Lawrence, Have you been able to make any progress with the Ktechlab website? Jason. ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev
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 );
}
(Continue reading)
hi, I just wanted to show some progress, I made with the kde4 port. I implemented basic functionality of drawing connectors (graphical representation of a wire), tonight. The nights before, I refactored the work I did on drawing components. It's now based on QGraphicsView system. I noticed some conflicts between the old QCanvas implementation and the new one, regarding coordinate systems and reference points. Therefore I'd like to slightly change the circuit-file format, to make it fit better to the needs of the new graphics- system. I'm not sure, how exactly I want to change it, but I don't like it, as it is done, at the moment. One example I don't like is the use of different reference points and scales. A route in a connector is stored relatively to an 8x8 grid, item's coordinates are stored in absolute pixel-values. I still don't want to break old files, so I want to provide some legacy code, to load old style circuit files and save them as the new version. But as I said, I need to clarify some things, before proceeding (i.e. implement write support). I got some screen-shots: First one is very old.. it shows my first tests with plasma.. but there is the KDE3 version of ktechlab, showing a circuit file, I use for testing: http://nbprogs.dyndns.info/~jb/screen/ktechlab-circuit.png Then, the same file loaded with the version from "circuit_rewrite" branch: http://nbprogs.dyndns.info/~jb/screen/ktechlab-circuit1.png Note, the connectors are exactly the same, the components still have got some scaling and minor positioning issues (due to problems, I explained earlier in this mail). And the same, but with Theme::defaultTheme() set to "us" instead of "din": http://nbprogs.dyndns.info/~jb/screen/ktechlab-circuit2.png Again, there's some issues with the scale of the components, but this can be(Continue reading)
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. ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev
Julian Bäume wrote: > hi, > I just wanted to show some progress, I made with the kde4 port. I implemented > basic functionality of drawing connectors (graphical representation of a > wire), tonight. The nights before, I refactored the work I did on drawing > components. It's now based on QGraphicsView system. I noticed some conflicts > between the old QCanvas implementation and the new one, regarding coordinate > systems and reference points. Therefore I'd like to slightly change the > circuit-file format, to make it fit better to the needs of the new graphics- > system. I'm not sure, how exactly I want to change it, but I don't like it, as > it is done, at the moment. One example I don't like is the use of different > reference points and scales. A route in a connector is stored relatively to an > 8x8 grid, item's coordinates are stored in absolute pixel-values. I still > don't want to break old files, so I want to provide some legacy code, to load > old style circuit files and save them as the new version. But as I said, I > need to clarify some things, before proceeding (i.e. implement write support). I did a cleanup pass of the connector code about a month ago. I hope you are basing your changes to connectors off the current SVN, it is considerably less buggy and more readable... -- -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere.(Continue reading)
On Mon, 07 Dec 2009 13:35:03 +0100, Julian Bäume <julian <at> svg4all.de> 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());
(Continue reading)
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
(Continue reading)
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(Continue reading)
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. ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev(Continue reading)
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(Continue reading)
RSS Feed6 | |
|---|---|
1 | |
1 | |
3 | |
3 | |
7 | |
8 | |
1 | |
3 | |
4 | |
3 | |
4 | |
2 | |
14 | |
2 | |
5 | |
14 | |
20 | |
6 | |
3 | |
1 | |
3 | |
1 | |
16 | |
13 | |
13 | |
12 | |
23 | |
2 | |
19 | |
17 | |
14 | |
42 | |
35 | |
119 | |
107 | |
79 | |
26 | |
41 | |
37 | |
65 | |
47 | |
27 | |
129 | |
32 | |
39 | |
75 | |
3 | |
41 | |
16 | |
20 | |
18 | |
61 | |
2 | |
2 | |
7 | |
5 | |
45 | |
18 | |
22 | |
3 | |
18 | |
57 | |
18 |
