C++ sux.
Here's why.
You can have a line of code which seems innocuous enough but which
drives other code that may extent across 30 different source files in
ten different packages. =(
Case in point:
Start at the tip of the ice burg:
src/electronics/components
And open up any old EC*, or anything in that same directory which looks
like it should have an EC in front of it.
Look at the constructor. Instead of just having variables, it has
"properties", a special OOP construct which hides function calls in
simple assignment statements (!!!). Just by declaring that it has a
property, it is allowed to specify the type, limiting values, and
initial value...
Once this is done, something rather spectacular happens, First, in the
UI, a list of these properties appear and the user is given the ability
to change them directly... -- I've only begun to understand how this
works much less trace the execution path through the dozens of classes
that are doubtlessly involved. Furthermore, there is even more hidden
code which automatically keeps the GUI synchronized with the actual
state of the device, through what's called the "observer" paradigm. It's
a C++ missfeature which quadruples the amount of work someone
maintaining the code needs to do to figure out what is effecting what in
the code. =\
Second, there is no such thing as "circuitdocumentfile.cpp" Nothing in
the code handles .circuit files! Instead, there is some library routine,
in a package that I have not yet been able to identify much less get
documentation on, the file is built up by collecting these properties
from all objects in the circuit and making some other library call,
which I haven't located yet, which generates (and reads!!!) XML files of
a reasonable and robust format. -- It will simply ignore unsupported
features of different versions.
This is all slicker than snot, and utterly untracable to anyone who
doesn't know how it all works in advance. Every method call is a method
call to a parent class, as opposed to a class variable, so there is no
prefix to grep for. At various points in the chain, the direction of
invocation reverses so if you identify the parent class supporting one
of these calls, you then have to identify the other interface in the
class's protocol that is being invoked by some other part in the system,
identify that function, and then resume your trace up the class
hierarchy. I only know the vaguest outlines, I really don't yet
understand what the actual class responsibilities are and much more
importantly, which methods I should and should not modify...
This brings us to ComponetModel and ComponentModel Library. -- It is the
half-complete (if not half-hearted), attempt to allow the user to select
from specific models of transistors. Clearly, this is much too limiting
because there are countless other parts which one might want to put into
such a library.
I'd move to abandon this code in favor of a more general setup, which
I'll have to design...
One issue that is really getting on my nerves is the use of what appears
to be C++ keywords I've never heard of, or some extension to C++ by a
mechanism which is equally foreign to me.
fragment: #######
class ComponentModelLibrary : public QObject
{
Q_OBJECT
public:
##############
See that? Q_OBJECT. WHAT IN GOD'S NAME DOES WRITING Q_OBJECT THERE DO?
Here are some more examples:
#################
*/
int countExtCon( const ItemList &cnItemList ) const;
virtual void update();
public slots:
/**
* Creates a subcircuit from the currently selected components
*/
##################
I know what public: is, I know what private: is. I even know where to
look up what protected: is. BUT WHAT IN GOD'S NAME IS PUBLIC SLOTS:????
Kdevelop paints the "slots" keyword blue but I have no idea what it
means or why it is there. =(
Yet another example:
#################
connect( this, SIGNAL(connectorAdded(Connector*)), this,
SLOT(requestAssignCircuits()) );
#################
Connect, which at first appears to be an ordinary function/method call,
is painted blue by kdevelop so it is probably something else, god only
knows what! same with SIGNAL and SLOT.
I don't even think this is C++, it's more like C+=2. =(
I can't find this by keyword in Bjarne Strostrup's "The C++ Programming
Language." There is probably a name for it that I could look up, but I
don't know it. =(
In the short term, what I'd like to do is continue on with removing
class vec, and then trying to figure out how wires and nodes are broken,
as you can see major errors with current summation. My branch has some
error checking code which will need to be extended and mainlined...
Beyond making what's there work, the highest priority is implementing a
generalized component library. That seems to be the most strongly
demanded feature. I'm simply not competent to work on it at present. =(((
--
Buy Ron Paul's Money! =)
http://www.libertydollar.org/ld/ronpauldollar
Soundest investment on the planet!
UPDATED: RAIDED BY THE GUSTAPO AND SHUT DOWN EVEN THOUGH PERFECTLY
INNOCENT.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ktechlab-devel mailing list
Ktechlab-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
