Cee Plus Plus
Cee Plus PlusThe successor to CeeLanguage, enhanced with ObjectOriented, GenericProgramming and FunctionalProgramming concepts, as well as other miscellaneous features and tweaks. Predecessor to JavaLanguage, DeeLanguage and CsharpLanguage.
All the typing joy of java, the blazing speed of C whether you like it or not.
Usage:
Programming Styles
HaHaOnlySerious C++ Humor:
CeePlusPlus is a monstrously overgrown macro package that simulates some aspects of ObjectOriented programming in a conventional, strongly typed, C environment.
An interesting claim, given how little macros are used in C++, and how C++ answers all definition required for support of ObjectOriented programming. Instead, we could say: "C++ is a language which supports paradigms including OO in a strongly typed, simple environment."
{Both of you are wrong. CeePlusPlus isn't strongly typed... not with casting and covariant parameters to subclass methods.}
It's true if you consider the programming language constructs of the language to be structural macros. This is in fact what they are; for example the C++ utterance
class foo : public bar { ... };
is essentially a macro invocation, denoted by the class keyword. The remaining pieces of the syntax are basically arguments for the macro call. The braces, colon and all that are just syntactic sugar that establishes the pattern match. In the compiler, once the pattern is matched, the relevant pieces are extracted and some translation is emitted. If the C language supported sufficiently powerful structural macros, the features of C++ could have been provided just as a library of structural macros, rather than as a whole new language definition requiring a new compiler.
This is true of all languages, more or less. ProgrammingLanguagesAreSyntacticSugar and all that.
(And in the early days of C++, when one used cfront to translate C++ to C; it was more so. Most modern C++ compilers do not translate to C as an intermediate step, however; they compile C++ to machine code directly (although it is rather ironic that the most standards-compliant compiler available, ComeauCeePlusPlus, is implemented by translating C++ to C...)).
At any rate, so what?
Note that while a C++ to C compiler / translator / preprocessor can change C++ to C code which compiles down roughly equivalently in most cases, C++ exceptions cannot be translated to standard C and be as efficient as C++ exceptions on a good C++ compiler. One cannot (easily) automate translating C++ exceptions to equivalently efficient standard C, aka with the table approach. However, the rest of C++ 03 is simple syntantic sugar translatable 1 to 1 to C.
I'd argue that the template feature in C++ is nothing more than a macro package with a lot of sugar on top. It's also a macro package that invites implementing huge recursive macro expansions, and that is where the monstrosity comes in.
I am curious about your use of 'nothing more than'. If you mean 'macro' in the rather limited sense of C's pre-processor(why they called them macros I will never understand...), then I think you are quite wrong; C++ templates are a step towards something worthwhile. Only a very small step. It is the implementation that makes them a monstrosity. On the other hand, if you meant a real macro system like, say lisp's, then I can't understand 'mere' in this context. But I will agree that C++ templates are a pale shadow of that sort of power.
Yes, that is in fact what I mean. You actually agree with me. With the template implementation as it looks like today, they have re-implemented a macro-language on top of C (well, C with classes then). If I want a smart macro language, I'll use Lisp. And no, I don't believe that having macros in a statically compiled language is a good thing.
A medium-sized LanguagePissingMatch has been moved from this space to JavaVsCpp.
I saw a C++ book by Alan J. Holub called "EnoughRopeToShootYourselfInTheFoot" ISBN 0070296898 . Didn't read it, so I can't vouch for the contents, but the title really sums the situation up!
See the Amazon link for some really mixed opinions on this book.
Okay, speaking as both detractor and defender of C++, I've had just about enough of me. I blow the crap out of this language and then get all hoity toity when someone else does it too. The nerve of me. What a bum.
Still I say, despite the objections I raise, that there's a time and a place for CeePlusPlus. Let's try talking about that before we get any more schizoid than we are already: WhenShouldWeUseCeePlusPlus? WhenShouldWeUseJava? -- PeterMerel
In my own work, I've found that C++ is far superior to C for low-level bit-frobbing (like Twain plugins and image processing code). I use it whenever Java is inappropriate [non-application code plugins, etc.]. At the simplest level, C++ is a superset of C for all practical purposes, so anything that can (or MUST) be done in C can be done in C++ with the additional benefits of templates, in-line functions, classes with or without virtual functions, and so on. -- KeithRay
In my own work, I've found that plain old C is far superior to C++ for low-level bit-frobbing...
This thread probably doesn't belong here but... I have found just the opposite to be true. For low-level work, I really need the more stringent type-system of C++. C is just too loose and does not allow you to program with ConstCorrectness. Also, passing C function pointers is much slower [and more error-prone] than using generic-style function objects and parameterization. The only bodge is that many low-level API's (such as devices) are written in C, so it is difficult when the API you are using prototypes functions to take a "char*" when you know that the pointer is not modified and should be a "const char*" or "char* const". Other than this, I find C++ to be far superior to C for low-level work. Of course, if you are the "kid in the cookie jar" type, you may be better off with C, which is less strongly typed than C++ and let you get away with more. -- RobertDiFalco
Is there a decent internet account of what coding methods should and should not be used as far as C++ (or C) is concerned?
See EnoughRopeToShootYourselfInTheFoot book. It ain't half bad.
Personally, I think that a better guideline is "use only what you need." I find that strict coding standards of "use this" and "don't use this" hide an embedded assumption that all programs you write will be like some simple subset that the writers had in mind. I say that when using member function pointers through templated generic functions simplifies your program, then do it. (Otherwise keep your hands off that icky complicated stuff! ;-) -- JeffGrigg
I am not sure I understand the initial statement in this section. I have not seen any operation I could do in C that I could not do in C++. The only difference in C++ is the packaging of the methods into classes. The few things I have not been able to do in C++ usually required me to revert to AssemblyLanguage, not C. -- WayneMack
"The only difference in [between C and (?)] C++ is the packaging of the methods into classes". Seriously? That's the only difference you can see between C and C++? Exceptions, templates, operators, function over-loading yadda yadda NickKeighley
One of the things I like about C++ is the ability it gives you to specify the types of what you are working with. This enables the compiler to catch errors at compile-time that would wait until run-time in some other languages. (And in some languages, you have to write the run-time checks yourself.) For example, suppose I had a type for a homogeneous set of objects and I wanted to write a function to find the union of two such sets. In C++ I can write
template <class T> set<T> set_union(set<T> const & x, set<T> const & y) { ... };
In Java I can create a Set class, but either it has to be a set of Objects or I have to tell the set what it is a set of when it is constructed. Then my definition becomes:
public static Set setUnion(Set x, Set y) { ... };
This doesn't specify that the sets have to be sets of the same type of object.
In Scheme I can't even go that far:
(define set-union (lambda (x y) ... ))I can't say in Scheme that x and y have to be sets. And in Forth?
: SET-UNION ... ;I can't even specify the number of parameters in the language. I have to use a comment.
I think that the more you have to rely on comments to express something about a function in a language, the lower the level of the language. Comments are not checked by the compiler and they can be misleading or incorrect. But in C++ the compiler checks everything... and that prevents bugs. -- EdwardKiser
I agree that I'd rather express something in code than in a comment. These "somethings" you are expressing about the function - perhaps they don't really need to be expressed at all? HelpingTheCompiler
One of the things I like about C++ is the ability it gives you to specify the types of what you are working with.
Perhaps, in that case, you should be using ObjectiveCaml, or some other language with HindleyMilnerTypeInference?
That's a good idea. I learnt C++ after OCaml, when someone shown me that C++ provides the same level of expressivity. I still like OCaml. It's just that C++ is available out of the box nearly everywhere. So I don't get those weird looks any more.
BjarneStroustrup had something to say in an interview about times and the differing acceptance of things:
Q: If you were to start from scratch today and design C++ over again, what would you do differently?
A: Of course, you can never do a language over again. That would be pointless, and every language is a child of its time. If I were to design a language today, I would again have to make trade-offs between logical beauty, efficiency, generality, implementation complexity, and people's tastes. It is important to remember how much people's tastes are conditioned by what they are used to.
Logical beauty? Taste? These are apparent in C++????
Ask yourself one question: Why do many people prefer C++ to Lisp, Simula or Smalltalk?
The handful of people I know who prefer C++ to Lisp, Simula or Smalltalk tell me it's because they feel more employable.
Do you think it is because they think the other languages are better for the task? No! If it was, they would use them, instead.
I'm not aware of any way to use Simula today (2004). I know of very few shops where a developer could use Lisp. The situation is a little better with Smalltalk, but seems to be deteriorating. The overwhelming majority of employers force language choices on their developers, not vice-versa.
C++ is a MultiParadigmProgrammingLanguage (with support for procedural, OO, generic, and, especially with libraries, functional programming), rather than just OO or just functional programming. I know. It slices, it dices, it even juliennes.
What I find a little strange is that, like many C++ programmers, a number of Lisp advocates appear bright, yet seem to be unable (or unwilling) to understand why a language like C++ is designed the way it is. If you want Lisp, use Lisp. As Bjarne Stroustrup has said, something like "C++ isn't Smalltalk. Smalltalk is the best Smalltalk." C++ is designed the way it is for a reason. Those may be reasons for using C++, rather than e.g. Lisp, for a project. The language chosen for something may depend on many factors, and good programmers typically know several languages.
[BTW, it is possible to do LispProgramming with C++, e.g., with InteLib. But, hmm, I don't quite remember a language (other than C++) which could allow C++ programming within it.]
People who consider the C++ design as "hacks" appear ignorant of the design and evolution of the language. It evolved from another successful language, C, with influence from Smalltalk (OO), and later got support for generic programming (templates), etc.
[Translation: People who consider C++ piecemeal evolution as piecemeal evolution appear ignorant of the piecemeal evolution of the language. It was piecemeal evolved from another language, C, with influence from Smalltalk (OO), and later had generic programming (templates), etc. stapled to it.]
I find it an elegant language. Yes, I'm familiar with languages like Smalltalk, Lisp or Haskell. Yet, C++ is my favourite language. Nowadays, I use PHP for web applications. Use the right tool for the job.
I'm reminded of Bjarne Stroustrup's quote: "There are two kinds of languages: The ones everybody bicker about, and the ones nobody uses." :)
I find it rather amazing that especially Lisp-fans (but also some Smalltalk fans) jump over each other to criticize C++. You won't find that in the C++ community, which I find liberatingly free of fanatics. If you like Lisp or Smalltalk then by all means use it. But if you think that the thousands of C++ programmers, many of them highly intelligent and well versed in other languages, including functional programming and OO, use C++ because they don't know any better, then you're in a state of deep denial.
Do you define "fanatic" to mean someone who disagrees with you?
[I would define "fanatic" to include those who imply, as certain SmugLispWeenies and SmugSmalltalkWeenies often like to do - both in this wiki and elsewhere, that C++ programmers who like C++ do so because they're "stupid" - either due to inexposure to Lisp/Smalltalk/whatever else, or a failure to fully grok Lisp/Smalltalk. It's the old IfYouDontLikeItYouDontUnderstandIt fallacy. And it's utter BS.
I have lots of nasty things to say bout C++; and I consider myself one of its defenders. It's got lots of warts and sharp edges, damn sure. I like Smalltalk and other languages; they have their place.
But so does C++. Despite its warts, I like it and get lots of stuff done in it. So there. :) ]
People may have different preferences. Some may find it easier to think in terms of imperative or iterative programming, others declarative or recursive. It may also depend on the context, including the language. What I especially like about C++ is that it gives me all these styles or paradigms, and more.
All this criticism of C++ and other popular languages by proponents of rarely used languages sounds like jealousy, to me. Again, it's not because C++ fans hasn't "understood" things like functional programming. I find some FP-concepts interesting (such as lambda, higher-order functions, currying and pattern matching), but it can be done in C++, as well, with a suitable library.
Oh, and to the posting below:
"BjarneStroustrup didn't understand garbage collectors and had already made the entire edifice so byzantine that any reasonable garbage collector was impossible to build anyway."
From TheDesignAndEvolutionOfCpp: "garbage collection would make C++ unsuitable for many of the low-level tasks for which it was intended.... I am fully convinced that had garbage collection been an integral part of C++ originally, C++ would have been stillborn"
Your point being? It seems to me that your quote from TheDesignAndEvolutionOfCpp confirms how poorly BjarneStroustrup understood garbage collectors. Both statements say the same thing: CeePlusPlus is incompatible with good garbage collection. Perhaps you should read the book before evaluating BjarneStroustrup's level of understanding. The C++ philosophy is, "you only pay for what you use". If you want a garbage collector, you can use one. If not, you don't suffer the consequences of being forced to use one (which in Java's case includes no destructors - thus breaking the infinitely more valuable ResourceAcquisitionIsInitialization idiom).
So much for not understanding garbage collection. Besides, if you want GC for C++, there are several available. It's not "impossible to build", at all. Also, there are programming idioms where you typically don't need it, and thus can avoid its overhead (such as using ValueObjects).
This has already been addressed at length. It's true that several are available. None of them offer the efficiency of the best gc's in Java, Smalltalk or Lisp, or at least none of them do so while preserving the CeePlusPlus requirements for calling destructors.
Incidentally, SmugLispWeenies have their own page.
[There are many programming tasks for which using a GarbageCollector is indeed inappropriate - I wouldn't let one near a RealTime system, for instance; nor a deeply EmbeddedSystem where memory is a scarce resource and the several-times multiple of the WorkingSet? that many modern GC algorithms need to function efficiently, simply isn't available. C++ is widely deployed in both types of systems.]
''Does a chip wired into the guts of a Tektronix oscilloscope as a "deeply embedded system where memory is a scarce resource" count as a "programming task for which using a GarbageCollector is indeed inappropriate"?
[Actually, that's more than a "chip wired into the guts"; that's a Motorola 68k processor of respectable vintage, with a fair bit of memory, and lots of custom acquisition hardware. Quite a competent bit of processing power for the time - hardly the equivalent of running Smalltalk on, say, an 8051.
The UI of the Tek 11K scope, which was what TektronixInc implemented in Smalltalk, is an appropriate application of Smalltalk. The acquisition system etc. - which is real time (not sure how hard) - wasn't written in Smalltalk; it was written in C. And the C stuff had its own memory pool, so that the acquisition system couldn't be indefinitely blocked by garbage collection cycles.
Perhaps Ward or someone who worked on the 11k could comment further - but it had a fair bit of memory for the time, IIRC. Enough to support a Smalltalk implementation.]
In the extra 18 months it takes to get virtually ANY CeePlusPlus application working (in comparison to Smalltalk), the available memory generally doubles anyway because of Moore's law.
[The 18 months claim smells like BS to me; the actual gap (if any) will doubtless vary based on the skills of the team, the size and scope of the project, the availability of tools and libraries, the application domain, and a whole host of other stuff. If you know a paper demonstrating that Smalltalk teams can consistently outperform C++ teams, point me to it. For some application domains (enterprise stuff), it wouldn't at all surprise me - C++ has long been a poor choice for enterprise software; with several other languages besides Smalltalk also being a better choice. But an unqualified "18 months" claim simply flunks the smell test.]
This claim is just CeePlusPlus marketing hype.
[Hype by whom? Nobody is getting rich selling C++ implementations - of the two leading implementations of the language, one (GnuCpp) is FreeSoftware and the other (Visual C++) is widely achieving second-class status from the vendor in favor of the DotNet platform. AT&T certainly isn't out there peddling "marketing hype". The remaining handful of compiler vendors out there target niche markets; and certainly aren't engaged in a diabolical plot to hold back Smalltalk.]
The observation that the C++ community widely deploys applications says only that the suits successfully steamrolled junk into the market.
[Or, it says that the language is actually useful. I don't think C++ is particularly great; however I do think it is useful. And the rants of "C++ is only used because of suits/management incompetence/marketing savvy, and for no other reason" are more BS. It gets used because a) it solves people's problems; b) it's widely available and has been for years, c) it (along with C) is the systems LanguageOfChoice for the two dominant computing platforms today (Windows and Unix/Linux), and d) there are tons of libraries for it, and e) it was able to leverage the enormous C community.]
The more relevant question is how does C++ compare with Smalltalk in such cases.''
[For many cases, Smalltalk is clearly a better choice. For others, it's not. You'll notice that despite increases in CPU power and memory afforded by MooresLaw, Tek hasn't done anything with Smalltalk in years. Part of that was likely politics (Tek, until recently, has had a hardware-centric culture that for a long time resisted even C++ - who needs that sissy OO stuff), part of that was the difficulty with keeping the Smalltalk environment running as the underlying hardware platform migrated with changes in technology.]
[And, it's also widely used to implement garbage collectors and runtimes for higher-level languages.] So what? This is just an abstraction-level confusion. [Not a confusion; instead a point. At some point, VirtualMachines and the like need to be implemented in a systems-level programming language. While I suppose one could try and implement a JVM in Java or a Smalltalk VM in Smalltalk - and that might be useful for debugging or certain things - at some point the chicken-egg cycle must be broken.]
-- TerjeSlettebo?
C++ is not for everyone, or every project. However, C++ is the logical answer to a series of questions - in other words, given the set of requirements, C++ is a reasonable solution. If you don't understand the requirements, you won't understand C++; if these requirement aren't important to you, C++ probably won't be, either. If you are curious, read TheDesignAndEvolutionOfCpp. If you aren't, quit complaining about C++.
CeePlusPlus is the result of a cascade of implications of several horrifically bad design decisions, heavily influenced by the arrogance, ignorance, and intellectual sloth of the person and community that produced the sorry mess. And so I enthusiastically agree with you that "C++ is not for everyone, or every project.", and I even agree with you that "C++ is the logical answer to a series of questions." Unfortunately, C++ is the result of incorrect answers to that series of questions. CeePlusPlus was one of a group of C derivatives, including ObjectiveCee, ObjectCee? (from Apple), and numerous home-brew preprocessors (including one I wrote) that used arrays of function pointers to accomplish method dispatch. In such systems, each method name has to be mapped onto an offset into the array that contains the corresponding function pointer. In order to accomplish this mapping, a name scope must be determined for the method name. The design decision taken by BjarneStroustrup was to make the scope global, resulting in a slight performance increase, and also resulting in a requirement that every class in the ancestor chain be recompiled anytime any class in the chain is modified. Similar decisions were taken about object "purity" (BjarneStroustrup was unable or unwilling to work out how to embed native types in a pure object pointer representation, ala SmalltalkLanguage), resulting in the proliferation of "operators" versus methods, "primitive types" versus classes, and so on. BjarneStroustrup didn't understand and didn't want to understand metastructure (and his earlier decisions added so much gratuitous complexity that any metastructure would have been immensely more difficult), and so class objects and a viable runtime model fell by the wayside. With no class objects and no metastructure, "constructors" and "destructors" became necessary. Like the metastructure decision, BjarneStroustrup didn't understand garbage collectors and had already made the entire edifice so byzantine that any reasonable garbage collector was impossible to build anyway. I don't need to read a book about presenting some sanitized reconstruction of the history -- I was in the middle of the language wars while they were being fought.
[sung to the tune of 'Veteran of the Psychic Wars' by B.O.C.]
(It seems like some topics on the Wiki always bring up one of these "yes it is - no it isn't" levels of discussion everywhere it's mentioned. Am I ever sick of hearing about Emacs ;-)
I can see why C++ would not be someone's first choice, and for some people, would never be considered an option. It's not my first choice, either, but not every tool is appropriate for every job. However, I would much rather be using C++ than what I'm currently using in one of my projects (yet-another-C-plus-minus toolkit like you mentioned).
I don't believe that Bjarne made the choices he made because he didn't know what he was doing. I think he made different choices than you would have made because his priorities were different from yours.
C++ is a large, very expressive, powerful, and low-level language. It has a lot of quirks and darks corners. It is often misused, and often the wrong choice, but it is not 'unusable'. For some purposes, it remains the best choice - for a wide variety of reasons. C++ isn't smalltalk, but it was never intended to be.
[And therein lies the problem. C++ should have been SmallTalk. In fact, it should have been Objective-C. I know Bjarne wanted Simula rather than SmallTalk, and he made all of his language design decisions consciously. Unlike some, I do not accuse Bjarne of ignorance. I do accuse him of making simple bad decisions. (N.B. I am a late convert to ObjectiveCee, RubyLanguage, and dynamic languages in general -- my background is C++).]
Actually, if you read his book TheDesignAndEvolutionOfCpp, he laments the fact that some of his language features and choices were political (due to the ISO process) rather than technical.
Why do many people prefer C++ to Lisp [or] Smalltalk?
1. C++ does not have garbage collection. When a programmer states that an object is not needed anymore, the memory becomes available again. A programmer (and a user) can be confident about how long a delay there will be between steps, because there will not be (long) garbage collection steps at irregular intervals. Anyone who played xconq on an early 1990s work-station has experienced the frustration of waiting for garbage collection.
class A {
public:
virtual ~A() {}
virtual void action(A& a) {... do something ...}
};
class B : public A {
int m_nValue;
public:
// action with covariant parameters.
virtual void action(B& b) {... do something with m_nValue and b.m_nValue ...}
};
void test() {
A* pA = new A();
A* pB = new B();
pB->action(*pA); // <-- no typecheck error! and will use B's action and try to use (*pA).m_nValue
}
The above assertion of a typecheck error is incorrect. The code doesn't do what you think it does. B::action does not override A::action; it's a distinct member function with a distinct signature. It overloads, rather than overrides A::action. In C++, a member function's signature is its name and its list or parameter types. Since the signatures of A:action and B:action are distinct, overriding does not occur in this example. Another consequence is that C++ has only covariance of function return types, which is safe. -- DanMuller
Is that so? I'll run some code to double-check, but it leaves me curious as to why this produces a typing error:
void test() {
A* pA = new A();
B* pB = new B();
pB->action(*pA); // <-- typecheck error! A::action not called based on distinct signature.
}
Hmm, sorry, my saying that B::action() overloads A::action() was an oversimplification. In this second example, pB is now of type B. B's action() actually hides A's because the names are the same (even though the signatures differ). This flies in the face of my statement about signatures, but this behavior is by design in C++, and helps prevent common programming mistakes. You can overcome the hiding by adding "using A::action;" to B's declaration, which has the effect of bringing A::action() explicitly into the scope of B. -- DanM
Thanks.
4. C++ supports const correctness.
char* test() { return "Hello, World!";}
5. Similar to Lisp or Smalltalk, but unlike C, it is possible to write C++ without explicitly using pointers. The pointers needed to interpret the command line can be wrapped up in a short function or two, including the main() function. After that, the code can use references, not pointers.
Wow, what a pointless discussion. If your problem domain allows you to use Lisp, Smalltalk, Ruby, or even Objective C, go ahead, and don't waste time even considering C++. C++ is a valid candidate in those cases where the only alternative would be C. In those cases, if you only can get mediocre programmers, stick with C and take the hit. (Same if your problem is quite simple -- your hit will be minimal.) Otherwise, BjarneStroustrup's decisions make a lot of sense, and C++ will give you more maintainable, more evolvable software. There is currently no mainstream alternative (although several languages are on the boundary, such as D and OCaml).
Hogwash -- when Oberon-2 was introduced, it offered everything salient that C++ offered at the time, and with fewer keywords, and more. It offered very fast execution (run-time array bounds and nil pointer checks could be turned off via a compiler option), safe execution (or left on just as easily), is statically, strongly typed, modern variants now also offer generics (however, Turbo-C++, et. al. equally didn't offer templates back in the day either), and nearly all Oberon environments I've seen allows you to control the GC in various ways for real-time purposes. Indeed, Oberon (like Modula-2) appears to be used in a number of European real-time projects.
Functionally, only the syntax of the language differed. People apparently hated the mandated use of all-uppercase keywords, hated putting types after variable names instead of before, and just generally couldn't bring themselves to be found in public after having worked with Oberon. From a bullet-list point of view, comparing feature against feature, for all features that actually contribute tangibly towards a successful project, it is every bit as much a valid candidate anywhere you would think of applying C++, and it provides substantially clearer source code, superior modularity, and type-safety.
C++ was chosen as the language of the new generation of systems programming languages. This was a mistake of monumental proportions. C's success can, at least in part, be attributed to the mistakes of Pascal. Those mistakes have since been fixed. But, it's too late -- the burgeoning hegemony of harder to read, harder to parse, overly complicated, and otherwise FadWare? programming languages, such as C++, all in the futile attempts at backward compatibility, have won the war against simple sanity and common sense.
{The GoodEnough is the enemy of the RightThing. I will not dispute that Oberon very likely would have been a much better choice than C++ for systems programming (not that there's any objective measure for that assertion). But it doesn't matter at this point; overthrowing any established system with its inertia requires a solution remarkably better than the one that exists, such that (a) people fight inertia to use it, and (b) the existing solution can't "hack in" some slow, awkward incremental improvement that captures the same features in a 'GoodEnough' fashion to keep people on its side. It's a lesson that all LanguageDesigners? should learn from, especially since backwards compatibility is such an enormous hassle to support when attempting to 'clean up' any language (not so bad if you're okay with language FeatureCreep, like Perl). Get it right, right now, or know that you'll have to make do with GoodEnough until someone invents something much better; YagNi doesn't apply to language design, which is why Pascal failed and took Oberon and its other incremental successors down with it.}
This entire issue is a little odd, languages are simply tools at our disposal, a skilled carpenter could attempt to use his saw to lever out a bent nail but it would take a lot more time and lateral thinking (not that this isn't fun), but the claw hammer is just lying there doing nothing. Every language has its time and place; if I want lightning fast performance with the convenience of the OO paradigm (say for a game) I'll use C++; if I'm building a restaurant billing system, I'll probably use a managed language where I don't have to worry about a hanging pointer taking the system down on a busy friday night. I don't think it is possible to create a magic-bullet language and no-one should try; universal remotes never work quite right, and neither would a universal language. C++ definitely has its place and in that place it shines brightly... usually your games collection ;)
[Reply in PickTheRightToolForTheJob]
It's rather sad and odd to say nowadays that one of the strongest point of C++ is his compatibility with C. Removing compatibility with C from the new standard would probably kill the language. Sad also to say that C++ is like a farm where the cows escaped out of desperation. There are nice little niches nowadays such as gaming, compilers, computational stuff, real time, network, Os, hardware drivers. But the biggest part of the market, which is the enterprise market, escaped to java and later on to others in order to make developers a commodity.
The standard is awfully large and still awfully weak. The availability of libraries, made out of real C++ is so little, and still all rely upon C libraries. In the standard there is yet no web, no xml, no gc, no User Interface, no test driven development, no metadata programming, and this is often not even in boost.
If you hire C++ programmers, you better go to Lourdes first, and then please have a read to the bible in the paragraphs about the babel tower. Programmers: they will not even talk the same language, they will fight to death for design and they will end up in a bizantine solution.
One day god comes down and tells to you that you are from now on the boss of IBM, if you just have everybody develop C++, Money will flood from the sky.
First of all you need something equivalent to a C++ university. Each of your half a million employees will spend some time in your university, from a couple of months to a couple of years of training with exams and usual stuff (even sales people and secretaries will need training).
Then you will need at least a 100 man years for rebuilding a compiler from scratch (there are people theorizing to start out compiler development from the generic type system perspective instead of the usual red dragon perspective) plus some other 1000 man years for building up a decent set of libraries and tools. Take in consideration that STL alone dates back to the 70s and became visible in the 90s.
Having spent this money then the most difficult task is there, convince everybody that your libraries and compiler, i.e. your standard proposal is the best on earth, which to be optimistic is another 1000 man years (imagine people doing scientific publications, improving the software and so on so forth).
Considering just software development related people, 100Keur gross / man year, we have now spent at least 3000 man years, which is 300 billions euros. This number is not actually so big if you consider that the apollo project was $22.718 billion across 13 years.
Oops, I forgot one thing, you end up bankrupt still, but god is at least happy, the standard is made on purpose to make all the work you have done a commodity.
The worse part of this story is that I still love C++, and I would love to make it better.
See: CppStandard, CeePlusPlusIdioms, LateCeePlusPlus, EarlyCeePlusPlus, OperatorOverloading
CategoryProgrammingLanguage CategoryCpp, CategoryConsideredHarmful, CategoryConsideredUseful
EditText of this page
(last edited August 10, 2014)
or FindPage with title or text search