On 10/18/11 11:56 AM, "ext Oswald Buddenhagen" <[email protected]> wrote:
>On Mon, Oct 17, 2011 at 10:25:37PM +0200, Knoll Lars (Nokia-MP-Qt/Oslo) >wrote: >> On 10/17/11 7:33 PM, "ext Oswald Buddenhagen" >> <[email protected]> wrote: >> >> >On Mon, Oct 17, 2011 at 02:55:53PM +0200, Knoll Lars (Nokia-MP-Qt/Oslo) >> >wrote: >> >> Why would we want to add a wrapper for char's? >> >> >> >why again do we have a wrapper for ushort called QChar? after all, some >> >global functions operating on ushort would do. ;) >> > >> >> I don't see any added value of having a 'QByte' class/struct/typedef. >> >> >> >i do. code which is easily templateable for both. >> >> At the cost of people having to deal with another class where a >>primitive >> type is perfectly fine? >> >well, yes. it's consistent. >for that matter, i would be all for turning qchar into a collection of >static functions operating on ushort. >but either option is not doable for qt5 anyway, because a change either >way would be massively source-incompatible for low-level code. so i'll >just add *podData() functions to both classes for the time being. Well, QByteArray has data(), QString has data() and unicode()? Why do we need another method for getting the same thing? > >> Not even to mention the drawbacks in terms of ABI. >> Classes are not passed in registers to functions, primitive types are. >> >in this case https://qt.gitorious.org/qt/qtbase/merge_requests/69 is >plain bogus. and the previous endeavours to get rid of QLatin1String >const refs. I think it is indeed wrong. But someone should go back and check the ARM and x64 ABI specs once again to make sure. Cheers, Lars _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
