Re: [Interest] Why QString and not std::string?
> I actually don't know anyone directly who codes C++ _with_ boost. I use boost when it is non-graphical stuff and the LGPL is not good enough. Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On Saturday 16 June 2012 Jun, Michael Seydl wrote: > When there's no Qt I definitely would use boost. It's header only ... mostly > ... very portable and provides everything one could need. Asio, regex, > filesystem, spirit ... But that's the Qt mailing list don't wanna make > advertisement for another library here. ;) If there were no Qt, yeah... I guess I would use -- Wait. I think I'd open a second-hand bookshop or something like that. I'd probably stop coding. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
Nobody forces you to. Due to naming conflicts of slots and signals moc including boost can be quite a hassle. What I tried to say is std::string needs enhancement when QString is not available and that one good stable possibility is boost. Personally I used boost::bind and boost::function even in Qt projects sometimes, but that's just my odd preference in the light of slots and meta object method invocation. Greets, Mike On 16.06.2012, at 16:50, warg...@gmx.dde wrote: > On Sat, Jun 16, 2012 at 04:45:28PM +0200, Michael Seydl wrote: > >> Who codes C++ without boost >> nowadays? boost::lexical_cast ftw. > > I use both, but usually don't mix. Why should I use boost in > a Qt project? If boost does not provide anything I need, > which I cannot get from Qt? > > Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
When there's no Qt I definitely would use boost. It's header only ... mostly ... very portable and provides everything one could need. Asio, regex, filesystem, spirit ... But that's the Qt mailing list don't wanna make advertisement for another library here. ;) Sent from my iPhone On 16.06.2012, at 17:22, Boudewijn Rempt wrote: > On Saturday 16 June 2012 Jun, Michael Seydl wrote: >> I'd say one reason is the encoding awareness of QString alone is a good >> reason. Fiddling around with libicu and alike is a mess. Regarding the int >> to string thing. Who codes C++ without boost nowadays? boost::lexical_cast >> ftw. > > I actually don't know anyone directly who codes C++ _with_ boost. > > -- > Boudewijn Rempt > http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On Saturday 16 June 2012 Jun, Michael Seydl wrote: > I'd say one reason is the encoding awareness of QString alone is a good > reason. Fiddling around with libicu and alike is a mess. Regarding the int to > string thing. Who codes C++ without boost nowadays? boost::lexical_cast ftw. > I actually don't know anyone directly who codes C++ _with_ boost. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On Sat, Jun 16, 2012 at 04:45:28PM +0200, Michael Seydl wrote: > Who codes C++ without boost > nowadays? boost::lexical_cast ftw. I use both, but usually don't mix. Why should I use boost in a Qt project? If boost does not provide anything I need, which I cannot get from Qt? Guido ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
More people than you might think. ;) On 06/16/2012 06:45 PM, Michael Seydl wrote: > Who codes C++ without boost nowadays? signature.asc Description: OpenPGP digital signature ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
I'd say one reason is the encoding awareness of QString alone is a good reason. Fiddling around with libicu and alike is a mess. Regarding the int to string thing. Who codes C++ without boost nowadays? boost::lexical_cast ftw. Greetz, Mike On 15.06.2012, at 12:50, Rui Maciel wrote: > Does anyone know what's the rationale for relying on Qt's custom QString > instead of simply using C++'s standard and omnipresent std::string? > > > Thanks in advance, > Rui Maciel > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
> > On 2012/06/15 07:26 PM, Charley Bay wrote: > > > (1) Its interface is too minimal (insufficient) > > (2) Its implementation is limited > > (3) It does not support real-world-unicode use > > > > That's my venting because for over a decade I never understood why > > people thought std::string was an acceptable component. IMHO it's > > absolutely useless. And dangerous. I don't care if I'm the only one on > > the planet with my conclusion, but IMHO, std::string is > > absolutely unusable insufficient crap. > > On Sat, Jun 16, 2012 at 7:06 AM, Alex Strickland respondeth: > I enjoyed this article: http://www.gotw.ca/gotw/084.htm > > Herb Sutter's not too thrilled with it, but iirc the interface being > minimal isn't one of the reasons :) > That's a good read -- thanks! My summary for those not wanting to RTFA (please feel free to correct me): "Monolithic designs create complex classes that do less, not more; sometimes member functions should be non-friend, non-member functions to enable "logic-reuse" and "logic-extensibility"; Lookie here, "std::string" is a good example of a monolithic class that is not-well-thought-out for various reasons." I admit "string" is a (somewhat) "hard problem". The concept of "string" is: - is ubiquitous for all systems (i.e., "key-abstraction") - is "kind-of" a container, but not really - is legitimately a class (requiring things like memory management, constructors/destructors, overloaded operators, basic accessors/manipulators) - is legitimately a library (TONS of manipulators, search-and-replace, accessors, etc., are required), including both "universally-understood" and "domain-specific" library needs (e.g., advanced "regular-expression-matching" could be considered "domain-specific", as there are different dialects) - implies algorithms that SHOULD be "reusable" (e.g., among UTF-8/UTF-16/UTF-32, fixed-width or MBCS, and application-specific types that are "like-strings" but with application-specific types, etc.) My opinion is that "std::string" did both wrong: It's not minimal-enough (e.g., they could have put the "heavy-lifting" into libraries), and it's not complete-enough (it's not "useful-enough" on its own). It could have gone to either end of the spectrum, but it chose to stand in the middle of the road, where it will get hit by cars driving in both directions. Our systems use both QString (it's "strong" by itself and offers great Unicode support), and "MyCustomString" (extends functionality specific to our needs, including *lots* of parsing). In part, we could **NEVER** use "std::string" because there is no mechanism to extend functionality in a reasonable way (that is not part of its current design, and we can't wait years for a couple new API functions to show up in the "standard"). Any APIs passing around "std::string&" are highly future-limited (e.g., not "future-proof" enough for us). Heck, even forcing me to decide if my API should pass a "std::string&" or "std::wstring&" seems really stupid to me (I should not have to decide that now, because not matter what I select, it will absolutely be wrong later.) The proper answer is to "wrap" the decision in a "MyString" class that handles such details so I can have a stable API. But, such is not the belief of "The Committee". But, quite seriously, "TheString" is absolutely a key abstraction. In any system. That means, "Upon This Rock I Shall Build My System." I absolutely cannot use a component that will seg-fault/core-dump when its public API is exercised in a reasonable way (such as when assigning it a "char*" value, that later turned out to accidentally be NULL, which happens all the time, across module boundaries and interfacing with legacy libraries, which is pretty much every system on Earth that uses "char*" as a data type.) This is an absolutely (trivially) avoidable problem with a reasonable implementation THAT THEY CHOSE TO NOT CENTRALIZE. It's bat-sh*t INSANE to assume every application-specific use, and every programmer at ten-minutes-till-5pm-on-Friday will merely do-the-extra-stupid-work to wrap all operations with an "if(...)". --charley ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 2012/06/15 07:26 PM, Charley Bay wrote: > (1) Its interface is too minimal (insufficient) > (2) Its implementation is limited > (3) It does not support real-world-unicode use > > That's my venting because for over a decade I never understood why > people thought std::string was an acceptable component. IMHO it's > absolutely useless. And dangerous. I don't care if I'm the only one on > the planet with my conclusion, but IMHO, std::string is > absolutely unusable insufficient crap. I enjoyed this article: http://www.gotw.ca/gotw/084.htm Herb Sutter's not too thrilled with it, but iirc the interface being minimal isn't one of the reasons :) -- Regards Alex ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On sexta-feira, 15 de junho de 2012 14.31.26, 3dw...@verizon.net wrote: > Here&aps;s hoping the upgrade at least the standard library a LOT faster > going forward. Great! Now maybe in C++15 or 16 we'll be able to convert strings from the local 8-bit codec to Unicode without using , mbstowcs and managing buffers manually. And then we'll be able to use them by 2020. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On Fri, Jun 15, 2012 at 11:50:47AM +0100, Rui Maciel wrote: > Does anyone know what's the rationale for relying on Qt's custom QString > instead of simply using C++'s standard and omnipresent std::string? std::string is closer to QByteArray than to QString, so you are probably not asking the question that you might want to ask. Anyway, "convenience" is one reason. Andre' ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
I know C+11 is not available everywhere but they did work on lexical casting:string to_string(int val);string to_string(unsigned val);string to_string(long val);string to_string(unsigned long val);string to_string(long long val);string to_string(unsigned long long val);string to_string(float val);string to_string(double val);string to_string(long double val);And similarly for wstring. They also have conversions in the other way: stoi, etc.Here's hoping the upgrade at least the standard library a LOT faster going forward. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On sexta-feira, 15 de junho de 2012 12.19.27, Rui Maciel wrote:
> With C++11, UTF-16 strings are supported through the std::u16string
> type, which is a typedef for basic_string.
That's great. Except that the standards people often forget the most basic
things should be easy...
Here's one they forgot. Please fill in the blank:
#include
int main(int argc, char **argv)
{
std::u16string s = __ (argv[1]);
}
I'm looking for the equivalent of QString::fromLocal8Bit().
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 6/15/12 10:18 AM, Konstantin Tokarev wrote:
>
>
> 15.06.2012, 17:50, "Giuseppe D'Angelo" :
>> On 15 June 2012 14:35, Sven Anderson wrote:
>>
>>> On 15.06.2012 14:58, Thiago Macieira wrote:
Any one care to give me the Standard Library equivalent of:
QString::number(x)
>>> string to_string(int) ?
>>
>> No go, C++11 only.
>
> #if NO_CXX11_AVAILABLE
> std::string to_string(int x)
> {
> std::static_cast( &(std::ostringstream() << x )
> )->str();
> }
> #endif
>
It works, but it's terribly slow: sprintf is 5 times faster on my
system. Benchmark is at https://gist.github.com/2937802.
Chhers,
Jonas
signature.asc
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
15.06.2012, 21:26, "Charley Bay" : > That's my venting because for over a decade I never understood why people > thought std::string was an acceptable component. IMHO it's absolutely > useless. And dangerous. I don't care if I'm the only one on the planet with > my conclusion, but IMHO, std::string is absolutely unusable insufficient crap. Well, when compared with char *, std::string readily becomes acceptable, useful, and safe ;) -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
> > >>> > But it's standard and it is C++. > >> But (I think) the point was: what should have we used for the last > >> 10-15 years of QString? > > > > I could've been a bit clearer in my initial post, but I intended to know > > if there was currently any reason that justified having QString around > > instead of simply using what's already included in C++'s standard > > library. > The thread has talked about historic reasons, including support of UTF-16, and historic non-standard availability of STL, how QString is copy-on-write (explicitly not allowed by std::string), and how "wide-string" is not UTF-16. These are rational, but since they are "historic", one could argue they avoid the central question of, "Why use QString going forward?" I *really* want to get back to "Item-Four", which was "QString expanded interface" where you can do things (parsing, etc.) that are not in the "std::string" interface. IMHO, the std::string interface is absolutely insufficient crap. Any implementation that crashes with the following: std::string my_string; my_string = NULL; // crash??!! ...those developers should be taken-out-back-and-shot. Their bodies burned. Their names to not be spoken again. IMHO, I would absolutely never use std::string: (1) Its interface is too minimal (insufficient) (2) Its implementation is limited (3) It does not support real-world-unicode use That's my venting because for over a decade I never understood why people thought std::string was an acceptable component. IMHO it's absolutely useless. And dangerous. I don't care if I'm the only one on the planet with my conclusion, but IMHO, std::string is absolutely unusable insufficient crap. If you remove QString, I'll just wrap the string-class-of-choice into a "MyString" class that is minimally acceptable to do what "std::string" should have done. ;-)) --charley ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On Fri, 15 Jun 2012 17:39:06 +0300, Rui Maciel wrote: > On 06/15/2012 03:13 PM, Giuseppe D'Angelo wrote: >>> > But it's standard and it is C++. >> But (I think) the point was: what should have we used for the last >> 10-15 years of QString? > > I could've been a bit clearer in my initial post, but I intended to know > if there was currently any reason that justified having QString around > instead of simply using what's already included in C++'s standard > library. Mixing different libraries and standards into single jar quite often ends up in total mess. And you can just others about their experience of doing so, starting from the last point here: http://blog.qt.nokia.com/2010/06/17/how-qt-can-turn-you-into-a-guitar-maestro/ -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
> From: Till Oliver Knoll >2012/6/15 Rui Maciel : Nevertheless, why is it important to support UTF-16? >>> >>> 1. Faster string search modification than for UTF8 >>> 2. It's native UTF string format on Windows and Mac OS X. >> >> How relevant is the efficiency of string search modification operations? > >EXTREMELY relevant! While not every application is constantly digging >through piles of text, I would dare to say that string operations >(concatenation, search, replace, regexp, ...) are one of the most >common operations that applications do. And be it just the parsing of >config files. > >> And what string data type is used in C++ projects that target Windows >> or OSX? > >Guess what: UTF-16 ;) (that's the internal data format of QString). And to top it off, last I checked std::wstring on Linux (with GCC's libstdc++ at least) was UTF-32. Yeah, that bit me a few weeks back when I was trying to write a Standard C/C++ library for an in-house file format that only specified that certain fields were wide-characters in Unicode. The original code was all Win32 stuff and the author didn't think to note in anything that it was UTF-16. So I had to write a little converter for what I needed as C++11 is not available in all my build environments yet after figuring out that was what the problem was. Ben ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 15 June 2012 15:39, Rui Maciel wrote: > On 06/15/2012 03:13 PM, Giuseppe D'Angelo wrote: >>> > But it's standard and it is C++. >> But (I think) the point was: what should have we used for the last >> 10-15 years of QString? > > I could've been a bit clearer in my initial post, but I intended to know > if there was currently any reason that justified having QString around > instead of simply using what's already included in C++'s standard library. Besides all the technical reasons given? Backwards compatibility to existing code-bases. There's millions upon millions of lines of Qt code out there using QString, do you want to tell everyone that to port to Qt5 they must use C++11 and change all their code to use std_string? John. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
2012/6/15 Paul Miller : >>> ... >>> QString::number(x) >> >> static_cast(&(ostringstream()<< x ) )->str(); > > I just threw up a little in my mouth. > > I'll take QString::number(x), thank you. Hehe, thanks for the chuckle, I was just about to write a similar story ;) In fact, I'll prefer anytime the Qt equivalent to any << c++11(_std_api).STL_there_is<<42_because&(it'\\s_easier_to_read (same goes for boost - sorry), even if I loose 10% of performance, but gain just 11% of readability and ease of use! Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
[proper recipient] 2012/6/15 Rui Maciel : > ... > > Wouldn't it be better to simply provide an alternative std::string > implementation for that specific case? That's what has been done: it's called QString ;) > And how relevant is that > requirement today? As others have mentioned, C++ 11 is not available everywhere yet. >>> Nevertheless, why is it important to support UTF-16? >> >> 1. Faster string search modification than for UTF8 >> 2. It's native UTF string format on Windows and Mac OS X. > > How relevant is the efficiency of string search modification operations? EXTREMELY relevant! While not every application is constantly digging through piles of text, I would dare to say that string operations (concatenation, search, replace, regexp, ...) are one of the most common operations that applications do. And be it just the parsing of config files. > And what string data type is used in C++ projects that target Windows > or OSX? Guess what: UTF-16 ;) (that's the internal data format of QString). Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 06/15/2012 03:13 PM, Giuseppe D'Angelo wrote: >> > But it's standard and it is C++. > But (I think) the point was: what should have we used for the last > 10-15 years of QString? I could've been a bit clearer in my initial post, but I intended to know if there was currently any reason that justified having QString around instead of simply using what's already included in C++'s standard library. Rui Maciel ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On sexta-feira, 15 de junho de 2012 17.46.37, Konstantin Tokarev wrote: > 15.06.2012, 16:58, "Thiago Macieira" : > > Any one care to give me the Standard Library equivalent of: > > > > QString::number(x) > > static_cast( &(ostringstream() << x ) )->str(); Don't forget the #include, which is not . Last time I tried this, it took me a few minutes to figure out what I had done wrong, then find on the internet what the header name was. (last weekend, while porting Synergy to IPv6) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 06/15/2012 12:25 PM, Konstantin Tokarev wrote: > > > 15.06.2012, 15:19, "Rui Maciel": >> On 06/15/2012 11:55 AM, Konstantin Tokarev wrote: >> >>> 1. Historical reasons - STL was not implemented on the same level in all >>> compilers >>> in the past. >> >> Is this constraint still relevant today? > > Not so long ago it turned out that toolchain for some SoC was shipped without > STL so I had > to eliminate its usage. Wouldn't it be better to simply provide an alternative std::string implementation for that specific case? And how relevant is that requirement today? >>> 2. std::string does not hadle UTF16 strings, and std::wstring is >>> non-standard >> >> With C++11, UTF-16 strings are supported through the std::u16string >> type, which is a typedef for basic_string. > > Not everyone can use C++11 today. But it appears that there is already some talks on implementing features in Qt5 which rely on C++11. >> Nevertheless, why is it important to support UTF-16? > > 1. Faster string search modification than for UTF8 > 2. It's native UTF string format on Windows and Mac OS X. How relevant is the efficiency of string search modification operations? And what string data type is used in C++ projects that target Windows or OSX? Rui Maciel ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 6/15/2012 8:46 AM, Konstantin Tokarev wrote: > > > 15.06.2012, 16:58, "Thiago Macieira": >> Any one care to give me the Standard Library equivalent of: >> >> QString::number(x) > > static_cast(&(ostringstream()<< x ) )->str(); I just threw up a little in my mouth. I'll take QString::number(x), thank you. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
15.06.2012, 17:50, "Giuseppe D'Angelo" :
> On 15 June 2012 14:35, Sven Anderson wrote:
>
>> On 15.06.2012 14:58, Thiago Macieira wrote:
>>> Any one care to give me the Standard Library equivalent of:
>>>
>>> QString::number(x)
>> string to_string(int) ?
>
> No go, C++11 only.
#if NO_CXX11_AVAILABLE
std::string to_string(int x)
{
std::static_cast( &(std::ostringstream() << x )
)->str();
}
#endif
--
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 15 June 2012 15:10, Rui Maciel wrote: > On 06/15/2012 02:50 PM, Giuseppe D'Angelo wrote: >>> > string to_string(int) ? >> No go, C++11 only. > > But it's standard and it is C++. But (I think) the point was: what should have we used for the last 10-15 years of QString? -- Giuseppe D'Angelo ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 06/15/2012 02:50 PM, Giuseppe D'Angelo wrote: >> > string to_string(int) ? > No go, C++11 only. But it's standard and it is C++. Rui Maciel ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 15 June 2012 14:35, Sven Anderson wrote: > > > On 15.06.2012 14:58, Thiago Macieira wrote: >> Any one care to give me the Standard Library equivalent of: >> >> QString::number(x) > > string to_string(int) ? No go, C++11 only. -- Giuseppe D'Angelo ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
15.06.2012, 16:58, "Thiago Macieira" : > Any one care to give me the Standard Library equivalent of: > > QString::number(x) static_cast( &(ostringstream() << x ) )->str(); -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 15.06.2012 14:58, Thiago Macieira wrote: > Any one care to give me the Standard Library equivalent of: > > QString::number(x) string to_string(int) ? Sven ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 15.06.2012 14:58, Thiago Macieira wrote: > On sexta-feira, 15 de junho de 2012 16.12.55, Constantin Makshin wrote: >> 3. std::string's behavior (e.g. use of the copy-on-write technique) is >> implementation-dependent while QString is the same everywhere. > > C++11 bans that. C++11 says that std::string must not be refcounted. Honestly? I'm confused... Is there any copy-on-write alternative in the standard then? Sven ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On sexta-feira, 15 de junho de 2012 16.12.55, Constantin Makshin wrote: > On 06/15/2012 02:55 PM, Konstantin Tokarev wrote: > > 15.06.2012, 14:50, "Rui Maciel" : > >> Does anyone know what's the rationale for relying on Qt's custom QString > >> instead of simply using C++'s standard and omnipresent std::string? > > > > 1. Historical reasons - STL was not implemented on the same level in all > > compilers in the past. > > 2. std::string does not hadle UTF16 strings, and std::wstring is > > non-standard > 3. std::string's behavior (e.g. use of the copy-on-write technique) is > implementation-dependent while QString is the same everywhere. C++11 bans that. C++11 says that std::string must not be refcounted. > 4. QString has more features (formatting, regular expressions, cheap > substring extraction through QStringRef, etc.). Any one care to give me the Standard Library equivalent of: QString::number(x) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
15.06.2012, 16:12, "Constantin Makshin" : > On 06/15/2012 02:55 PM, Konstantin Tokarev wrote: > >> 15.06.2012, 14:50, "Rui Maciel" : >>> Does anyone know what's the rationale for relying on Qt's custom QString >>> instead of simply using C++'s standard and omnipresent std::string? >> 1. Historical reasons - STL was not implemented on the same level in all >> compilers >> in the past. >> 2. std::string does not hadle UTF16 strings, and std::wstring is >> non-standard > > 3. std::string's behavior (e.g. use of the copy-on-write technique) is > implementation-dependent while QString is the same everywhere. > 4. QString has more features (formatting, regular expressions, cheap > substring extraction through QStringRef, etc.). Note that (4) on its own doesn't require new implementation of string -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 06/15/2012 02:55 PM, Konstantin Tokarev wrote: > 15.06.2012, 14:50, "Rui Maciel" : >> Does anyone know what's the rationale for relying on Qt's custom QString >> instead of simply using C++'s standard and omnipresent std::string? > 1. Historical reasons - STL was not implemented on the same level in all > compilers > in the past. > 2. std::string does not hadle UTF16 strings, and std::wstring is non-standard 3. std::string's behavior (e.g. use of the copy-on-write technique) is implementation-dependent while QString is the same everywhere. 4. QString has more features (formatting, regular expressions, cheap substring extraction through QStringRef, etc.). signature.asc Description: OpenPGP digital signature ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
15.06.2012, 15:19, "Rui Maciel" : > On 06/15/2012 11:55 AM, Konstantin Tokarev wrote: > >> 1. Historical reasons - STL was not implemented on the same level in all >> compilers >> in the past. > > Is this constraint still relevant today? Not so long ago it turned out that toolchain for some SoC was shipped without STL so I had to eliminate its usage. > >> 2. std::string does not hadle UTF16 strings, and std::wstring is >> non-standard > > With C++11, UTF-16 strings are supported through the std::u16string > type, which is a typedef for basic_string. Not everyone can use C++11 today. > > Nevertheless, why is it important to support UTF-16? 1. Faster string search modification than for UTF8 2. It's native UTF string format on Windows and Mac OS X. -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
On 06/15/2012 11:55 AM, Konstantin Tokarev wrote: > 1. Historical reasons - STL was not implemented on the same level in all > compilers > in the past. Is this constraint still relevant today? > 2. std::string does not hadle UTF16 strings, and std::wstring is non-standard With C++11, UTF-16 strings are supported through the std::u16string type, which is a typedef for basic_string. Nevertheless, why is it important to support UTF-16? Rui Maciel ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Why QString and not std::string?
15.06.2012, 14:50, "Rui Maciel" : > Does anyone know what's the rationale for relying on Qt's custom QString > instead of simply using C++'s standard and omnipresent std::string? 1. Historical reasons - STL was not implemented on the same level in all compilers in the past. 2. std::string does not hadle UTF16 strings, and std::wstring is non-standard -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
