I got a BB Z10 for free for being a Qt developer and attend a developer event. It was my first BlackBerry, and I am so sorry that I will have to let it go, since I am so not buying a BB device if it's just running Android (If I'll end up buying an Android device, I'll have plenty of choices). Yes, the BB OS 10 interface is a lot better for me than Android. I loved the Nokia N9, and this one was even a tiny step forward, and I'm too used to it after 5 years of happiness. I also used a Jolla for some time, and is the kind of UI where I feel at home.
The way you jump back and forth between applications on Android is really really bad for my taste. I have an Android tablet, and it annoys the hell of me that it shows lots of poor screenshots of applications that I have not opened (e.g. when I just restarted after an upgrade it shows tons of them no really running). Harmattan (Nokia N9), Sailfish OS (Jolla) or BlackBerry OS 10 give a much more useful indication of what the application is/was doing, or additional controls. Besides, you see several of them at a glance, not in a stack view that only shows a tiny slice of the second one and almost nothing of the next ones.
The top shade got one step back in the last major Android release. In an Android tablet, the user had access to different quick controls swiping on the left or the right of the screen: now I have to swipe twice to have quick access to the Bluetooth control, so moving my headset from the phone to the tablet (or vice versa) is a lot faster and convenient in BB OS 10 with respect to Android (they used to be tied in the previous version).
I'm used to not being the typical user (I'm a bit more power user, fine), but seriously, changing from one application to the other (browser to podcast to instant messaging for example) or having quick access to Bluetooth settings is something I would expect done right in 100% of the mobile OSs for this time and age.
Second, if the HTML pages were served under the more secure application/xhtml+xml media type, the compromised page wouldn't have been usable, because the malformed syntax would have produced a fatal error, instead of silently corrected (this is specified in HTML5, which IE supports now, woo).
I think this speaks clearly of how bad was the decision of creating HTML 5, and not making future web documents an XML application only. With XML, the rules clearly state that a document has to be well formed in order to be interpreted by the XML parser (then it can be invalid according to the XML application, say XHTML). But no, they kept the incredibly stupid tradition of making browsers try to recover according to unspecified ways. I wonder how many workarounds are in the parsers of todays web browsers that swallow utterly broken contents that IE6 displayed properly at that time. Workarounds and complicated code paths that will probably stick for a really long time, since old content will not be fixed ever. And complex code paths that will continue to produce security holes from time to time.
Ironically, many (if not all) the usability issues that you mention that C++ could change, are nearly impossible to fix due to the C legacy. But having C as legacy is also a big strength: you can use native OS APIs with ease.
Yes, I know quite a few other languages, but I want to get into a widespread compiled language that has good ties into FOSS. Both Objective-C and C++ fit that bill.
I know plenty of open source applications, from GUIs in Qt and gtkmm to console applications and interpreters of programming languages in C++. The backbone of any Linux distribution is C and C++.
I know 0 packages in my Linux installation that are written in Objective-C. There are some, for sure, but are they widespread? I doubt it.
This is a flaw in Windows and Mac OS X where they fail to differentiate between two similar but different file names.
Odd, I thought it was exactly the opposite. Linux doesn't interpret the names at all. Only '\0' and '/' (in C/C++ notation) are treated specially by Linux in what can be allowed as file name. The rest is just an array of bytes. Is Mac OS X or Windows the ones that try (and I said try, since I'm not sure they achieve it) to protect the user from security and confusion problems. Is not just case sensitivity, think of pre-composed characters, for example (distinguishing modified+character from character already modified). See the interesting conversation after a Git release, where several developers explain the problems on the normalization that Mac OS X does.
And the source being distrowatch, a website for people looking for a distribution. Maybe it confirms that users of Ubuntu don't want to change distro? Or for people who don't even know what a distro is? Or who don't speak English?
Signed: a Debian user who complained a lot about Ubuntu on several levels.
And too slow and a failure as an OO language. I mean, even the designers of C++ warn against complex class hierarchies. How stupid is that?
And the designers of Ruby also suggest that you don't create complex class hierarchies. And the designers of Java created interfaces to avoid complex class hierarchies. Maybe the problem are complex class hierarchies, or trying to solve everything with OOP when you should not?
Odd that of all possible choices, systemd developers chose almost
always a way that is exactly the same or very similar to what Debian does.
For example, I don't see stuff like/etc/sysconfig, while I do see things
like/etc/hostname etc.
Everybody else has/etc/hostname too, sorry to pop your fanspiracy.
Now, as it turns out, more frequently than not we actually adopted schemes
that where Debianisms, rather than Fedoraisms/Redhatisms as best supported
scheme by systemd. For example, systems running systemd now generally store
their hostname in/etc/hostname, something that used to be specific to Debian
and now is used across distributions.
Maybe the example was too subtle, but for sure there are some things from/etc/sysconfig that are gone from Red Hat, and are substituted by
Debian-style configuration.
Most distros are focusing on system d because they simply do not have the resources to do anything else.
This is the sad reality. The Red Hat-isation of the linux world. It's either the Red Hat way or the highway.
And most distros obviously are not chosing the highway.
Odd that of all possible choices, systemd developers chose almost
always a way that is exactly the same or very similar to what Debian does.
For example, I don't see stuff like/etc/sysconfig, while I do see things
like/etc/hostname etc.
Google does an excellent job of catching spam. The submitter's problem isn't that, it's that he's got other numpties giving out his email address and then he's not using the Google-supplied tool (that little "mark as spam" button) to mark unwanted email so that Gmail learns his preferences. Instead, he's Dunning-Krugered together his own solution that barely works.
Submitter's problem is PEBKAC.
Sorry, but I completely agree with the story explained. My previous employer gave me an email address managed by Google Apps. I subscribed and posted to about 3-4 different open source project mailing lists. Obviously that's enough to make your address well known to spammers.
The amount of email in the spam folder was surprisingly high, given that my very personal email address, which has appeared during a decade (not just two years) on online archives of about 20 times more lists, receives a little bit less. But that's not bad. What I found insulting is that they had plenty of false positives. That's the worse kind of error in email filtering: you check your inbox more often, and is not a big deal deleting one additional email a day. But I found email threads of those mailing lists broken when because parts of a thread (just parts of a freaking mailing list thread!) were marked as spam, and was autoexpired (yes, I don't need to check all mailing lists that often). It also marked as spam one reply to an email I sent. A shame.
And yes, I used the "this is not spam" feature, but I got bored. The best I could do was reviewing all the filters to completely skip the spam filtering, which is stupid anyway in many mailing lists that require a legitimate address to subscribe, which yields a very low spam rate (besides the "join me in my linkedin network" that some stupid sent to the whole address book).
You were implying that using a subset of C++ features is not practical because you could "write C++ that is not guaranteed to be maintainable by anybody short of a complete master", which is absurd, because only a complete master could write that kind of unmaintainable code. Well, according to your logic and your subjectivity, there are only a small amount of people capable of that feat. And the fact that there are lots of C++ programs and libraries out there that are maintainable proves it.
Err, the implication is that you can also write C++ that is not guaranteed to be maintainable by anybody short of a complete master, which even Bjarne says he is not. I think it is fair to estimate that the number of complete C++ masters in the world is in the single to double digits; no more. It may be you can identify another programming language for which that holds true. I don't think I can.
You can not even identify one without resorting to factual mistakes. I'm running every day lots of programs written in C++. A simple search on a linux distro reveal thousands of packages in C++. Is that maintained by those "single to double digits" amount of people in the world? Sure.
Well, he has given that answer several times. On his FAQ, he says:
"There are only two kinds of languages: the ones people complain about and the ones nobody uses". Yes. Again, I very much doubt that the sentiment is original. Of course, all "there are only two" quotes have to be taken with a grain of salt.
Any practical example to back it up? Probably there are some cases of that, but the contrary is IMHO more common. One of the most popular C++ library out there, Qt, doesn't make you learn exceptions, and templates are only used for containers, so you rarely see one of those scary compilation errors.
That means that in practice, you see large C++ codebases that are very easy to grasp. At my current workplace, all C++ developers barely understand C++ outside the C subset, and projects work fine from the customer perspective. Do they understand that each time they pass a value to a function they are copying it, and that it can be costly? No, but luckily they are doing that with QByteArray, which is implicitly shared. They don't have to understand the feature. Besides me they don't even know it exists, but it works, and saves the day.
I like the idea how everything is a file etc. That is one reason why I originally became Linux user and now it feels Linux systems have become something totally different by new third/fourth generation "geeks" who don't care anymore about open file system and results are like systemd journalctl.
Funny that you mention that, because systemd exposes lots of features through cgroups and a nice filesystem on/sys. And to use systemd's journal's files, the documentaion already explains that you just open the files, memory map them, and use inotify, a classic notification API on files...
C++ does no garbage collection because C++ developers learn how not to produce garbage in the first place. Use proper mutex lockers, smart pointers or file handles, and you won't leak memory, won't miss freeing locks or file descriptors.
And is not that you need to be a genius to make use of them. Just use, for example, a QFile, or QMutexLocker, and at the end of the scope the resource is freed. Done.
Umm, anyone who wants their code to not run substantially slower. Seriously, do you front end programmers really think nobody does numerical simulations or other performance-sensitive work? In my line of work, I'd kill for the opportunity to make my code 1.5 times faster!
I'm surprised by your answer at so many levels. First, I thought the guys doing scientific calculations were scientists that many times (not always of course) are only used to Matlab, Mathematica or even Excel. Second, obviously we will need native code, as well as interpreted, functional, and lots of code in domain specific areas (what the heck... I spent this Sunday morning writing in VimL, a language so stupid that can't copy a file without reading the whole contents in memory or invoking system(), but I needed to program in that and there is no way around it).
But the final sentence of the article isn't targeted at people doing heavy lifting. Is an "attack" at Google's Native Client (NaCl). I peeked at NaCl, and you needed a some set up and some APIs to run some native code invoked from the browser. ASM.js is way simpler, since is just a subset of JavaScript, and has much more possibilities of being followed by vendors like Opera or even Microsoft.
Oh, and, I do native code for a living, and while I would kill for making my code faster, my manager would kill for making me finish projects earlier.:-) Native code is awesome, but sometimes dumb languages are more business successful if you can use all your developers in a project, including that 50% that, by definition, are below the average.
Heavily refactoring projects of this size rarely brings any benefit for the users, it's just technical masturbation. (...)
Some open source projects would benefit from proper managers who can stop them from shooting themselves in the foot.
You are missing an important point: many people that work on a software project in their spare time do it to have fun. I work as a programmer for a living, and at work I do what my employer wants me to do. I might not like the way I have to do things at work, but I do as my manager says.
If I work on a hobby project to have fun, I want to do things the way that make me happy. It might be the case that you are happy making a killer product that has tons of users, even if the internals are crap. Or it might be the case that you are only happy with something that has a nice architecture and uses bleeding edge technologies, even if that makes the product unstable an unpopular.
I don't know what is the state of Kdenlive and the opinion of Jean-Baptiste Mardelle, but I hope you know better if you make such assumptions about other's projects.
As I understand it, that is not going to happen if you want Google's bless (i.e. their applications and Google Play Services, which are critical for some applications to work). Read Google’s iron grip on Android, especially page 3.
Since the Kindle OS counts as an incompatible version of Android, no major OEM is allowed to produce the Kindle Fire for Amazon. So when Amazon goes shopping for a manufacturer for its next tablet, it has to immediately cross Acer, Asus, Dell, Foxconn, Fujitsu, HTC, Huawei, Kyocera, Lenovo, LG, Motorola, NEC, Samsung, Sharp, Sony, Toshiba, and ZTE off the list. Currently, Amazon contracts Kindle manufacturing out to Quanta Computer, a company primarily known for making laptops. Amazon probably doesn't have many other choices.
Seems like a terrible move against market freedom. Even worse for consumer freedom.
OK, I give up. The fact that you still think that using a string as a vector of bytes is comparable with a class that is capable of understanding the text it stores, with some encoding conversion capabilities, and more, should be a clear enough indication that we don't have the same expectations on what is a class for human text. And the fact that you still try to put words in my mouth signals that it isn't worth wasting time with you.
Read again the thread. You said that MOC is a precompiler (wrong, is a code generator), and that it transforms the input text in ways impossible with C macros (even more wrong).
I said "Is the classic C preprocessor" in response to "these keywords are pre-processed by a special compilation step into C++ code" which is absolutely right.
And you still fail to explain how you can use std::string for text instead of for low level manipulation of the string bytes.
Qt uses the moc precompiler, which is *not* c macros. It does transformations to the input text that is impossible with C macros.
Next time you write about something, use it first, please. MOC is not a precompiler nor "transforms" input text. It generates code. Like a bazillion other tools that generate perfectly standard C++ code.
Only for fools who thought you need 16-bit code units to store a larger character set, rather than a variable-length encoding.
Execellent. That's why everyone is using std::string in i18n-ed text, and why C++11 didn't introduce new string types.
But yes, call people stupid as long as you want. Now you are probably right.
My C++ compiler does not compile signal: or slot: tokens. Qt is not C++ in the same way as Microsoft COM is not C++, even though its mostly built with C++ and MIDL generator spits out C++ boilerplate as an option.
My C++ compiler doesn't compile "#include" either. Because it doesn't have to. You need to run the file through a preprocessor. That's part of the standard, and is unavoidable at this time.
If don't like the use of the C preprocessor, fine. But don't lie saying that is not "standard". It might not be the part of the standard that you like the most, but is standard. And using a tool for generating code is perfectly normal. Or is protobuf no longer a "standard C++" tool?
There is a proof of concept clang plugin that would provide the QObject features without MOC. That doesn't make it better in all use cases, since that would be tied to a compiler.
No, seriosly, one might not like one solution to a problem. But having no solution is worse. If one day there is a better solution, the Qt project will adopt it. But right now there isn't one that fills all the features provided by Qt with the current implementation.
Slashdot Mirror
I got a BB Z10 for free for being a Qt developer and attend a developer event. It was my first BlackBerry, and I am so sorry that I will have to let it go, since I am so not buying a BB device if it's just running Android (If I'll end up buying an Android device, I'll have plenty of choices). Yes, the BB OS 10 interface is a lot better for me than Android. I loved the Nokia N9, and this one was even a tiny step forward, and I'm too used to it after 5 years of happiness. I also used a Jolla for some time, and is the kind of UI where I feel at home.
The way you jump back and forth between applications on Android is really really bad for my taste. I have an Android tablet, and it annoys the hell of me that it shows lots of poor screenshots of applications that I have not opened (e.g. when I just restarted after an upgrade it shows tons of them no really running). Harmattan (Nokia N9), Sailfish OS (Jolla) or BlackBerry OS 10 give a much more useful indication of what the application is/was doing, or additional controls. Besides, you see several of them at a glance, not in a stack view that only shows a tiny slice of the second one and almost nothing of the next ones.
The top shade got one step back in the last major Android release. In an Android tablet, the user had access to different quick controls swiping on the left or the right of the screen: now I have to swipe twice to have quick access to the Bluetooth control, so moving my headset from the phone to the tablet (or vice versa) is a lot faster and convenient in BB OS 10 with respect to Android (they used to be tied in the previous version).
I'm used to not being the typical user (I'm a bit more power user, fine), but seriously, changing from one application to the other (browser to podcast to instant messaging for example) or having quick access to Bluetooth settings is something I would expect done right in 100% of the mobile OSs for this time and age.
Second, if the HTML pages were served under the more secure application/xhtml+xml media type, the compromised page wouldn't have been usable, because the malformed syntax would have produced a fatal error, instead of silently corrected (this is specified in HTML5, which IE supports now, woo).
I think this speaks clearly of how bad was the decision of creating HTML 5, and not making future web documents an XML application only. With XML, the rules clearly state that a document has to be well formed in order to be interpreted by the XML parser (then it can be invalid according to the XML application, say XHTML). But no, they kept the incredibly stupid tradition of making browsers try to recover according to unspecified ways. I wonder how many workarounds are in the parsers of todays web browsers that swallow utterly broken contents that IE6 displayed properly at that time. Workarounds and complicated code paths that will probably stick for a really long time, since old content will not be fixed ever. And complex code paths that will continue to produce security holes from time to time.
Ironically, many (if not all) the usability issues that you mention that C++ could change, are nearly impossible to fix due to the C legacy. But having C as legacy is also a big strength: you can use native OS APIs with ease.
I know plenty of open source applications, from GUIs in Qt and gtkmm to console applications and interpreters of programming languages in C++. The backbone of any Linux distribution is C and C++.
I know 0 packages in my Linux installation that are written in Objective-C. There are some, for sure, but are they widespread? I doubt it.
This is a flaw in Windows and Mac OS X where they fail to differentiate between two similar but different file names.
Odd, I thought it was exactly the opposite. Linux doesn't interpret the names at all. Only '\0' and '/' (in C/C++ notation) are treated specially by Linux in what can be allowed as file name. The rest is just an array of bytes. Is Mac OS X or Windows the ones that try (and I said try, since I'm not sure they achieve it) to protect the user from security and confusion problems. Is not just case sensitivity, think of pre-composed characters, for example (distinguishing modified+character from character already modified). See the interesting conversation after a Git release, where several developers explain the problems on the normalization that Mac OS X does.
And the source being distrowatch, a website for people looking for a distribution. Maybe it confirms that users of Ubuntu don't want to change distro? Or for people who don't even know what a distro is? Or who don't speak English?
Signed: a Debian user who complained a lot about Ubuntu on several levels.
And too slow and a failure as an OO language. I mean, even the designers of C++ warn against complex class hierarchies. How stupid is that?
And the designers of Ruby also suggest that you don't create complex class hierarchies. And the designers of Java created interfaces to avoid complex class hierarchies. Maybe the problem are complex class hierarchies, or trying to solve everything with OOP when you should not?
Odd that of all possible choices, systemd developers chose almost always a way that is exactly the same or very similar to what Debian does. For example, I don't see stuff like /etc/sysconfig, while I do see things
like /etc/hostname etc.
Everybody else has /etc/hostname too, sorry to pop your fanspiracy.
Let me quote from the biggest myths:
Now, as it turns out, more frequently than not we actually adopted schemes that where Debianisms, rather than Fedoraisms/Redhatisms as best supported scheme by systemd. For example, systems running systemd now generally store their hostname in /etc/hostname, something that used to be specific to Debian
and now is used across distributions.
Maybe the example was too subtle, but for sure there are some things from /etc/sysconfig that are gone from Red Hat, and are substituted by
Debian-style configuration.
Most distros are focusing on system d because they simply do not have the resources to do anything else. This is the sad reality. The Red Hat-isation of the linux world. It's either the Red Hat way or the highway. And most distros obviously are not chosing the highway.
Odd that of all possible choices, systemd developers chose almost always a way that is exactly the same or very similar to what Debian does. For example, I don't see stuff like /etc/sysconfig, while I do see things
like /etc/hostname etc.
Google does an excellent job of catching spam. The submitter's problem isn't that, it's that he's got other numpties giving out his email address and then he's not using the Google-supplied tool (that little "mark as spam" button) to mark unwanted email so that Gmail learns his preferences. Instead, he's Dunning-Krugered together his own solution that barely works.
Submitter's problem is PEBKAC.
Sorry, but I completely agree with the story explained. My previous employer gave me an email address managed by Google Apps. I subscribed and posted to about 3-4 different open source project mailing lists. Obviously that's enough to make your address well known to spammers.
The amount of email in the spam folder was surprisingly high, given that my very personal email address, which has appeared during a decade (not just two years) on online archives of about 20 times more lists, receives a little bit less. But that's not bad. What I found insulting is that they had plenty of false positives. That's the worse kind of error in email filtering: you check your inbox more often, and is not a big deal deleting one additional email a day. But I found email threads of those mailing lists broken when because parts of a thread (just parts of a freaking mailing list thread!) were marked as spam, and was autoexpired (yes, I don't need to check all mailing lists that often). It also marked as spam one reply to an email I sent. A shame.
And yes, I used the "this is not spam" feature, but I got bored. The best I could do was reviewing all the filters to completely skip the spam filtering, which is stupid anyway in many mailing lists that require a legitimate address to subscribe, which yields a very low spam rate (besides the "join me in my linkedin network" that some stupid sent to the whole address book).
You were implying that using a subset of C++ features is not practical because you could "write C++ that is not guaranteed to be maintainable by anybody short of a complete master", which is absurd, because only a complete master could write that kind of unmaintainable code. Well, according to your logic and your subjectivity, there are only a small amount of people capable of that feat. And the fact that there are lots of C++ programs and libraries out there that are maintainable proves it.
Err, the implication is that you can also write C++ that is not guaranteed to be maintainable by anybody short of a complete master, which even Bjarne says he is not. I think it is fair to estimate that the number of complete C++ masters in the world is in the single to double digits; no more. It may be you can identify another programming language for which that holds true. I don't think I can.
You can not even identify one without resorting to factual mistakes. I'm running every day lots of programs written in C++. A simple search on a linux distro reveal thousands of packages in C++. Is that maintained by those "single to double digits" amount of people in the world? Sure.
Well, he has given that answer several times. On his FAQ, he says:
Any practical example to back it up? Probably there are some cases of that, but the contrary is IMHO more common. One of the most popular C++ library out there, Qt, doesn't make you learn exceptions, and templates are only used for containers, so you rarely see one of those scary compilation errors.
That means that in practice, you see large C++ codebases that are very easy to grasp. At my current workplace, all C++ developers barely understand C++ outside the C subset, and projects work fine from the customer perspective. Do they understand that each time they pass a value to a function they are copying it, and that it can be costly? No, but luckily they are doing that with QByteArray, which is implicitly shared. They don't have to understand the feature. Besides me they don't even know it exists, but it works, and saves the day.
I like the idea how everything is a file etc. That is one reason why I originally became Linux user and now it feels Linux systems have become something totally different by new third/fourth generation "geeks" who don't care anymore about open file system and results are like systemd journalctl.
Funny that you mention that, because systemd exposes lots of features through cgroups and a nice filesystem on /sys. And to use systemd's journal's files, the documentaion already explains that you just open the files, memory map them, and use inotify, a classic notification API on files...
Is there anything it cannot do?
Garbage collection.
C++ does no garbage collection because C++ developers learn how not to produce garbage in the first place. Use proper mutex lockers, smart pointers or file handles, and you won't leak memory, won't miss freeing locks or file descriptors.
And is not that you need to be a genius to make use of them. Just use, for example, a QFile, or QMutexLocker, and at the end of the scope the resource is freed. Done.
Umm, anyone who wants their code to not run substantially slower. Seriously, do you front end programmers really think nobody does numerical simulations or other performance-sensitive work? In my line of work, I'd kill for the opportunity to make my code 1.5 times faster!
I'm surprised by your answer at so many levels. First, I thought the guys doing scientific calculations were scientists that many times (not always of course) are only used to Matlab, Mathematica or even Excel. Second, obviously we will need native code, as well as interpreted, functional, and lots of code in domain specific areas (what the heck... I spent this Sunday morning writing in VimL, a language so stupid that can't copy a file without reading the whole contents in memory or invoking system(), but I needed to program in that and there is no way around it).
But the final sentence of the article isn't targeted at people doing heavy lifting. Is an "attack" at Google's Native Client (NaCl). I peeked at NaCl, and you needed a some set up and some APIs to run some native code invoked from the browser. ASM.js is way simpler, since is just a subset of JavaScript, and has much more possibilities of being followed by vendors like Opera or even Microsoft.
Oh, and, I do native code for a living, and while I would kill for making my code faster, my manager would kill for making me finish projects earlier. :-) Native code is awesome, but sometimes dumb languages are more business successful if you can use all your developers in a project, including that 50% that, by definition, are below the average.
Heavily refactoring projects of this size rarely brings any benefit for the users, it's just technical masturbation. (...)
Some open source projects would benefit from proper managers who can stop them from shooting themselves in the foot.
You are missing an important point: many people that work on a software project in their spare time do it to have fun. I work as a programmer for a living, and at work I do what my employer wants me to do. I might not like the way I have to do things at work, but I do as my manager says.
If I work on a hobby project to have fun, I want to do things the way that make me happy. It might be the case that you are happy making a killer product that has tons of users, even if the internals are crap. Or it might be the case that you are only happy with something that has a nice architecture and uses bleeding edge technologies, even if that makes the product unstable an unpopular.
I don't know what is the state of Kdenlive and the opinion of Jean-Baptiste Mardelle, but I hope you know better if you make such assumptions about other's projects.
Yes, I saw that earlier this morning, but I wonder how legal is that, and how easily you can be blocked by Google. I doubt is a solution for a vendor.
As I understand it, that is not going to happen if you want Google's bless (i.e. their applications and Google Play Services, which are critical for some applications to work). Read Google’s iron grip on Android, especially page 3.
Seems like a terrible move against market freedom. Even worse for consumer freedom.
OK, I give up. The fact that you still think that using a string as a vector of bytes is comparable with a class that is capable of understanding the text it stores, with some encoding conversion capabilities, and more, should be a clear enough indication that we don't have the same expectations on what is a class for human text. And the fact that you still try to put words in my mouth signals that it isn't worth wasting time with you.
Luckily enough that people admit that you should use a Unicode library, because even C++11 supports Unicode terribly, and there is work underway to improve it. Meanwhile, I'm happy to have QString. And I'll be happier if with Qt6 there is a type that can replace it.
Read again the thread. You said that MOC is a precompiler (wrong, is a code generator), and that it transforms the input text in ways impossible with C macros (even more wrong).
I said "Is the classic C preprocessor" in response to "these keywords are pre-processed by a special compilation step into C++ code" which is absolutely right.
And you still fail to explain how you can use std::string for text instead of for low level manipulation of the string bytes.
Qt uses the moc precompiler, which is *not* c macros. It does transformations to the input text that is impossible with C macros.
Next time you write about something, use it first, please. MOC is not a precompiler nor "transforms" input text. It generates code. Like a bazillion other tools that generate perfectly standard C++ code.
Only for fools who thought you need 16-bit code units to store a larger character set, rather than a variable-length encoding.
Execellent. That's why everyone is using std::string in i18n-ed text, and why C++11 didn't introduce new string types.
But yes, call people stupid as long as you want. Now you are probably right.
Thanks for the hint, but I've found the Wikipedia page on it (and the first results on the web) not very exciting. However, Software for Infrastructure from Stroustrup has a really cool example on how to do it very pretty. It uses user-defined literals to create expressions such as "Speed s = 10m/2s".
My C++ compiler does not compile signal: or slot: tokens. Qt is not C++ in the same way as Microsoft COM is not C++, even though its mostly built with C++ and MIDL generator spits out C++ boilerplate as an option.
My C++ compiler doesn't compile "#include" either. Because it doesn't have to. You need to run the file through a preprocessor. That's part of the standard, and is unavoidable at this time.
If don't like the use of the C preprocessor, fine. But don't lie saying that is not "standard". It might not be the part of the standard that you like the most, but is standard. And using a tool for generating code is perfectly normal. Or is protobuf no longer a "standard C++" tool?
There is a proof of concept clang plugin that would provide the QObject features without MOC. That doesn't make it better in all use cases, since that would be tied to a compiler.
No, seriosly, one might not like one solution to a problem. But having no solution is worse. If one day there is a better solution, the Qt project will adopt it. But right now there isn't one that fills all the features provided by Qt with the current implementation.