321–330 of 353 posts
Earlier quoted context omitted.
Fairly common programming language convention as well. I believe FORTRAN 66 and ALGOL 68 were the first standards widely referred to with a revision year. More recent examples include Fortran 90 (no more caps!) and C99.
I agree but it seems like newer languages adopted the 1.0, 2.0 versioning scheme so it might throw some people off.
Earlier quoted context omitted.
> Being careful is not enough. UTF32 will not help you much with that, save that you've got a separate type for "strings" and "bunch of bytes" Which you can have anyway, so do that, it's a good idea which doesn't require using UTF32. > But UTF-8 for in-memory strings has a long track record of being much harder to actually do correctly. As if other in-memory encodings had a better track record.
Nobody's ever accidentally tried to uppercase a UTF-32 string by passing each code point to C's toupper() function; but that constantly shows up in projects using UTF-8 for in-memory strings. And it's not always caught by unit tests. People never accidentally pass a UTF-32 string to a legacy API that expects char*'s in Latin1 encoding. I when I say "never" I don't mean "almost never happens"; I mean literally "anybod…
Earlier quoted context omitted.
Nobody's ever accidentally tried to uppercase a UTF-32 string by passing each code point to C's toupper() function; but that constantly shows up in projects using UTF-8 for in-memory strings. And it's not always caught by unit tests. People never accidentally pass a UTF-32 string to a legacy API that expects char*'s in Latin1 encoding. I when I say "never" I don't mean "almost never happens"; I mean literally "anybod…
I will repeat, since you apparently managed to miss it last time around: using your type system does not require using UTF32 as your internal string encoding. Hell, you don't even need a type system to have separate bytes and string types, you can even do that in dynamically typed languages, regardless of the string type's internal encoding (it could even be variable, within a single string).
I realize I won't convince you. That's what I meant in the original comment that I know many people disagree with me on this.
Earlier quoted context omitted.
Not even 4 weeks worth of semi-productive self-learning? That sounds quite pathetic. There must be something else, like fear of the unknown, risk aversion, "nobody got fired for choosing IBM"…
I know consulting companies that bill the customer the hours developers spend getting up to speed with a given technology. In the cases the customer is not willing to pay, developers get asked to learn off work hours, if they want to stay on the project.
Earlier quoted context omitted.
Nobody's ever accidentally tried to uppercase a UTF-32 string by passing each code point to C's toupper() function; but that constantly shows up in projects using UTF-8 for in-memory strings. And it's not always caught by unit tests. People never accidentally pass a UTF-32 string to a legacy API that expects char*'s in Latin1 encoding. I when I say "never" I don't mean "almost never happens"; I mean literally "anybod…
> With UTF-32, you don't have to worry about copying less than a full code point to a destination string But you can still copy only parts of a grapheme cluster. If you want to do Unicode right, you have to treat even UTF-32 as a variable-length coding.
Earlier quoted context omitted.
I will repeat, since you apparently managed to miss it last time around: using your type system does not require using UTF32 as your internal string encoding. Hell, you don't even need a type system to have separate bytes and string types, you can even do that in dynamically typed languages, regardless of the string type's internal encoding (it could even be variable, within a single string).
I didn't miss it. I simply know projects that use UTF-8 for in-memory strings, and none of the ones I'm familiar with uses a different type for it. It's all convention, and they all occasionally find that somebody flubbed the convention. Can you point me to any projects that manipulate UTF-8 encoded in-memory strings and actually use a different type for it them? I realize I won't convince you. That's what I meant in…
Glib seems to.
https://developer.gnome.org/glib/2.37/glib-Strings.html
Though in complete fairness the type appears to be just a "bags of bytes" type and so could hold anything, it's really meant to hold UTF-8 (as you can tell from the functions that append/prepend Unicode chars).
Earlier quoted context omitted.
What were these corner cases and special considerations you ran into? I wouldn't call Herb Sutter's _Exceptional C++_ a huge tome and it seems to be the standard treatment of exception safety.
It's 240 pages of knowledge that you can completely do without, and it's a book called "47 engineering puzzles." The puzzles, of course, are entirely exception-related. I'm not saying it's impossible to write exception safe code. I'm saying that you can write code without exceptions without being worse off for it.
So I'm curious about why you think RAII makes writing exception-safe code difficult?
Earlier quoted context omitted.
My point is that none of the features are modern. Comparing a later version of language to an earlier one to measure modernism seems rather pointless.
>Comparing a later version of language to an earlier one to measure modernism seems rather pointless. C++ is a production ready systems language, not a theoretical CS research paper. How do you propose we define modern in this context then? As I'm sure you're aware, it takes years to vet design features, debate whether they can be implemented, whether they affect performance, whether they have unintended side-effects…
Lambdas have been understood for many many years, the same goes for GC. The were not only in the domain of academia.
Common Lisp has many of these features and more, being a multi-paradigm programming language. And has been used in industry for many many years. Yet people say CL is antiquated while it has so called 'modern' features.
Earlier quoted context omitted.
An order of magnitude is a hell of a lot. I did some extensive comparisons of C++, Java, and C# back when I was working on my dissertation. Admittedly, this was about 10 years ago now, but at the time, the best I could get with Java was about a factor of 2.5 slower than C++. C# was similar, but I don't recall the specifics now. When you read a language shootout, a lot of times a factor of 2-2.5 times slower than C or…
A factor of two difference is something that can be a result of using different C++ compilers or even different versions of the same compiler. See this: http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/ Particularly the comments section contains various results obtained from different compilers / versions. Variablility is higher than 2x for GCC. Comparing with Clojure is not fair, because it is not really sta…
The link is fine, but only shows micro-benchmarks. It's much easier to get a 3x difference in execution speed between compiler versions when you have a three-line example -- you're maybe exercising 5% of the optimizer?
The current version of the C++ I was using comes in at around 50kloc. The Java and C# versions were a bit smaller, since once I stopped testing the platforms, all the new code only went into the C++ version, but it's a significant piece of work. I haven't seen any significant real application for which the theoretical benefits of Java (JIT's profile-guided optimizations, etc.) have really come to pass. You can write slow C++ code, but if you know what you're doing and instrument carefully, there's very little or no evidence that Java can be as fast on real programs.