Re: [Ktechlab-devel] a matter of style

[Julian B. <ju...@sv...>]

On Tuesday 08 December 2009 02:55:56 Alan Grimes wrote:
> Julian Bäume wrote:
> > That's why I think, the Qt API helps to write better code. I saw a
> > construct in the code, reading: "Cell **m_cell;" or something like that.
> > WTF? ;) This is not C, it's C++. Such expressions should really be
> > avoided and I can't think of any example, where there is no other way of
> > expressing this.
> 
> I'm a C programmer. =\
I didn't mean to offend you, here :)

> 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). Bad implementation can be avoided. Another thing is 
algorithmic complexity. You won't be able to implement (perfect) routing in a 
fast way. So you need to implement heuristics, that solve the problem fast, 
but not with optimal results. These problems can't be avoided. (Not yet ;)) 
All these problems have a real impact on the speed of programs like KTechLab. 
The overhead Qt or any other library might bring here shouldn't count much.

> 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.

bye then
julian