[Ktechlab-devel] a matter of style

[Alan Grimes]

Julian Bäume wrote:
>> Sure, C++ is great for organizing stuff but it's HORRIBLE for
>> algorithms. For algorithms, I require a language that executes directly
>> instead of vertically (try debugging a STL call). I need to be able to
>> think in terms of register moves, pushes and pops, and of the memory be
>> it stack, heap, or data, and understand exactly what the hell is slowing
>> shit down. =\ 

> I disagree, here. You can write nearly as fast code with C++ and Qt, as you do 
> with plain C++ or plain C. If an algorithm is slow, it can be because of many 
> things. One thing is bad implementation. If you copy around stuff a lot, 
> especially when it is not needed, you waste a lot of time (memory operations 
> are damn slow).

That's just it! In C++ I have no idea when I'm copying and when I'm
refferencing! =(

In Java, everything's a refferance until I new something. I can deal
with that.

In C, everything that isn't a pointer is a value. For example if I write
sturct a = struct b; (pseudocode) struct b is copied into struct a.

In C++ I don't know whether I'm copying a refference, a shallow copy of
the top class, or a deep copy!!! =(

So what I do is code around my ignorance by dealing almost exclusively
with pointers which are always references. That said, I have tried to
convert some things to references, with poor results. =\

>> The connector routing code is inherently a slow problem,
>> and therefore to get acceptable performance I reverted to the style
>> which I prefer to get the damn thing to work. -- that said, you can
>> compare my revisions to the archival code and make your judgment about
>> what I've done with it.

> Okay, I see, what you mean. It is okay for me, if you do so. Especially if it 
> really brings a speed-up. May be, in this cases we should have a look on 
> problematic code, together and discuss possible solutions. This might be a way 
> to create more than one solution and chose the best one out of these.

The problem that I will probably be getting into next time I have time
for ktechlab, is the class Pin and (inherently), the classes it deals
with. pin contains a ton of information that belongs to NodeGroup.
Ideally Pin should be as simple as Wire now is. I have also left a ton
of TODO's and FIXME's in the code. Each one a very valid subject of
discussion.

-- 
DO NOT USE OBAMACARE.
DO NOT BUY OBAMACARE.
Powers are not rights.