Subject: Re: [boost] C++ announcements coming tomorrow
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-11-03 21:43:33
On 11/3/2012 3:15 PM, Eric Niebler wrote:
> On 11/3/2012 2:24 PM, Paul Mensonides wrote:
>> He's been told repeatedly.
> To be fair to Herb, it's not his call to make.
I don't dislike Herb, and my rant isn't really about Herb. I just
believe that everything that he says WRT VC++ is carefully filtered
through MS's marketing engine--which is what I have a problem with.
Because of that, I do not trust anything that MS says, via Herb or
others, with respect to VC++ or MS's so-called "commitment" to C++. I
believe that MS has made valuable contributions to C++, but also that
they have hobbled it and tried to control it. In the cases where they
have made contributions, such as putting money into this new foundation,
I do not believe it has been for altruistic reasons but is instead yet
another marketing attempt. Don't get me wrong, I have nothing against
companies trying to make money. I do have a problem with companies
attempting to disguise their agendas.
All of the above is opinion, but trust is earned not assumed, and I have
not seen anything out of MS WRT to C++ that gives me cause to issue
trust. In fact, I've seen the opposite time and again over a very long
period of time.
>> Not that I'm against a "foundation" or against adding more libraries to
>> the standard library, but the only things that C++ programmers need to
>> produce portable code are C++ compilers that implement the standard (and
>> only the standard--not a bunch of vendor-specific extensions). As an
>> example, paraphrasing, "We're proposing 'await' but if the committee
>> doesn't want it we can always add it as an extension." It is particular
>> compiler vendors and their compilers that are getting in the way of
> I disagree with the view that it's categorically wrong for compiler
> vendors to implement extensions, as long as there is a way to turn them
> off, and as long as the standard library works in a std-compliant way
> when they're off.
To be clear, I understand the need for compiler-specific things like
pragmas (and maybe even things like __stdcall and __cdecl). I do have a
problem with feature extensions of any kind, however. The reason is not
because I believe the language to be sacrosanct so much as that it
breeds lack of portability. If a vendor wants a particular feature
extension, the route is through the language standard, which, to some
degree, allows such features to be discussed and designed in a much
larger context and also inhibits the abuse of popular-compiler-vendor
power. If that route fails, the feature is either not ready or not
general purpose enough to belong in the language.
I hardly believe the standard to be perfect. For example, I believe
initializer lists to be an abomination. Such a facility should have
been implemented atop a less-castrated variadic template mechanism.
However, initializer lists are part of C++ because the majority thought
they were a good idea. Therefore, if I was to implement a compiler and
call it C++, I had better implement that feature even if I don't like
it. The same is true for two-phase lookup, etc., etc.. The point
being, *I*, as the compiler vendor, don't get to decide what is and is
not C++ and what should or should not be implemented.
What C++ needs is portable libraries. In theory, if a library is not
making platform-specific API calls and not using vendor extensions,
portability should be achieved *accidentally*--not by drastic effort by
a library implementer for each compiler/platform. The bottom line here
is not more libraries added to the standard library per se nor a
foundation. Those are solutions to different problems. The bottom line
is lack of real prioritization to implement the language by certain
compiler vendors. *They* are the problem. VC++ is at the top of that
list, though it is by no means the only one on the list. Each
compiler/platform implements a union of a subset of C++ and a set of
extensions. Writing portable C++ code requires using only the
intersection of those sets from all compilers/platforms together with
workarounds for all bugs in all scenarios. Almost nobody does that, and
therefore we end up with lots of non-portable or conditionally-portable
If compilers implemented 100% of the language (allowance being made of
course for features recently added to the language) and did not provide
extensions (which by their very existence encourage their use), then
libraries can be developed to generalize platform-specific details (not
compiler-specific details) (e.g. Boost.Filesystem, Asio, etc.) and a
hierarchy of portable libraries *can* be developed.
>> Further, we don't need C++/CX (or whatever it is called this iteration).
>> The .Net Framework is a huge pile of typical MS bloatware, and,
>> contrary to popular opinion, C# is actually *not* a good language.
> C++/CX has nothing whatsoever to do with .NET. You're thinking of C++/CLI.
I'm thinking both actually. I.e. extensions to the language designed to
interoperate with other things. Those should be 100% library. Same
thing with AMP.
>> actively interferes with abstraction and encourages bloatware
>> production. I am so tired of hearing the "right tool for the job"
>> fallacy WRT programming languages especially WRT to C# and Java.
> One language to rule them all, then?
In theory, yes. Or, at least, almost yes. There is a legitimate
difference between scripting vs compiled software (e.g. Python vs. C++)
but that difference has to do with codebase longevity, not application
domain. Otherwise, programming is about abstraction and composition of
those abstractions. A theoretical language which allows full
abstraction and full composition of abstractions is the "one language to
rule them all." I'm not saying that is C++, and C++ is unlikely to
reach that even in the limit, though it is the closest of current major
languages. What abstraction and composition give you is the ability to
decompose software at the library component level--whose domain reach
extends far beyond the language itself and the standard libraries of the
Given that such a language doesn't yet exist, there is room for a
competition of ideas in how to reach or most closely approximate that
goal. In that competition there are means of comparing languages
The only significant productivity boost that C# yields is the presence
of the large monolithic .Net Framework. It isn't the language itself
that is more productive. The language is, in fact, crippled WRT
abstraction and composition. Just like Java, it is full of decisions
intentionally designed to enforce a particular way of coding--which is
the opposite of abstraction, the opposite of DSEL design, and so on.
Furthermore, its generics mechanism is a joke, it lacks a typedef
concept and therefore an associated types concept, the universal gc
model is fraught with issues related to release of non-memory resources
(leading to the Dispose so-called "pattern" and tons of the equivalent
of try/catch/rethrow cleverly hidden as using() which is the absolute
opposite of abstraction). It is simply not a good language from first
principles because its first principles are objectively wrong.
Related to that, the supposed easy-to-use languages such as C# actually
amount to unqualified people implementing (and re-implementing) duct
tape solutions to problems. That is not a good thing, it's detrimental
in the long run. Duct tape solutions, in turn, drastically deprioritize
the development of good, reusable, long-term solutions.
WRT to C#, I'm not speaking without experience, unfortunately. I
implemented and maintain a C# code-base of approximately 60,000 lines
(not particularly small for one person, though not large) for my
employer (which is not a software foundary). I originally made the
decision to use C# because I believed at the time that C++ would be
beyond the capability of our IT department to understand and maintain.
In retrospect, that was a mistake on my part where I fell into the
right-tool-for-the-job trap. However, as time went on, the domain logic
far exceeded the language complexity, and the codebase is now well
beyond the capability of our IT department regardless (lots of math).
In that development, I routinely ran into C#'s lack of abstraction
capability. Now, I want to port it to C++, but to do that I have to
replace usages of the .Net Framework with libraries. Boost provides
some of those that I need, Qt (which is its own style of abomination)
provides others, but others are more difficult. Not because such
libraries don't exist, but because they are often full of unjustified
platform/compiler-specific extensions, rely on other libraries with such
reliance, or run afoul of broken or missing language features on said
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk