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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
_______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
