From: Julian B. <ju...@sv...> - 2009-12-07 12:36:00
|
hi again, I want to have short input on which iterators to use. Qt provides both, STL- and JAVA-style iterators. Here an example: java-style: QStringListIterator it(route); QPointF p; p.setX(it.next().toDouble()*8); p.setY(it.next().toDouble()*8); moveTo( p ); while (it.hasNext()) { p.setX(it.next().toDouble()); p.setY(it.next().toDouble()); p*=8; lineTo( p ); } same code with STL-style: QStringListI::const_iterator it = route.constBegin(); QPointF p; p.setX((*it++).toDouble()*8); p.setY((*it++).toDouble()*8); moveTo( p ); while ( it != route.constEnd() ) { p.setX((*it++).toDouble()); p.setY((*it++).toDouble()); p*=8; lineTo( p ); } which one should we use? There is now speed-impact of one over the other. Just a matter of taste. When iterating the whole list, I personally prefer the foreach macro, like: foreach (QVariant component, m_model->components()) { if (component.canConvert(QVariant::Map)) { addItem( new ComponentItem( component.toMap(), m_theme ) ); } } Is it okay? Or should we use another method, to iterate over every item in a list. (alternatives are: for-loops in combination with List::size() or iterators) I know, we have talked about that, earlier, but IMHO, we didn't agree on anything, yet. At least, I'm not aware of it. We should specify these things in the wiki.. and I'm willing to go through the code and change everything according to our agreements. This doesn't have to be done, right now, I just want to produce new code according to our agreements. My votes for the record: java-style iterators and foreach-macro, when possible bye then julian |
From: Alan G. <ag...@sp...> - 2009-12-07 16:26:14
|
Yeah, my vote is for the shortest code whenever possible. This has a number of advantages. However I also prefer STL wherever possible because it won't be changing in QT5... That said, some of my conversions to STL were ill advised. =( -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. |
From: P Z. <zol...@gm...> - 2009-12-07 20:49:09
|
On Mon, 07 Dec 2009 13:35:03 +0100, Julian Bäume <ju...@sv...> wrote: > hi again, > I want to have short input on which iterators to use. Qt provides both, > STL- > and JAVA-style iterators. Here an example: > java-style: > QStringListIterator it(route); > QPointF p; > p.setX(it.next().toDouble()*8); > p.setY(it.next().toDouble()*8); > moveTo( p ); > while (it.hasNext()) > { > p.setX(it.next().toDouble()); > p.setY(it.next().toDouble()); > p*=8; > lineTo( p ); > } > > same code with STL-style: > QStringListI::const_iterator it = route.constBegin(); > QPointF p; > p.setX((*it++).toDouble()*8); > p.setY((*it++).toDouble()*8); > moveTo( p ); > while ( it != route.constEnd() ) > { > p.setX((*it++).toDouble()); > p.setY((*it++).toDouble()); > p*=8; > lineTo( p ); > } > > which one should we use? There is now speed-impact of one over the > other. Just > a matter of taste. > > When iterating the whole list, I personally prefer the foreach macro, > like: > foreach (QVariant component, m_model->components()) > { > if (component.canConvert(QVariant::Map)) { > addItem( new ComponentItem( component.toMap(), m_theme ) ); > } > } > Is it okay? Or should we use another method, to iterate over every item > in a > list. (alternatives are: for-loops in combination with List::size() or > iterators) > > I know, we have talked about that, earlier, but IMHO, we didn't agree on > anything, yet. At least, I'm not aware of it. We should specify these > things > in the wiki.. and I'm willing to go through the code and change > everything > according to our agreements. This doesn't have to be done, right now, I > just > want to produce new code according to our agreements. > > My votes for the record: > java-style iterators and foreach-macro, when possible +1, the STL style is not my favorite foreach is something new for me, so I don't have a string opinion about that. Note that instead of that while(), a for() could be also used in java style code: for(QStringListIterator it(route); it.hasNext(); ??? ) { ... } Where do you increment that iterator? It's strange. Note that there is a coding style page in the wiki, so these discussions can be noted there. > > bye then > julian |
From: Julian B. <ju...@sv...> - 2009-12-07 23:46:20
|
On Monday 07 December 2009 21:49:11 P Zoltan wrote: > > My votes for the record: > > java-style iterators and foreach-macro, when possible > > +1, the STL style is not my favorite So I guess, it's 2 vs 1 in favour of STL style, for now ;) > foreach is something new for me, so I don't have a string opinion about > that. Note that instead of that while(), a for() could be also used in > java style code: > > for(QStringListIterator it(route); it.hasNext(); ??? ) { ... } > > Where do you increment that iterator? It's strange. it.next() will increase the position and return the object. If you don't want to increase the pointer, use it.peekNext(). It will just return the object. During the first cycle of the loop, it.peekNext() will return the first element, until it.next() is called. This is slightly more code, than with STL iterators, of course. But IMHO this is much more readable. So your example would read like: for(QStringListIterator it(route); it.hasNext(); it.next() ) { //use it.peekNext() to point to the object... } Also note, QStringListIterator is a const iterator. You can only access the objects in the list read-only. If you want to alter the objects, you need to use QMutableStringListIterator, instead. (Same applies for STL-style. there is QStringList::iterator and QStringList::const_iterator) Concerning the foreach-macro, well. It's just useful in the special case, when iterating over the complete list. It just saves you some lines of code. > Note that there is a coding style page in the wiki, so these discussions > can be noted there. Okay. I will try to stick to java-style iterators, for now. And if there are no further objections, we can manifest it onto that page. bye julian |
From: Julian B. <ju...@sv...> - 2009-12-08 00:03:20
|
On Monday 07 December 2009 17:14:40 Alan Grimes wrote: > Yeah, my vote is for the shortest code whenever possible. This has a > number of advantages. However I also prefer STL wherever possible > because it won't be changing in QT5... :) Okay, the container-classes changed their api, slightly in Qt4, but (there's always a but ;)) with good reasons. The work needed to go to the new API is quite minimal. The classes are changed to be more compatible with java container classes, as well as STL ones. Believe me, changes in the container API are not our problem ;) And I believe, the API will be the same in Qt5, also. I have not heard of any objections against this API ;) > That said, some of my conversions to STL were ill advised. =( Well, I think, this is because the STL container classes expose you more to the complexity of C++. The Qt API encourages you to use pointers, only when really necessary (many things can be expressed equally using references). This should result in more stable code. And it also encourages you to use the const keyword, whenever possible. This also helps reducing common mistakes, like doing stuff like "if ( myObj1 = myObj2 ). (This won't compile, when myObj1 is declared as const ;)) 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. Okay, just my 2ct. bye then julian |
From: Alan G. <ag...@sp...> - 2009-12-08 02:07:38
|
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. =\ 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. =\ 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. -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. |
From: Julian B. <ju...@sv...> - 2009-12-08 07:17:58
|
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 |
From: Alan G. <ag...@sp...> - 2009-12-08 16:07:41
|
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. |
From: Matthew A. <sol...@gm...> - 2009-12-08 16:13:37
|
I'm just throwing in my vote for C++ STL style. It's how I learned, so it's what I find clearest. |
From: Richard R. <ron...@gm...> - 2009-12-08 20:45:09
|
I personnaly prefer java-style and foreach when possible, but I'll be happy either way ;-) On Tue, Dec 8, 2009 at 5:13 PM, Matthew Ayres <sol...@gm...> wrote: > I'm just throwing in my vote for C++ STL style. It's how I learned, > so it's what I find clearest. > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > -- Richard Rondu Recherche et Developpement IUT de Cachan - Génie Électrique et Informatique Industrielle 2 |
From: P Z. <zol...@gm...> - 2009-12-21 22:45:40
|
So... what is the conclusion? java style: julian, me stl style: alan, matthew, lot of old code :D Helping question: do we want same style in all the codebase, or not? I'd say it would be nice to have a consistent style in the source code. I've found only this about iterators in KDE websites: http://techbase.kde.org/Development/Tutorials/Common_Programming_Mistakes#Iterators There they use stl style. In KDE source code is the same situation? Then it might be a good idea to use same style as KDE does... On Tue, 08 Dec 2009 21:44:34 +0100, Richard Rondu <ron...@gm...> wrote: > I personnaly prefer java-style and foreach when possible, but I'll be > happy either way ;-) > > On Tue, Dec 8, 2009 at 5:13 PM, Matthew Ayres > <sol...@gm...> wrote: >> I'm just throwing in my vote for C++ STL style. It's how I learned, >> so it's what I find clearest. >> >> ------------------------------------------------------------------------------ >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> Ktechlab-devel mailing list >> Kte...@li... >> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel >> > > > |
From: Matthew A. <sol...@gm...> - 2009-12-22 09:54:02
|
To me, it looks as though STL is the conclusion here. On Tue, Dec 22, 2009 at 12:45 AM, P Zoltan <zol...@gm...> wrote: > > So... what is the conclusion? > > java style: julian, me > stl style: alan, matthew, lot of old code :D > > Helping question: do we want same style in all the codebase, or not? I'd > say it would be nice to have a consistent style in the source code. > > I've found only this about iterators in KDE websites: > > > http://techbase.kde.org/Development/Tutorials/Common_Programming_Mistakes#Iterators > > There they use stl style. In KDE source code is the same situation? Then > it might be a good idea to use same style as KDE does... > > > > On Tue, 08 Dec 2009 21:44:34 +0100, Richard Rondu > <ron...@gm...> wrote: > > > I personnaly prefer java-style and foreach when possible, but I'll be > > happy either way ;-) > > > > On Tue, Dec 8, 2009 at 5:13 PM, Matthew Ayres > > <sol...@gm...> wrote: > >> I'm just throwing in my vote for C++ STL style. It's how I learned, > >> so it's what I find clearest. > >> > >> > ------------------------------------------------------------------------------ > >> Return on Information: > >> Google Enterprise Search pays you back > >> Get the facts. > >> http://p.sf.net/sfu/google-dev2dev > >> _______________________________________________ > >> Ktechlab-devel mailing list > >> Kte...@li... > >> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > >> > > > > > > > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Ktechlab-devel mailing list > Kte...@li... > https://lists.sourceforge.net/lists/listinfo/ktechlab-devel > |
From: Julian B. <ju...@sv...> - 2009-12-22 15:41:01
|
On Tuesday 22 December 2009 10:53:51 Matthew Ayres wrote: > To me, it looks as though STL is the conclusion here. I'm fine with that. I will change everything in my code accordingly and stick to STL iterators for the container-classes from now on. bye julian |