Slashdot Mirror
GCC Moving To Use C++ Instead of C
An anonymous reader writes "CodeSourcery's Mark Mitchell wrote to the GCC mailing list yesterday reporting that 'the GCC Steering Committee and the FSF have approved the use of C++ in GCC itself. Of course, there's no reason for us to use C++ features just because we can. The goal is a better compiler for users, not a C++ code base for its own sake.' Still undecided is what subset of C++ to use, as many contributors are experts in C, but novices in C++; there is a call for a volunteer to develop the C++ coding standards."
Either that, or could we be about to see the beginning of a gcc/llvm compiler arms race?
I'm guessing that only the C++ compiler part will be written in C++. Sort of an Ouroborus.
One of the reasons for gcc being in C for so many years is that it was easier to get a bootstrap c compiler running on a given platform to compile the full gcc toolchain, but I would guess that a C++ compiler was not that important to those people anyways, but it still begs the question.. how do you get a C++ compiler working on a platform that doesn't have one?
If you need web hosting, you could do worse than here
We have to pick through the preprocessor output to find the broken bits.
Although I am not a contributor (for now at least, maybe), I want to follow how the developers will transition from C to C++. I mostly use C at work but I want to learn C++ as well. However, most of the time, I'd rather code in C than in C++ because I am that uncomfortable with it. Maybe the last time I used it is back in college, and that translates to not knowing much of it at all.
AC you got that right! C++ is macro for programmers that don't grok struct and pass by ref
It's not a horrible language if you take into account it's requirements. C++'s requirements are horrible and make it the monster it is. It has to have all the low-levelness of C with all the high level goodness of a modern OO language. Languages like Java, C#, Ruby, etc.. all have the advantage of not having to be a low-level language as well. While OS's have been written in languages like Pascal (original MacOS for instance and early versions of Windows) those were also largely custom compilers that added low-level functionality to the language.
So basically, C and C++ are unique in that they are required to be systems languages as well as applications languages. This makes both of them quirky to say the least.
If you need web hosting, you could do worse than here
considering he sustained that C++ is utter crap and that is why he didn't use it to develop git.... I just long for his rants... ^_^
How do you compile a compiler written in the language it compiles...
Admit nothing. Deny Everything. Make Counter-accusations.
Great idea! This will surely help steal back users from LLVM/clang. The reason people are jumping ship is because they want a compiler written in C++, it has nothing to do with performance, licenses and/or features. Just thinking about those crunchy templates, page up and page down, makes my mouth water. I can't even begin to comprehend how they ever got anything done without templates.
Oh, it's got its pros and cons, just like any language. At least with C++, you can point at any given piece of the language, and whether or not you like that piece, understand why it was designed that way. At least with C++, there are rational explanations for why it is the way it is. If C++ is the worst thing you've ever used then I strongly suggest trying to do something nontrivial in AppleScript; C++ will seem pretty awesome after that. :)
To paraphrase Einstein:
Make things as simple as possible, but not simpler.
IMHO, one should use as high level language as possible, but not higher. One should never choose a lower level language than necessary only because it is hard core, the choice has to be based on something more substantial.
I've met several C programmers having the knee-jerk reaction when they hear the word C++ that it's bloated and slow and hard. And tell me what, they haven't read Stroustrup's FAQ lately. C++ can be very lean and mean indeed. As can C# (which I'm mostly using right now).
The headline says "Use C++ instead of C" which is incorrect. C++ is, as made obvious from the text, an option, not a requirement.
Will this feed through to things like AVR-GCC for Atmel AVR 8-bit microcontrollers?
I wonder what changes in performance we would see.
http://winavr.sourceforge.net/
Are they seriously trying to suggest that the people who work on developing and maintaining a C++ compiler are novices in C++??
Sorry , am I missing something here?
Looking at the GNU Coding Standard which is used for gcc, whatever 'best practices' and style guideline they come with will make a good fireplace material ...
C++ is also required to be more-or-less compatible with C, and with various different pre-standard dialects of C++, which both prevents removing some of unpleasant parts, and means that new features have often had to be added in fairly baroque forms.
I 100% agree. A compiler would benefit very little by being moved to C++. Any "OO" use would be almost exactly single instance, and templates wouldnt be part of the subset they would allow. So what, the stream operators? sigh.
"His name was James Damore."
I would call the "high level" part a goodness. It's overly complex, making it too complex to understand, and hard to read and write code. C is already hard, but this is because of the low level part which you can't go without, and C++ just makes it insane.
And some language decisions are troubling. Abusing left and write shift with streams? I nearly puke when I see code like that. Couldn't they just have a 'write' and 'read' methods? It's confusing as to whether the code is doing shifts, or writes, or what, making it hard to read.
Template metaprogramming? Macros were already a way to make everything horrible, now there are even more things that allow you to do this. While it is a useful feature, any template code is nearly incomprehensible.
References for me are just more complicated pointers that only make code even harder to understand. And if you're doing high-level OO programming you should be avoiding using such constructs, just pass or return an object that carries the required information. Returning values through arguments like that is a bad idea, like all the things that references allow you to do. f(x) changing the value of x is a completely unexpected and surprising result for me. In C at least it had to be f(&x). Not to mention the use of & for references confuses the hell out of me.
Everything new, including the good things, like == overloading, and the way they are implementing, contributes to the extreme complication and insanity of C++.
C++ is the most horrible Object Oriented system you could add on top of C. Even Objective-C is better.
For this kind of job, C++ really is better than C. One of C++'s goals was to standardise things people were doing in C anyway (eg OOP). The advantage of C++ is that the compiler writes all the boilerplate for you. Not only that, but it does it right every single time. Every line of code you don't write is one that does not have a bug.
The main problem is that it is easy to write a basic C compiler and thereby bootstrap a system. With GCC's cross-compiler abilities, this is less of a problem than it might otherwise be, since bootstrapping can always be done on an exitsing, supported platform.
The other solution is for the GCC developers to open up the middle end (like LLVM has done). This would allow one to relatively easily target the compiler to output C, and even a very simple subset thereof, making the bootstrapping process easy. I appreciate their reasons for not wanting to make this easy: they want to prevent proprietary front ends making a mockery of the GPL. I personally think that in this case, they have gone in the wrong direction, and opening up the middle end would yield far more open, copyleft compiler front ends.
Kind of like FUSE has done for filesystems. Sure, it is easier to write a proprietary filesystem than it has ever been for linux. But it is also vastly easier to write free ones too. The end result is that there are far more Free (tm) and interesting filesystems than there ever were.
So, I think in this case that by making lift harder for developers, they have done a bit more damage than would have been caused by accidently making life easier for proprietary developers.
But, that's my $0.02. And I'll keep supporting GCC, not LLVM because it is GPL. I don't want to see the return of the bad old days of code full of #defines written to work around missing features and bugs in 100 different, bad vendor compilers.
SJW n. One who posts facts.
C++'s requirements are horrible and make it the monster it is
I don't think you are right there. I used to be very sceptical about C++, but I have had to develop some tools with it recently, and my respect for it has grown a good deal.
It is true that C++ programs can be real horrors to maintain and even to write, but I think the problem often lies with the design of the toolset used. That and the fact that C++ operates on a higher level of abstraction and therefore requires much more careful consideration and planning. The problems I have seen in the past have all been centered around people not quite understanding the nature of C++ and wanting to immediately put all those bright new features to "good" use, by overloading everything and indiscriminately inheriting from any number of classes.
The secret to good programming has always been to keep it simple - this is twice as important in C++, and the language has some great features for doing so, but you really have to understand what it is you are trying to achieve.
So, a library? Really? Think about it.
"His name was James Damore."
Here's somme ammo from bash.org:
In Soviet Russia, our new overlords are belong to all your base.
They'll implement the new machine code generation routines in C++ just like now, and then cross compile gcc.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
$ g++ -v /usr/lib/gcc/i486-slackware-linux/4.3.3/specs ../gcc-4.3.3/configure --prefix=/usr --libdir=/usr/lib --enable-shared --enable-bootstrap --enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose --with-arch=i486 --target=i486-slackware-linux --build=i486-slackware-linux --host=i486-slackware-linux
Reading specs from
Target: i486-slackware-linux
Configured with:
Thread model: posix
gcc version 4.3.3 (GCC)
That looks like gcc to me
Maybe while they're at it, they can add in actually-useful error messages. See http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html for some examples. It's shocking how user-hostile GCC is in comparison.
The GCC guys are not going crazy here. They are discussing what subset of C++ to allow.
If you use all the wild features of C++, the results could be scary. For example, operator overloading is great if used judiciously, but if used badly it can make the code a mess. And if it is used at all, then it means that you can't look at one page from a printout and know for sure what that code does; you need to look at all the class functions to make sure there aren't tricky overloaded operators.
I use plain C all the time at work, and the top C++ feature they should be using is simply the object-oriented class stuff. With a single global namespace you need to make functions like MyClassAddFloatAndInt(), but in C++ you could just call that function add(); it would be part of MyClass, and if you have other "add" functions with other type signatures, they won't collide. They could go from:
{
MyClass m;
MyClassInitialize(&m, foo, bar);
MyClassAddFloatAndInt(&m, 3.0f, 2);
MyClassDoSomething(&m);
MyClassCleanup(&m);
}
to:
{
MyClass m(foo, bar);
m.add(3.0f, 2);
m.do_something();
}
Even better if they allow the use of C++ namespaces to keep a large project organized.
The other major win that comes to mind is simply being able to use powerful C++ libraries like the STL. Not having to cook up some kind of container data structure in plain C, but being able to use std::vector<SomeType> and std::map<SomeType, OtherType> and such is a huge win.
P.S. I read through much of the discussion and here was my favorite post:
http://gcc.gnu.org/ml/gcc/2010-05/msg00757.html
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Because ObjectiveC is a slow shit?
Seriously, it might be OK for designing GUI interfaces, its dynamic nature helps there. But for compiler writing I'd prefer something:
1) Fast.
2) Typed.
3) Deterministic (no non-deterministic GC).
Maybe they've admitted that 'pride' is holding them back and that being able to use STL (for example) is a greater good than being able to do an initial compile on some obscure microcontroller which has a barely functioning C compiler.
No sig today...
I have a Caldera OpenLinux T-shirt from back in the day. I still wear it around once a week (because it's the only linux tshirt I have)
"Freedom in the USA is not the ability to do what you want. It is the ability to stop others from doing what THEY want"
That and the fact that C++ operates on a higher level of abstraction and therefore requires much more careful consideration and planning.
Planning... so you plan, then write, and you are done? This is a project that is expected to live for decades. The requirements change.
If you need more planning, that's a bad sign.
The problems I have seen in the past have all been centered around people not quite understanding the nature of C++ and wanting to immediately put all those bright new features to "good" use, by overloading everything and indiscriminately inheriting from any number of classes.
Yes. Expect it to happen, despite any efforts to resist. This is the nature of a project with more than one developer.
The secret to good programming has always been to keep it simple - this is twice as important in C++, and the language has some great features for doing so, but you really have to understand what it is you are trying to achieve.
Human brains are not SMP hardware. A group of people working together will not all see the same big picture.
Nobody on Earth fully understands all of C++. Every C++ programmer knows a subset. My subset is not your subset; it is unique to me as yours is to you. Features I love make you uneasy at best, and your pet features do likewise for me.
The features sneak in here and there... well I just can't resist because I really NEED my favorite feature! Think of the classic 2-circle Venn diagram for two people's C++ knowledge: you might hope for your project to be that intersection in the middle, but it's going to end up with the big fat union of pet features.
Really, you can't stop it. Resistance is futile.
You'll see exceptions, then memory leaks, an attempt to solve it with some kind of braindead "smart" pointer, somebody needs multiple inheritance, some ass overloads the comma operator or () operator, overloading gets sort of ambiguous with differences between the 32-bit and 64-bit builds, Boost gets pulled in with compile times and start-up times going to Hell, people cry for Java-style garbage collection...
GCC already uses a garbage collector internally although it has to be triggered explicitly.
The two main reasons for choosing a subset of C++98, instead of a different language, were mentioned on the mailing list. The most important reason is C++ will be the easiest to pick up by GCC hackers which are mostly accustomed to plain C.
The second reason mentioned were specific features of C++ like simple templates (STL containers) and multiple inheritance. They're taking everything slowly and at the moment there's no consensus even about the use vtables and RTTI.
Yeah, exactly. I don't understand why they didn't chose something modern like Ajax.
Mada mada dane.
grep MyClassAddFloatAndInt *.c
grep add *.c
This totally sucks. Now I need some complicated language-specific search tool that is sure to have fewer options than grep. It's probably not even scriptable, and surely much slower. Why do you want me to suffer?
I'm aware of garbage collector in GC. However, it's completely deterministic, and GCC people don't want to change it.
I tried to do some GCC hacking 3 years ago before I gave up and used LLVM.
Sure it can be abused, if you're overloading operator+ to insert records in a database you're doing it wrong.
OTOH operator[], operator*, operator-> and even operator are fundamental to data processing - you can't remove them from C++ without doing a lot of harm.
Anybody who advocates removal of operator overloading has completely missed the point - yes they can be evil but the good far outweighs the bad.
No sig today...
Subject line says it all. C is the best subset of C++ there is or ever will be.
(assuming you've got a decent C++ compiler...)
Seriously, how can you live without RAII, etc.?
No sig today...
So pick a subset you're happy with and stick to it. If that subset is basically pure C then so be it. But why whinge?
Someone moderated you Insightful. Makes me wonder...
And about modern technology...
Maybe rewriting GCC in python, and rewriting python in Assembler?
Wait....C++....standards?
DOES NOT COMPUTE
*Head explodes
Monstar L
I don't see what the problem with virtual functions is. He goes on and on about 'added overhead' but the overhead isn't added unless a programmer types the word 'virtual' somewhere in the source code. Presumably the programmer expects to get something in return for typing it... therefore the overhead is acceptable. QED.
Templates - how will they do STL without templates??? Seems like a big fail to me.
Exception handling ... probably not needed in a compiler. A compiler isn't likely to want to recover from a fatal error.
RTTI ... probably not needed either and usually quite easy to work around for the few cases a compiler might want it.
No sig today...
Even Objective-C is better.
What do you mean "even"? I consider Obj-C to be a pretty great language.
And, of course, this will slow down the compiler at least twice, maybe even more.
C++ is good, but C is best. Ever wondered why the kernel is written in C (with lots of assembly spices), not C++?
and DOM, don't forget the DOM.
You can't handle the truth.
If anyone is interested about the speed of various different dispatch mechanisms, I've done some profiling
C++ isn't a constraint. There are far more people capable of coding in C++ than in Objective C. And with Apple jumping ship for clang the implementation in gcc runs a serious risk of being deprecated or going bit rotten. Neither of which are justifications for using it internally.
There is no such thing as a slow language.
There are only slow implementations.
Templates - how will they do STL without templates??? Seems like a big fail to me.
The only thing STL adds over traditional container libraries is generics. Why does a compiler need generic containers? The only container that isnt easy to implement-as-needed in the STL that I see a compiler needing (and only for efficiency reasons) is an associative array, and that doesnt actually have to be generic at all.
I would think that it would be far more preferable to (continue to) implement these things specifically for the compiler, and further that people who think that its hard probably shouldn't be involved in the GCC mainline. Perhaps a nice fork for the algorithmically-impaired is in order.
"His name was James Damore."
Kind of like FUSE has done for filesystems. Sure, it is easier to write a proprietary filesystem than it has ever been for linux. But it is also vastly easier to write free ones too. The end result is that there are far more Free (tm) and interesting filesystems than there ever were.
There's a sig I see around here, about religions: (paraphrased) "If you need government to enforce your religious rules, what does that say about the strength of your message?"
If we* need to make it impossible for proprietary software to work with free software in order to sell** the free software, what does that say about the strength of our message and our ability to compete, feature/tech-wise? :(
I give all my moral support*** to the GNU project, which has the goal of enabling people to use only Free Software(tm) and Get Their Shit Done(tm). Making free software worse for the purpose of making proprietary software more worse (say, as in non-existent) runs counter to the purpose of the GNU project. Don't do that. Be pro-free, not anti-proprietary.
* The "freetards" :D
** lit. "make people use", fig. as in "selling [someone on] an idea".
*** including by wearing @gnu.org in my mail address---but I don't represent anyone but myself.
Why is it that this reply is insightful for C++ but would be funny for Perl?
I agree that iostreams are ugly, but they are not strictly part of the language and you don't have to use them if you know any better.
Templates are actually quite useful for performance, when you want parameters incorporated into the code at compile time, instead of evaluated by the cpu at run time. I acknowlege that this can be taken to the extreme: I know of one guy implemented a C++ template raytracer, where the image is produced entirely by the compiler at compile time instead of by the program. But if you care about performance, templates let you get away with less code than C, and no loss of performance at all.
Operator overloading is crucial for when you implement algebraic data types. Have you seen the Vector3d class in Java3D? If you ask me to choose between the potential for abuse and overly-verbose hard-to-read code, I'll take abuse without hesitation.
I'll give you the one about passing by reference. In my book non-const references should basically only be used in operator functions, but it seems a significant number of C++ programmers thinks differently. Still, again the fault is not with the language but with programmers.
I guess you could sum all of this up this way: C++ is a great language, and you can write much better code in C++ than in many, maybe even most, other similar languages, but it is also much easier to abuse by bad programmers. If you have a good team that you can trust, then go for it!
Not a python fan myself, but what would be the downside of rewriting gcc in python?.
via cross-compilation, you can still make a binary for any platform you like---and it's probably much easier to work with and maintain than a ton of C/C++ code.
"If anything can go wrong, it will." - Murphy
How could they have written a complier for a language they don't know? You do realize that GCC already does support C++? This means the GNU guys are admitting they don't know the language that they already wrote a complier for? How good a C++ complier could GCC be?
Awesome! Now the compilation process can spend 80% of its time repeatedly linking virtual tables and getting confused over pure virtuals, instead of spending 5% of its time running through the symbol table and 95% compiling. Remember, building i.e. X11 invokes gcc hundreds or thousands of times, once for each C file (and it invokes the C preprocessor too, and all kinds of other shit from the toolchain, once for each included file each time it's included).
Support my political activism on Patreon.
Informative? More like troll. Objective-C didn't include Garbage Collection until 2.0, just released. And GC isn't part of the language anyways it is just an implementation detail of their provided base NSObject. My ObjC runtime for embedded systems uses a very different base object implementation which sacrifices some(but not all as using C++ would) dynamic features for speed and memory savings.
I have never met an OO problem that cannot be solved in C. Objective-C makes it easier. C++ just creates more problems.
Objective-C is fast to compile, simple, 105% C-compatible. IMO, Objective-C should become C1x.
Objective-C isn't necessarily that slow. Message passing can be about four times slower than C++ method invocation, but once cached, the two are comparable. (SEE here for some interesting stats.)
In a system as IO-heavy as GCC, your bottlenecks probably won't be your method calls / message passing. And as for being deterministic: why would a compiler have to be deterministic? There are no hard real-time considerations for compilers. Your variation in compile-times will be minimal, even with a non-deterministic GC.
I think your point 2 (typed) is fairly valid. Part of the reason to move to C++ is to provide a language that is more strongly-typed than C. While the run-time binding of Objective-C makes it a great language for some applications, it does remove some compile-time type checking. (You do get warnings about an object type's ability to process a message, of course, so you don't lose it all.)
Microsoft is to software what Budweiser is to beer.
Why, exactly, is using STL a greater good from a compiler side?
For example, a std::vector may become correct more quickly than a home-grown array list because more eyeballs will be looking at it. In addition, its operator [] can be overloaded to provide bounds checking.
Nope, not a troll.
Objective-C is poor. For example, the most useful part of C++ are fast typed template containers.
Objective-C has only pointer containers which are untyped.
'Const' support? Nope.
RAII and smart pointers? Nope. Memory management in Objective-C is quite convoluted, btw.
So almost nothing useful for general-purpose programming. Except maybe for inheritance.
I'm talking about Objective-C features which are superset of C. Almost all of them come at a significant price.
I have a Caldera OpenLinux T-shirt from back in the day. I still wear it around once a week
You wear it on those days you want to get laid, eh?
Trolling is a art,
Let's ignore that C doesn't even have "pass by reference"; there's either pass by value or pass by pointer-to-a-value, which is itself a value.
I never understood the animosity against C++. Sure, it's a larger language (you just need to look at the difference in sizes between K&R and Stroustrup to see that); and sure, g++ spits out utterly incomprehensible errors when you work with the Template Black Magic; but on the whole, I find it makes for a more structured program than the equivalent C.
Of course, the only way to fly is Brainfuck; don't let anyone tell you otherwise.
xkcdsw: the unofficial archive of Making xkcd Slightly Worse
Nice to see they are not easily swayed by the "fashion victims" of more recent languages.
need a free COBOL editor for Windows?
I thought compilers would chop the incoming text up into lots of little strings and put them in an array of tokens, to me that says std::string and dynamically growing containers - much more robust than malloc and strcpy.
The expression evaluator will need a stack along with typed data items (int, float, double, etc). C++ can make that sort of thing much neater.
If you dig into it, I'm sure there's many places where C++ would remove a lot of lines of code from a compiler.
No sig today...
This is the part where I point out that c# can act as a low-levelish language. You can do pointer arithmatic and shoot yourself in the foot with buffer overruns just fine writing unsafe code.
Of course writing such low-level code in C usually looks more elegant than doing it in C#.
ah so many of you don't remember the REALLY early days of linux and having to bootstrap gcc. I don't even really recall the details any longer other than IIRC it took 3 full code compiles which took what felt like forever on old 386 machines with a couple meg of RAM... then building X11 which took about as long. ...then the distros with 20 or 30 floppy images appeared with binary packages... no more hours of waiting to build gcc and X11.
Anyways if you read the email link, you'd see they really only want bits and pieces of C++ since, apparently, most of their contributors aren't familiar with C++. Also if you follow the thread they're still obviously in the very early stages as they're branching out into also of unrelated/unimportant/pedantic nonsense interspersed with healthy doses of common sense.
Obj-C is why Apple is running circles around MS and Google. Whether you love em or hate em, Apple innovates highly polished products the fastest. MS: stuck with C++ no real innovation in a decade. Google: Love some of their stuff, but they haven't really standardized on one language. A lot of Google's stuff is 1/2 finished as a result.
Dynamic typing is a very important enabler of tight code (closures for example). It also enables far beta meta programming like unit tests and build automation. Static typing is the problem, not the solution.
Of course this stuff flies over the heads of most business deciders, and also programmers who enjoy disentangling spaghetti instead of writing unit tests because it gives them job security! More Parmesan with that?
While OS's have been written in languages like Pascal (original MacOS for instance and early versions of Windows) those were also largely custom compilers that added low-level functionality to the language.
Uuum, I have done systems programming in Pascal (starting at TurboPascal 3.0), and you can do everything perfectly well in it. If you can do it in C, you can do it in Pascal. The effort is about the same. No need for additional low-level stuff. Interrupts, ports, registers, pointers, etc... Everything there.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
and DOM, don't forget the DOM.
I've been trying to for years and then you mentioned it, you insensitive clod
C++ can be very lean and mean indeed.
Can be != is. A statically linked C++ hello world program using <iostream> is still on the order of a quarter megabyte even on recent versions of g++ and libstdc++. This hurts when you want to use C++ features on a memory-constrained embedded system. Consider a handheld computer with 288 KiB of RAM that sold tens of millions of units between 2001 and 2006. If the libraries needed to run hello world eat up all the RAM, how are you going to fit the application?
There's no equivalent to RIAA in C
That's only because the standard C library has no audio output facility. Did you mean RAII?
there's also no equivalent to stack unwinding or many of the other C++ constructs which are central to good C++ programming.
But how big is the library support for those C++ constructs? Once you #include <iostream> and reference cout, your statically linked hello world already almost fills RAM of your elevator controller. Do you want to see byte counts for a static hello-iostream.cpp on two different platforms?
I never understood the animosity against C++.
Many of us were around for the long trial by fire that was needed to figure out which features of C++ to use and which to avoid. "Modern C++" gets good results from a careful set of language features and libraries, but many folks still get flashbacks from the language itself.
It would also use even more gigabytes of RAM and run like a snail.
Python is nice to write but runs worse than Java.
No, the ObjC compiler is ass, like GCC in general when it comes to producing fast code. Stop blaming the language for a problem that is clearly determined by the interpreter.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
ability to declare variables in the middle of code blocks
That's been in C for the past decade.
if there was a way to do that without dragging in the full suite of OOP features, they'd go that route. They don't want exceptions.
In C++, you pay for what you use. If you don't throw, and you don't link to a library that throws, then you won't have exceptions. I guess their problem is that the standard library uses the version of operator new that throws std::bad_alloc on failure rather than the version that returns a null pointer.
Maybe they don't want function overloading
You can disable overloading for a function by putting extern "C" before the name of the function's return type.
Extended initializers
Something like that is already in C99.
Nope, not a troll.
Objective-C is poor. For example, the most useful part of C++ are fast typed template containers.
This is also one of C++ weaknesses. Troubleshooting templates is a royal pain in the ass. I'd rather chase a pointer to hell and back than deal with another set of poorly-written templates. And templates are almost invariably poorly-written.
They are damned useful when done right, though.
Objective-C has only pointer containers which are untyped.
True, that. Objective-C sacrificed compile-time type checking for flexibility. Well-written Objective-C code is almost beautiful (something that can't be said even for well-written C++ code), but you really need to be careful with your types.
'Const' support? Nope.
RAII and smart pointers? Nope.
"Smart pointers" are really just a kludge to fix up a poor language design choice. RAII isn't all that vital in Objective-C, either.
You are attempting to say Objective-C is deficient because it doesn't support the design patterns you use in your C++ code, when those design patterns are necessary because of the language itself.
Memory management in Objective-C is quite convoluted, btw.
You ain't kidding. It's getting easier with each iteration of the language, but the GC is kinda particular. Conscientious use of refs is a must.
So almost nothing useful for general-purpose programming. Except maybe for inheritance.
Riiiight.
Again, I think you are judging Objective-C based on your C++ experience. Late binding, associated references, adding messages to existing classes at run-time, message forwarding, and so on are all excellent general-purpose programming idioms that aren't supported in C++. Couple that with introspection (which is supported in C++, to a degree), and you can write very powerful fully-OO programs.
Objective-C isn't perfect. No language is. But it certainly isn't as anemic as you seem to think.
Microsoft is to software what Budweiser is to beer.
There is no such thing as actual pass-by-reference. Sure, a language might have fancy syntax for it, but it gets boiled down to pointer-to-a-value-which-is-itself-a-value. C just skips the sugar.
Can the C based versions be labeled clearly for those who prefer a gcc written in C only? If this is not possible, it may be a good idea to create a fork for gcc in C for those who may need it. Ideally, a compiler flag that can switch to C only version if requested would be good.
Do you mean it's completely NON-deterministic? Because otherwise I'm a bit confused by the contradiction between this post and your original one.
it would be slower than fuck, but would certainly provide mental masturbation for the ivory tower types. The ivory tower types don't have engineering pragmatism but they sure make pretty code sculptures
"This is also one of C++ weaknesses. Troubleshooting templates is a royal pain in the ass. I'd rather chase a pointer to hell and back than deal with another set of poorly-written templates. And templates are almost invariably poorly-written."
I have debugged code which uses Boost MPL. It looks scary but once you understand how templates work it's not different from usual debugging. Apart from the fact that it's done at compile time instead of runtime.
And plain simple template applications (containers, algorithms) are even easier.
"True, that. Objective-C sacrificed compile-time type checking for flexibility. Well-written Objective-C code is almost beautiful (something that can't be said even for well-written C++ code), but you really need to be careful with your types."
Untyped code is filed under 'ugly' in my book. I generally prefer maximum compile-time safety with as much typing as possible (my favorite language is Haskell :) ).
""Smart pointers" are really just a kludge to fix up a poor language design choice. RAII isn't all that vital in Objective-C, either.
You are attempting to say Objective-C is deficient because it doesn't support the design patterns you use in your C++ code, when those design patterns are necessary because of the language itself."
No. Pure C also suffers from this. Just look at all those 'goto cleanup' in the Linux kernel. Which is nothing more than a poor man's destructors.
I won't argue about your other points, since they are subjective. Personally, I'd rather prefer good pattern matching to all the OO stuff.
We may have gained a lot in the last couple of decades, but those early Borland compilers (Turbo C, Turbo Pascal, Turbo Asm, Borland C++) were just so righteous!
Seeing as how GCC now supports them both, why not use one of them instead?
Having done a little work with this, I think kernels are written in C because of issues with the runtime library. The C++ runtime is more complex to get up and working, and a kernel needs a different runtime library than the rest of the system because it has a different memory map and it doesn't make syscalls to the kernel to make things happen at the back.
Also, in the kernel there are plenty of places where you don't want anything happening between point A and point B that allocate memory or touch user space or manipulate semaphores or whatever, because you're in a critical section. Well, part of the whole design of C++ is a single statement can turn into dozens or hundreds, and often these statements will auto-allocate (and de-allocate) memory for you or use other resources. So you'd have to be real careful if you used C++, so careful that I'm not sure you get much from C++ except namespaces.
So in short, I think the reasons kernels don't use C++ cannot be directly applied to a compiler. It has its own reasons (primarily bootstrapping) though.
Also, kernels don't use much assembly, I'd say "lots of assembly spices" is an exaggeration. You can never get the amount of assembly down to 0, but neither do you use it that much.
http://lkml.org/lkml/2005/8/20/95
That may be, but references are much nicer to work with than pointers. The only problem is you can't delete them, you've got to wait for them to go out of scope. This makes using them with the heap problematic.
I purely despise the syntax that C came up with for using values pointed to by pointers. And pointer/integer conversions, etc. should never have been allowed. It makes garbage collection a guessing game. Garbage collection *should* be a part of any decent language. The only reason it isn't reasonable for C/C++ is the infernal mucking around with pointers/integers that it allows. Pointer arithmetic should be absolutely forbidden.
That said, I'm not sure whether I prefer C over C++, if one restricts oneself to a decent subset of C++...but some of the libraries that I want to use are only C++ libraries...so that sort of forces the issue for me.
I think we've pushed this "anyone can grow up to be president" thing too far.
No, the current GC in GCC is deterministic. I.e. if you run GCC with two identical inputs on two computers, GC will collect the same objects at the same time.
Untyped code is filed under 'ugly' in my book. I generally prefer maximum compile-time safety with as much typing as possible (my favorite language is Haskell :) ).
Haskell is beautiful. I wish I had more opportunity to use it, rather than just playing around with it. You have good taste.
I won't argue about your other points, since they are subjective. Personally, I'd rather prefer good pattern matching to all the OO stuff.
Not really subjective. You made the assertion there wasn't much there for general-purpose computing; I mentioned several features that are good for general-purpose computing. There's nothing subjective there, other than whether or not you like them.
Obviously, many people have found them useful, from the original NeXTStep coders andLotus Improv creators to the modern OS X and GNUStep developers.
In any case, while I prefer Objective-C over C++ (it just fits my style better), I can definitely understand the desire for stronger compile-time type enforcement. That alone is sufficient to warrant C++ over Objective-C, especially for a project that relies on input from many other people of varying skill levels.
My inner language fanboi came out when you glossed over most of the unique features that make Objective-C a versatile language.
Oh, one other complaint about it to add to your list: current implementations don't properly support private variables and messages.
Microsoft is to software what Budweiser is to beer.
I don't see how references are any better than pointers, really, except you aren't allowed to do certain things. Whoop-dee-doo. If you can trust those certain things, then just don't ever do them in your code. Boom, you have the safety of references without having to use references.
I'm not sure what your problem is with the syntax for pointers in C. It makes pretty good sense. I guess the only annoying thing is that a star is used both to indicate type, and also as a dereferencing operator. I suppose they could have used, say, a ^ to indicate the type and a * for dereferencing. Either way, the two contexts are pretty clearly separated, so it doesn't seem to be a problem for me.
Sure, GC would be nice, but consider the versatility of C's targets. C demands absolute control over what's going on. GC violates that as the GC is off on its own, outside of your direct control as programmer. It may also be unnecessary. Many interesting programs can be written in C with manual memory management and very little risk for leaks. It's only the large programs that would benefit from GC. And even then, having a sane model of object lifetime would be the better choice. Honestly, to me, GC is a cop-out. You are saying "I'm too lazy to make sure I know what is needed when, so I'm gonna let the run-time heuristically determine it for me and hope I don't run out of memory before it can do its job!" But I guess since developer time is more expensive than computer time, GC is the way we are going to go.
If C++ is the worst thing you've ever used then I strongly suggest trying to do something nontrivial in AppleScript; C++ will seem pretty awesome after that. :)
Why would you do this? AppleScript is a scripting language, primarily for application automation (which, incidentally, you'd probably have trouble doing in pure C++), not for writing multi-threaded CFD codes.
Stop! Dremel time!
MS: stuck with C++ no real innovation in a decade.
Other than that whole C#/.Net Framework thing, you mean. But I guess we can ignore that.
Google: Love some of their stuff, but they haven't really standardized on one language. A lot of Google's stuff is 1/2 finished as a result.
Right, because Google projects get slowed down because developers keep switching programming languages midstream. Last I heard they were rewriting GMail in a combination of Oberon, Scala, and Z-80 assembly language.
Breakfast served all day!
References for me are just more complicated pointers that only make code even harder to understand. Returning values through arguments like that is a bad idea, like all the things that references allow you to do. ... f(x) changing the value of x is a completely unexpected and surprising result for me. In C at least it had to be f(&x). Not to mention the use of & for references confuses the hell out of me.
References were originally added to C++ to provide for an efficient argument passing mechanism for large-sized values which would not require an explicit address-of. The main reason why you need it is for operator overloading - then you have e.g. a matrix class, you'd want to overload operator + for values of that class, not for pointers to then. I.e. you want to be able to write:
rather than, say:
Pretty much everywhere I've worked, C++ coding style explicitly prohibits using parameters of non-const reference types in all cases. After all, pointers are still there, so you absolutely can still declare a parameter as int* p, and pass a value as &x. This is done precisely for the reasons you give - so that it is clear what is mutated on exit from the function.
And if you're doing high-level OO programming you should be avoiding using such constructs, just pass or return an object that carries the required information.
Not all things are value-copyable. Sometimes you really want to create an object, and pass a reference to it around - for example, when ownership changes. Of course, you'd use std::auto_ptr or std::unique_ptr for that, not a C++ reference.
There is a myth out there that object oriented code produces better quality code then procedural programming.
I say myth because scientifically it has never been proven that code quality improves with compiler discipline.
All claims about less bugs per lines of code, easier to maintain, etc are purely anecdotal and speculative. When I studied this back in the early 1990s the primary impedance to any objective analysis comparing like for like were cost prohibitive. Any effort that involved a change in language also incorporated a change in design. People who wrote the original implementation were replaced, etc. etc.
One could look at this as a teaching moment.
Someone needs to step up and prove that compiler or language discipline increases code quality holding the developer constant.
The claim is that a programmer using a different compiler or language produces better quality code. It has been shown scientifically that a C compiler will mostly produce better performing code than code written in assembly. It has never been proven that compiler discipline can make a better programmer. If it has been proven than someone should be easily able to point that proof the to GCC crowd for them to use as an arbitrator for where to draw the C++ line.
The only argument that makes sense with respect to object oriented languages is that they afford a toolkit for upfront design. The large project architect has tools to layout the design for the implementers to essentially fill in the blank. Stroustrup predicates his entire C++ book on this point.
However, it doesn't appear the design features of C++ are the objective here. The objective here is code quality via better syntax, and is this is a claim that has never proven. Its a modern myth.
This is really not a discussion about C++ vs. C, but rather the modern myth that any given developer produces better quality code by compiler discipline.
Of course there are such things as slow languages. If a language specification, for example, mandates arbitrary-precision arithmetic, then you can't get around having to implement it, and it will inevitably be slower than native CPU arithmetic operations.
Sure, you can try to optimize it - e.g. use native, and only switch to your own custom bigint implementation on overflow. But you still have to do those overflow checks, and they aren't free.
Similarly, if a language e.g. mandates matching strings for every member lookup, there's only so much you can do to optimize that. Cache lookup results, precompile "hot" branches, etc - however hard you try, you won't beat a direct function call.
Obj-C is why Apple is running circles around MS and Google.
Wait, wasn't it because Apple is a UI/UX genius making polished products that Just Work?
MS: stuck with C++ no real innovation in a decade.
Erm... ever heard of C#?
Google: Love some of their stuff, but they haven't really standardized on one language.
That's because standardizing on a single language is silly for such a broad array of tasks - there's no single language that's good enough for everything. Google's combo of C++, Java and Python, in varying proportions depending on the task at hand, is actually a very good and sensible choice.
Dynamic typing is a very important enabler of tight code (closures for example).
That's bullshit. Closures have been present for ages in statically typed languages such as ML and Haskell (which are, by the way, typed much more strictly than C++). In fact, most languages with closures have been strongly typed until recently - historically, Lisp has been the only notable exception.
It also enables far beta meta programming like unit tests and build automation.
I don't see what dynamic typing has to do with build automation at all. Unit tests - I assume you mean mocking? - it's actually fairly trivial specifically in C/C++, because you can just link in object files with mocks instead of your real code.
For statically typed languages with VMs, mocking is done by using VM hooks to intercept calls. For example, TypeMock for .NET can hook into (and therefore mock) absolutely everything, even constructors and non-virtual and static method calls.
Static typing is the problem, not the solution.
I guess that's why Objective-C is actually statically typed (though permitting full dynamic dispatch)? I mean, if dynamic typing is so awesome, why not just use Smalltalk?
Returning to unit tests - ironically, for large projects written in dynamic languages, big parts of their respective unit tests could be thrown out completely if static typing was in place, because they effectively test type safety, only in an ad-hoc way (i.e. if programmer writing the test forgets about some corner case, too bad).
Yeah, but have they tried JavaScript?
"Because ObjectiveC is a slow shit?"
Which doesn't matter for 80% of the code you ever deal with. For the code where it does matter you can switch to plain old C (or C++ if you feel the urge).
In Objective-C you get the best of both worlds. The convenience of an almost script like environment (which is still very fast) for most of what you need to do and a low level C when performance is an issue.
A reference always "points" to a variable. This is useful because you don't need to account for null pointers when they aren't required, and function parameters are more exact.
Who ordered that?
Garbage collection *should* be a part of any decent language.
I don't understand your reasoning for this. Why force garbage collection on a program that doesn't need it?
Who ordered that?
[Linus] sustained that C++ is utter crap
I thought he said C++ is an overloaded piece of shit?
Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
It's sad. C++ has major problems, which are well known. The fundamental problem is that C++ has hiding without memory safety. C++ is unique among major languages in that respect. There are languages with no hiding, (C, assembler) and languages with both hiding and memory safety (Java, Delphi, Go, D, Ada, Modula, Erlang, Eiffel, and all the "scripting" languages).
The C++ committee, and Strostrup, are in denial about this. They're off in template la-la land, trying to abuse the template system into a compile-time interpreter.
C has its own problems. The basic one is that you lie to the language about how big things are. A string parameter is declared as "char *", not "char[n]". So the language has no idea how big objects are. It doesn't require garbage collection or array descriptors to fix this. It just requires a declaration syntax where you can talk about the size of the arrays you're passing around. This fundamental defect in C is the cause of most buffer overflows. (Technical discussion: C should have had array parameter declarations like int read(int fd, char[n]& buf, size_t n); rather than int read(int fd, char* buf, size_t n); Then the language knows how big the array is. This could be extended to structs, etc. so that whenever you have an array, there's an expression known to the compiler that defines its size. This allows subscript checking.)
C++ tries to paper this over with collection classes, but the mold always seeps through the wallpaper. Too often, you need a raw pointer, which breaks what little protection the collection classes provide.
There are also plenty of lean and efficient vector/list/hashtable libraries in C. I hardly see the point of promoting the STL. Moreover, GCC probably already feature lists and stuffs, and has been for years. Therefore, I don't see exactly what is the point at saying that STL is more this and that, compared to what already works in GCC ?
Pointers, and by extension pointer arithmetic operations in C (and C++) are 1 to 1 mappings to some very common assembly instructions. That is, it's merely a way to use expressions for the type of code that deals with addressing raw memory. If you've found that you're using a lot of code that does pointer arithmetic but can't figure out why, well then you're doing it wrong (tm). This type of code belongs safely tucked away in a well tested library routine. However, to suggest that you should never ever be able to write code that performs these operations literally means you will sell yourself short in the long run when you come across a problem that *requires* that type of bit fiddling. It doesn't happen often, but it does happen.
http://www.usenix.org/publications/library/proceedings/tcl95/full_papers/bogdanovich.txt
Excerpt:
It has a dynamic runtime system (objects are dynamically typed).
This is nonsense. For starters, this isn't what "dynamically typed" is - dynamic typing refers to types of bound identifiers (i.e. variables), not types of values. In Obj-C, variables are strongly typed, though you can escape that with "id" (but only for objects - not for primitives such as "int", for example).
Furthermore, objects in Obj-C are statically typed in a sense that you can change their "isa" field to point to a different class, thus substituting the message receiver. But this doesn't change the value representation (i.e. layout of data fields) of the object, which is immutable, and is definitely part of its type.
It doesn't need to be always enabled. A compiler switch to enable it is quite reasonable. But it needs to be always available. (And saying that garbage collectors, like Bohm[sp?], are available doesn't satisfy the requirement. But a good, fast, garbage collector for C/C++ is basically impossible, because you never know which integer is going to be converted into a pointer. Or added to a pointer to yield another pointer.
I think we've pushed this "anyone can grow up to be president" thing too far.
I had a Caldera OpenLinux CD. I gave it to the Jehova's Witnesses one Sunday morning when they called round in exchange for a leaflet about Armageddon.
Stick Men
When I've needed to do this kind of thing, and I have, just not on an 8086 descendant platform, I wrote a separate function in assembler. Enabling this doesn't justify allowing the compiler language to permit this foolishness. (Well, not necessarily foolishness. That was the only way I could do a random access read from the disk..library problems. Still, not an argument for allowing this to be done from within the language.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Why not simply overload the new operator to handle garbage collection (keeping it's normal use intact)?
Who ordered that?
No, they're marketing geniuses making cool-looking products, for some value of cool.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
That doesn't tell you whether there are references that aren't generated through the new system. (E.g., an array on the heap that has a user generated pointer to an array element.)
So you can end up with stray pointers to memory that's already been released...and possibly reused.
I think we've pushed this "anyone can grow up to be president" thing too far.
I thought compilers would chop the incoming text up into lots of little strings
Thats the abstraction. You know that this can be done in many ways, right?
...or it could use a hash table to associate the token with a number assigned to it, and pair that with an auxiliary array (indexed by that number) that stores information about the token.
It *could* use your sloppy and memory-hungry std:string crap...
In short, you are basically educated in step one of abstraction, but not the implementation.
The expression evaluator will need a stack along with typed data items (int, float, double, etc). C++ can make that sort of thing much neater.
First, regular old C was designed to make implementing stacks simple. Pre-and-Post increment-and-decrement is absolutely all you need .. in short, the damn thing has operators specifically for stacks and queues. I will repeat the assertion that the only thing STL brings to the table is generic containers. The key word is generic and you havent justified a need for them.
Your datatype argument is not well educated, I am afraid, since STL containers are only generic prior to compile-time. In short, they are not run time generics so STL doesn't add anything for a compiler in that regard. The compile needs to treat things as arbitrary datatypes at runtime, and in that vein OO in general is no better than flag/feature bits and function pointers. Either way it needs to perform tests, branch to specific processing or output routines, etc..
If you dig into it, I'm sure there's many places where C++ would remove a lot of lines of code from a compiler.
Why don't you think that its just as likely that it will require more lines of code? You need to think this through, because OO is most certainly not heralded for enabling shorter program sources.
"His name was James Damore."
Good luck implementing exception handling.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
The ANSI C committee adopted const from C++ in time for the first ANSI C standard, 21 years ago (sadly not calling it "readonly").
(You make a valid point about not having to use every C++ feature to get benefits from using some, and I believe that the plan is to be conservative in introducing features that are helpful while avoiding more controversial or complex features.)
You use a cross compiler. But it is painful - GNU Ada is self hosted and moving Ada to a new platform is quite painful. But once done it's a lot more fun. Why should Ada, Fortran or C++ advocates be forced to use C to improver their favourite compiler.
And maybe the move to C++ also means better cross compiler support.
Anyway: self hosted Fortran next!
Actually not all gcc is written in C. The Ada front-end is written in Ada. I think it is the way to go, all language front-ends should be self hosted.
rockets and reactor software should neither be written in C nor in C++. For those you should use SPARK Ada:
http://en.wikipedia.org/wiki/SPARK_(programming_language)
And funnily enough: GCC Ada is written in Ada. Because the real (not pseudo) high integrity developers won't trust a language which (easily) allows to cast a pointer to an integer.
Different name mangling between different compilers is deliberate, and a good thing: it stops you linking together code that uses incompatible ABIs, and then getting strange crashes.
Now, if you want to complain that it took too long to standardize ABIs for C++, and that it's too hard, and that they're not stable enough, then you might well be able to make a pretty strong case, but that's a different thing. If your ABIs don't match, you shouldn't make your name mangling match.
(Incidentally, if you code in a sane way then the implicit copy operations _almost_ always do the right thing. It would still be better if we had to explicitly enable them, but that would have broken C compatibility, or made struct vs class into two different worlds.)
C makes bitwise copies. C++ makes memberwise copies (and in simple cases, can optimize that to a bit copy). In C++ you'd hold a smart pointer, and copying that would do the right thing (whatever the smart pointer defines it to do: ref counting, causing a compilation error, making a copy of the target).
Copy operations in C++ would probably not be implicit, if it weren't for the fact that they're implicit in C.
It is a library for generic algorithms, decoupled from data structures via STL's notion of iterators (which is rather different from GoF iterators). As a proof of concept it happens to provide some containers that work pretty well.
There are many problems with your example.
Don't you see what is going on here? Even the most trivial feature of C++, constructors, are horribly ridden with complications. C++ is a language of never-ending surprises, gotchas, land mines. It's a trap.
Let's knock those down one at a time.
Returning to unit tests - ironically, for large projects written in dynamic languages, big parts of their respective unit tests could be thrown out completely if static typing was in place, because they effectively test type safety, only in an ad-hoc way (i.e. if programmer writing the test forgets about some corner case, too bad).
The problem with static typing in large projects is that a significant proportion of the code becomes devoted to writing bridging delegates from one type domain to another. This isn't so much a problem with smaller projects because it's often possible to force the use of a single type system, but when things get large that becomes impossible; you just can't coordinate the various developers well enough (typically because some of the code is written externally and can't be changed). Dynamic typing can significantly reduce the amount of glue required, at a cost of compile-time safety; dynamic languages typically enforce run-time checks strictly of course, whereas more static languages use their type system to perform those checks during compilation. (Great when it works, horrendous when it doesn't.)
"Little does he know, but there is no 'I' in 'Idiot'!"
The problem with static typing in large projects is that a significant proportion of the code becomes devoted to writing bridging delegates from one type domain to another. This isn't so much a problem with smaller projects because it's often possible to force the use of a single type system, but when things get large that becomes impossible; you just can't coordinate the various developers well enough (typically because some of the code is written externally and can't be changed). Dynamic typing can significantly reduce the amount of glue required, at a cost of compile-time safety; dynamic languages typically enforce run-time checks strictly of course, whereas more static languages use their type system to perform those checks during compilation. (Great when it works, horrendous when it doesn't.)
It's not an all-or-nothing proposition, and it is possible to have some middle ground.
Talking about .NET or Java in particular, if differing types that you need to bridge are all interfaces (or classes inherited from MarshalByRefObject in .NET), then you can create dynamic proxies for them - which have a single dispatch method receiving all method calls on an object, and can forward some (or all) calls to another object with no need to check for each and every method individually. E.g. see this convenience wrapper for .NET (Java API is somewhat simpler, and is trivial to just use directly).
Such proxies are, of course, not type-checked themselves, and performance-wise they are as slow as any dynamic dispatch. But their clients are still forced to be type-safe, and they only pay the dispatch penalty when they use an object which is proxied; for everything else, it's just the normal cost of vtable dispatch.
Also, obviously, this is somewhat lengthier than an equivalent implementation in a typical dynamic OO language, but then, IMO, you don't want such things to be too easy to write - they're supposed to be kludges, not something that you write routinely. If such proxying becomes commonplace, it is much harder to understand the working of the code, decreasing its maintainability.
Furthermore, there are even better approaches to that problem from a static typing perspective. One example were the C++0x (now C++1x...) concepts, and in particular concept maps - the latter allowed you to take any existing type, and map it to any existing concept, without either the type or the concept aware of it; and with members that map directly being mapped automatically. A bit like an outside interface definition. Furthermore, you could have several concept maps between a given type and a concept, each named, and use one or the other in various situations as need be; and even confine them to local scopes.
Don't get me wrong. I like C++, and I also respect it. But I respect it in that "handling nitroglycerine" sort of way rather than in that "treat it like a samsonite bag" kind of way that you can with C# or Java.
Just because you CAN write entirely high level code in C++ doesn't change the fact that it's a mine field filled with explosives waiting to go off at the first misstep.
Yes, you pay for that ruggedness in more modern languages in terms of run-time performance and other factors, but that's what makes C++ so odd... it's that mix of both, that makes it neither.
If you need web hosting, you could do worse than here
True that you can do it, but it's not the default mode. You can take off the safeguards, and run without shielding, but watch out for the radiation.
If you need web hosting, you could do worse than here
TurboPascal is not Pascal. It's TurboPascal. It's a "Pascal-like" language.
If you need web hosting, you could do worse than here
I will repeat the assertion that the only thing STL brings to the table is generic containers.
Wrong. It brings generic containers and algorithms. But saying it like that somehow diminishes what it brings to the party. Its a lot like saying, "Pah - using doctors can ONLY save your life. Its no big deal."
As for reduced line count, the GP post is absolutely correct - assuming you're not counting the generated code associated with STL's template instantiation. Which frankly, is generally not considered for line counts. So if you have many different data types which must otherwise be tracked, in C, you have many different implementations of hand crafted code to handle all these different types - generally all doing the same thing. Or, you've generalized it (void * plus a magic/type in a structure) and thrown away the limited type safety provided by C. Or, you can replace all that, while adding additional type safety with fewer lines of code. Additionally, the STL implementation is far more likely to be much, much faster, not to mention bug free; especially for more complex containers and algorithms.
"Still undecided is what subset of C++ to use".., they need to identify their core needs to answer this question. I would really like to see what they actually come up with. This might be good news..., i hope.
But this is a system's language which is meant for precisely allowing this type of programming from within the language (and avoiding platform specific assembler code while performing the operations themselves using slightly higher level expressions). I'm not sure if the benefits of what you say outweigh the downsides considering their original intended purpose.