On 17/05/2011, at 8:41 PM, André Pönitz wrote: I thought we already settled on "keep sources compatible unless it _really_ hurts". We can discuss whether keeping the inability to have more then 2 billion items / 2 GB counts as "really hurts". I still claim it doesn't, as any real application needing containers that big will have left behind the implicit shared Qt containers _a long time_ before it hit the size limit.
So this is a discussion about real loss in the cross-platform promise vs a perceived but not-really-existing gain. I could agree with adding _another_ QVector64 class template or something similar as already suggested by others in this thread, but then, people really who really need that could just use std::vector. There is one case where QVector solves problems that std::vector cannot. If you use QVector in your interface and you make that interface available across module boundaries (ie you export the symbol/function/class it is being used by), this still allows developers of other libraries that interface with yours to switch out their STL implementation for something else, such as STLport (we've done this and so have others). This is a useful way of checking your STL usage during development, but you can only safely do it if you don't have any of the STL in your interfaces (or you can guarantee that all libraries using the STL in their interface were also built with your custom STL implementation). My understanding is that Qt only uses STL containers in its interface in ways that will always result in the code being inlined, so you shouldn't have any problems switching to a different STL implementation. It doesn't matter what STL Qt might be using internally, since that code is already compiled into the Qt binaries. If you have something like std::vector in your exported interface, you immediately deprive clients of your library from being able to switch to a different STL implementation for their own code. Thus, being able to stick with QVector can be advantageous. I won't enter into the discussion about performance since I haven't done the comparisons myself, other than to say that I'd be surprised if there were not legitimate cases/specific scenarios where careful usage would avoid performance concerns for QVector. Regarding use of ssize_t as a potential replacement for int, isn't this a non-standard type currently only provided by GNU C? I guess you'd have to explicitly create a typedef for it under Windows. Given the current style used within Qt, it would seem more consistent to create a Qt-specific type like what is done with qint64, etc. It would lower the risk of a platform introducing an incompatible/suboptimally sized ssize_t in the future. That aside (and again putting aside performance considerations for now), switching to ssize_t shouldn't break existing code at the source level. If it did, then it would seem to me that the code was already not safely handling the situation where it would try to represent a number too large for an int. Concerns about a 64-bit app with a ssize_t value being passed via QDataStream to a 32-bit app and the latter receiving a number they can'r represent also seem a bit of a red herring for this particular argument (but it is a potentially valid argument for other reasons), since current code would already have to handle an int on the sending end for the cases where we are talking about a switch to ssize_t. Sorry if I'm mixing two separate threads of discussion here, but I'm not yet seeing how a switch to ssize_t would break existing valid code at the source level (but I'm happy to be shown such examples!). -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
