271–280 of 353 posts
Earlier quoted context omitted.
Given the Mesa/Cedar system a Xerox PARC, Oberon at Swiss Federal Institute of Technology and Modula-3/SPIN at Olivetti, doing OS work in GC enabled systems programming languages is quite possible. The problem is how to move OS vendors away from C's influence.
Use micro-kernels.
Earlier quoted context omitted.
Don't forget D
D is fine language and a pleasure to program in, but with it's required garbage collector, it's not really in the same niche as C/C++/Rust. I think the hallmark of this niche is the ability to run without a garbage collector penalty and the accompanying lack of determinism.
Earlier quoted context omitted.
Too bad it's a mirage I hate to spoil your worldview, but modern C++ is very alive and well in the scientific computing communities. Disney Animation implemented a new renderer using it, and our next movie is currently being rendered using the new renderer, so I highly doubt it's on its way out in the these areas.
How much time/money did it take to be implemented? What is the maintenance cost? Which version of C++? What percentage was written from scratch? Does it run in a networked environment? These are the real questions. Pharao Inc. built pyramids in ancient Egypt. It cost many lives of slaves but it was cheap them. Nowadays we make big buildings without slaves.
And hey, don't knock the Pharaohs!
First off, it's been known for some time that the Pyramids were built by paid workers:
http://www.boston.com/news/world/middleeast/articles/2010/01...
(Literate too, since they left graffiti)
http://www.bbc.co.uk/history/ancient/egyptians/pyramid_build...
The conditions that migrant workers endure building World Cup facilities in Qatar seem to be worse than those endured by Egyptian construction workers:
http://www.theguardian.com/world/2014/may/14/qatar-admits-de...
Earlier quoted context omitted.
Comparing to Python or Haskell, maybe you're right, but not to CLR-based or JVM-based statically typed languages. Very often the differences between Java/C# and C++ are the same order of magnitude as differences between various C++ compilers. The mythological C++ performance is often overstated (there are some performance advantages in C++ but they are rarely big enough to justify language choice).
I think C++ is justified when you're constrained by CPU, RAM, or other resources. That is, if the limiting factor is development speed, or network traffic, or waiting for user input, then C++ probably isn't going to be worth it. But if in your problem area you can get a competitive advantage by being faster, using less memory, or tightly controlling other resources, then C++ is probably the right choice. If you reall…
Earlier quoted context omitted.
While a bit harsh sounding, this is actually spot on. What I write nowadays vs 5 years ago: hard to believe it is the same laguage.
Exactly. I only write greenfield C++ and I dig it a whole bunch.
Earlier quoted context omitted.
Too bad it's a mirage. No, really. "Modern C++" doesn't exist outside of blog posts, books, and tutorials. Real-world C++ is an array of sometimes mututally-exclusive dialects, patterns, rules, sub-dialects. Reading MFC is nothing like reading Qt which is nothing like WxWidgets which is nothing like Boost which is something (but not quite like) the STL which is way different from Apache C++ libs which is way differen…
So "Modern C++" is a mirage, but Rust and Go are the surefire winners? Do you have any substance to add to your post? I don't know, I've been writing C++ for about a decade and the code I write is "modern" as far as I can tell. I just started a new project. It is C++, it is "modern", and Rust and Go simply aren't options. Rust is an infant and not yet ready for prime time, and Go simply wouldn't be considered by mana…
Why does the "pool of talent" even matters?
Earlier quoted context omitted.
Yes, RAII is the only way to make an exception-safe class. Good luck doing it. It's not easy. I know; I've tried. There are all kinds of corner cases and special considerations that you have to take into account. People have written huge tomes about that exact topic detailing exactly why it's a hard problem and why you're probably not going to solve it correctly by accident. You're far more likely to introduce a memo…
"Good luck doing it. It's not easy. I know; I've tried" Completely unsupported assertion (no pun) without evidence. Other people have tried it, and have succeeded. I could start listing all the software written in C++ that you use in your everyday life, perhaps 100's of times a day... but that'll quickly exhaust my word limit for this post. "That's why C++ is overly cumbersome unless you ignore most of its capabiliti…
Have a look at Tarsnap's source code.
Earlier quoted context omitted.
How can you not use manual memory management in C++? Say you're writing a compiler, which uses a quite complex, possibly circular, graph structure of objects for its AST representation. You can't use SharedPtrs (cycles), can't use UniquePtrs (sharing of graph nodes), can't use RAII (unpredictable lifetime). I see no better solution than a GC.
Even Stroustrup says that there are times garbage collection is the right solution. But, some people are surprised that there are times it isn't needed, and that garbage collection always brings the burden on unordered finalization (e.g., it's possible for an object's members to be finalized before the object, so finalizes must be written in a way that assumes very little about what is valid regarding data members).
Modula-3 generics are good enough to even implement reference counting data structures.
The going VM craziness of the last two decades pushed such languages away from the mainstream and thus younger generations get surprised by such approaches.
Earlier quoted context omitted.
Comparing to Python or Haskell, maybe you're right, but not to CLR-based or JVM-based statically typed languages. Very often the differences between Java/C# and C++ are the same order of magnitude as differences between various C++ compilers. The mythological C++ performance is often overstated (there are some performance advantages in C++ but they are rarely big enough to justify language choice).
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…
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 statically typed, and known to be much harder to optimize for speed than e.g. pure old Java.
Earlier quoted context omitted.
Given the Mesa/Cedar system a Xerox PARC, Oberon at Swiss Federal Institute of Technology and Modula-3/SPIN at Olivetti, doing OS work in GC enabled systems programming languages is quite possible. The problem is how to move OS vendors away from C's influence.
Use micro-kernels.