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