I do systems programming and I use C++ a lot. It's perfect for that. Anyone who does systems or embedded stuff will tell you how wonderful C++ is over the alternatives.
C++11 Makes Competitors Go Rusty
51–60 of 69 posts
Re: C++11 Makes Competitors Go Rusty
#52How many people here who complain about the language being too complicated have actually been harmed by the presence of features in the language? If you want an advanced programming language, it's going to be complicated. Without garbage collection, it will be even more complicated. Almost every feature that exists in C++ exists for a reason, and every one that was added or removed in C++11 was added or removed for g…
No offense, but have you spent much time with Go or Rust? In most cases Go's performance difference isn't extremely divergent from C++'s and it preserves safety and enhances convenience, exceptions and adds concurrency.
Go afaict does more than preserve safety, it improves it! And it enhances convenience. Concurrency in C++ works just fine, though.
Re: C++11 Makes Competitors Go Rusty
#53Your freaking enormous ball of mud accreted some more mud. Quelle surprise . It's probably doing it by sheer gravitational attraction at this point. I do not think that removes the need for languages that have the capabilities of C++, yet aren't freaking enormous balls of mud. The reader may mentally replace my use of the word "freaking" with other choice terms at his or her discretion.
Any useful language is a freaking enormous ball of mud. Bjarne said: there are only two kinds of languages - the ones people complain about and the ones nobody uses.
Stroustrup is right, but that doesn't prove your point. Every language will have detractors, but not every language will be the target of every particular complaint. Lua, for example, is a useful language and it has largely avoided being a ball of mud.
Naturally, that minimalism brings its own set of issues and complaints. But the point is, you don't need to be as much of a ball of mud as C++ in order to be useful or successful. I think a lot of language partisans, and C++ partisans in particular, point to Stroustrup's quote as an excuse for their language's warts. It's true that no language can ever be perfect, but that doesn't mean that all complaints are without merit and unworthy of attention and consideration.
Re: C++11 Makes Competitors Go Rusty
#54Earlier quoted context omitted.
I was more thinking iOS and Android. Though I haven't investigated weather or not it could use the NDK.
Ah, my mistake. I know that you can build ARM binaries with Go, you ought to be able to invoke those from the NDK. /r/golang had a link to this a while back, re: Go on iOS: https://groups.google.com/group/golang-dev/browse_thread/thr... Looks like the iOS port requires a bit of work on cgo support for arm/linux before a proper iOS app can be made. Without the cgo shim it seems the app can't run more than 10 seconds,…
Thanks I hadn't realized they had gotten so far.
Re: C++11 Makes Competitors Go Rusty
#55Your freaking enormous ball of mud accreted some more mud. Quelle surprise . It's probably doing it by sheer gravitational attraction at this point. I do not think that removes the need for languages that have the capabilities of C++, yet aren't freaking enormous balls of mud. The reader may mentally replace my use of the word "freaking" with other choice terms at his or her discretion.
Any useful language is a freaking enormous ball of mud. Bjarne said: there are only two kinds of languages - the ones people complain about and the ones nobody uses.
I can not think of a cognitively bigger language than C++. And I mean language, not library set or anything like that, but literally, what the syntactic constructs are, how they are defined, and in particular how they end up interacting with each other. I often wonder how many of the C++ defenders could actually answer detailed questions about it, or how much of the code they write would actually deeply, deeply surprise them with what memory allocation bugs are lurking, how much indirection there really is, or how many implicit copies of things they are making if they really took the time to step through the assembly language version. Or how many of them could bang out a decently accurate summary of the new official memory model, let alone how it might interact with all of the other features of C++. Or for real bonus points, successfully use it without introducing enormous numbers of things that are, technically, errors, but it so happens you never run into them at runtime.
Non-zero, I'm sure, but I bet single-digit percentages, tops. Except that last one, which I'd put money on sub-1%.
What are the odds that C++, as a fairly extreme outlier, is actually closer to optimal for the general purpose tasks it is used for than all the other languages?
Re: C++11 Makes Competitors Go Rusty
#56Earlier quoted context omitted.
Last I heard the Go compiler was generating code 6x or more slower than comparable C++ code. Is that not still true?
You heard wrong: http://blog.golang.org/2011/06/profiling-go-programs.html
The graphviz / svg output from the profiler shown there is very nice. Does something similar exist for other languages? I particularly like the scaling of the node size by the appropriate value (CPU time, memory use, etc).
Re: C++11 Makes Competitors Go Rusty
#57Earlier quoted context omitted.
Can I just trade in my exceptions for Maybe or Either? It's already possible to do both of these things, the trouble is that I have to use other people's code that uses exceptions.
Except the C++ dragon rears its head. How do you build an intelligent Maybe or Either type in C++? Should they be value types containing unions? You can’t use “non-trivial” types in unions till C++11, and a lot of people haven’t yet upgraded. Referential types with dynamic allocation? How do you transfer ownership? Are “Left” and “Right” subtypes of “Either”? It’s ridiculous.
The choices are clear for every situation you describe.
Re: C++11 Makes Competitors Go Rusty
#58I like and use C++. It fits my requirements of allowing high performance but still having rich abstractions. I also like most of the additions in C++11, and I look forward to using them. But, there is a valid argument for using a newer language that has nothing to do with the language itself: the ancient include, compile and link process. Having to do the #ifndef/#define/#endif dance in every header file I write is a…
> Having to do the #ifndef/#define/#endif dance in every header file I write I'm just using "#pragma once" in my current hobby C++ project. I understand pragmas are living in sin, but is there any reason I shouldn't use them?
gcc 3.x had #pragma once bugs related to symbolic links. MSVC had bugs related to filenames that only differed by case. Modern gcc and MSVC can recognize and optimize for the #include guard pattern. Many benchmarks show no build time improvement of traditional #include guards vs #pragma once.
I some one benchmark where the developer #included all his headers and source files into a single .cpp file. Compiling this single .cpp file was about 50x faster than a traditional build! <:) Of course, you will likely have name and dependency conflicts.
Re: C++11 Makes Competitors Go Rusty
#59Earlier quoted context omitted.
You heard wrong: http://blog.golang.org/2011/06/profiling-go-programs.html
The graphviz / svg output from the profiler shown there is very nice. Does something similar exist for other languages? I particularly like the scaling of the node size by the appropriate value (CPU time, memory use, etc).
Go's pprof is based on the C-based one: http://code.google.com/p/gperftools/
Re: C++11 Makes Competitors Go Rusty
#60Compatibility: The new language will have to talk with older languages. Types will have to be translated; memory models will need to be aligned and compilers will need to 'play nice' together. This is not just as the compiled object level but at the ABI level during linking etc. I've spent more time solving issues with memory models in C++ than I have in any other language because C++ has no ABI - I've had patches to…
I'd like to upvote twice, but it wouldn't let me. So it's cruel, but I usually secretly assume that people who keenly advocate C++ are just poseurs. Anybody who has actually gone through the whole process of making a program in C++ and fixing enough of the bugs in it that somebody can put it in a box and sell it in the shops, is appropriately circumspect in their recommendations, because they know just how appallingl…
Amen! There are good reasons why Google's [1] and Mozilla's [2] C++ style guides frown on C++ features like exceptions, RTTI, iostreams, and static objects.
I read an anecdote that Bill Joy has a "copy of Bjarne Stroustrup's The C++ Programming Language in which he's highlighted all the sections that Java programmers don't need to concern themselves with." I wonder what a C++-compatible subset language would look like if someone just deleted code from a C++ grammar. Rather than writing style guides and lint scripts, just whittle down a C++ compiler's front-end. :)
[1] https://google-styleguide.googlecode.com/svn/trunk/cppguide....
[2] https://developer.mozilla.org/index.php?title=en/C%2B%2B_Por...