Standard Versus Non-Standard C++

[Le Chaud Lapin]

{ Reformatted; please limit your lines to 70 characters -mod }

Hi All,

I asked a rhetorical question in a recent post, and the post was
rejected, perhaps because I did not explain why I was asking the
question. The question was:

"Is this valid C++ code or not?"

"this" was code like:

// Is this C++?
SyndicationClient^ client = ref new SyndicationClient();
for(wstring url : urls)
// Perhaps it is, and my compiler is simply out of compliance.

...found on this page:

http://msdn.microsoft.com/en-us/library/windows/apps/hh465045.aspx

The Moderator pointed out that it was obviously not.

I asked the question because I believe that Microsoft is being
somewhat untruthful when they persist in calling C++/CX or C++/CLI or
C++/whatever "C++".

It is not. And it is harmful to the integrity of C++ to do so, IMHO.

If it were C++, I would be able to compile it with my
highly-accommodating C++ compiler.

Microsoft has been, for years, attempting to mislead C++ programmers
into thinking that their "variants" of C++ is essentially C++ with a
bit of flavoring. Experienced programmers know better, but it causes
me some dismay to think of all the young programmers who are just
starting out with "Hello World" being told that highly non-standard
extensions are C++. Aside from the non-standard syntax, which, alone
would break any compliant C++ compiler, they use keywords like:

1. sealed
2. ref
3. get

Scattered across the Internet are statements like:

"You're still coding in C++, and you can access the STL, the CRT, and
any other C++ libraries, except that you can't invoke certain
functions directly, such as those related to file I/O."

If you use those three keywords in your code, you are ~not~ coding in
C++. You're coding in something else that just so happens to share a
lot of keywords and syntax with C++.

A few years ago, in this very group, I castigated a Microsoft writer
for naming his MSDN article "Pure C++", when it was anything but, and
he relented, but Microsoft persists with this inaccuracy everywhere.

Experienced coders like those who lurk here know better, and for that
reason, we have a responsibility to make sure young coders are not
corrupted by misrepresentations before they even get started.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Zeljko Vrba]

{ Please avoid useless quotes, but do provide the minimum
necessary to establish context -mod }

On 2012-07-01, Le Chaud Lapin <jaibu...@gmail.com> wrote:
> { Reformatted; please limit your lines to 70 characters -mod }
>
> Hi All,
>

Hi,

I'm not sure what intention you had behind this post. In the
introduction, under "Objectives" it says explicitly that it uses
extended C++ named C++/CX, and this is repeated few times on the
same page.

Your objection is like castigating somebody for saying they speak
"English" instead of "British English" or "English as a second
language".

Also, a question for you: many C++ projects can be compiled with MSVC
and GCC, i.e., they are syntactically correct ISO C++ programs. Yet,
they rely on behavior that is UB according to the standard, but which
both compilers define in a useful way. Since code exhibiting UB at
run-time is technically not "valid C++ code", should the authors of
such projects be allowed to say that they are coding in C++?

When criticizing somebody for saying "C++" when they actually mean
"C++ as compiled by compilers X,Y on platforms A,B,C", why do you
(arbitrarily) draw the line at minor syntax extensions, use of which
is fully avoidable [at the cost of more complexity/verbosity]?

(I agree that syntax extensions are easiest to spot, but that, IMO,
does not make such programs any more "un-C++" than syntactically
correct C++ programs relying on vendor extensions.)

[Martin B.]

{ Article accepted because it discusses the relationship between
standard C++ and one of its dialects. Articles only pertaining
to a specific dialect will be rejected as off topic. -mod }

On 01.07.2012 09:12, Le Chaud Lapin wrote:
> { Reformatted; please limit your lines to 70 characters -mod }
>
> Hi All,
>
> I asked a rhetorical question in a recent post, and the post was
> rejected, perhaps because I did not explain why I was asking the
> question. The question was:
>
> "Is this valid C++ code or not?"
>
> "this" was code like:
>
> // Is this C++?
> SyndicationClient^ client = ref new SyndicationClient();
> for(wstring url : urls)
> // Perhaps it is, and my compiler is simply out of compliance.
>

> ....found on this page:
>
> http://msdn.microsoft.com/en-us/library/windows/apps/hh465045.aspx

The ref new thing of WinRT is one of those extension I don't really
get. As far as I understand it encapsulates COM reference counting
with IInspectable and (without much thinking and trial on my side,
admitted) it should have been very trivial to do this in purely
standard C++ without a loss in usability.

But then again -- I don't see it matter much because if you're coding
to the WinRT API, it really doesn't matter whether it's standard C++
or not, because you're locked into the MS platform anyway.

> I asked the question because I believe that Microsoft is being
> somewhat untruthful when they persist in calling C++/CX or C++/CLI or
> C++/whatever "C++".
>
> It is not. And it is harmful to the integrity of C++ to do so, IMHO.
>
> If it were C++, I would be able to compile it with my
> highly-accommodating C++ compiler.
>
> Microsoft has been, for years, attempting to mislead C++ programmers
> into thinking that their "variants" of C++ is essentially C++ with a

> bit of flavoring. ...

IMHO this is just hair splitting. It's C++ with extensions, what else
would you call it?

At least with CX you don't pull the baggage of the dotnet-runtime into
your process as you do with CLI.

I also fail to see inhowfar this (WinRT/CX) is harmful to C++.

It certainly makes some sense if C++ -- even a variant C++/CX -- is a
1st class citizen on the largest OS platform than if pure C++ would be
a 2nd class citizen on this platform. (But see my first paragraph that
I'm not sure that they couldn't have pulled it off purely with C++11.)

cheers,
Martin

--
Good C++ code is better than good C code, but
bad C++ can be much, much worse than bad C code.

[Francis Glassborow]

On 01/07/2012 08:12, Le Chaud Lapin wrote:
> { Reformatted; please limit your lines to 70 characters -mod }
>
> Hi All,
>
> I asked a rhetorical question in a recent post, and the post was
> rejected, perhaps because I did not explain why I was asking the
> question. The question was:
>
> "Is this valid C++ code or not?"

The answer rather depends on the meaning of 'valid C++ code'
It certainly is not portable code but an implementer is allowed to
provide extensions as long as they issue a diagnostic the first time an
extension is used in a translation unit.

Strictly speaking the diagnostic could be a message of thanks for using
their extensions.

>
> "this" was code like:
>
> // Is this C++?
> SyndicationClient^ client = ref new SyndicationClient();
> for(wstring url : urls)
> // Perhaps it is, and my compiler is simply out of compliance.

No an implementation is only required to compile code that is
well-formed according to the standard which that code clearly is not.
However it is not forbidden from accepting such code providing a
diagnostic has been issued at least once per TU.

>
> ...found on this page:
>
> http://msdn.microsoft.com/en-us/library/windows/apps/hh465045.aspx
>
> The Moderator pointed out that it was obviously not.
>
> I asked the question because I believe that Microsoft is being
> somewhat untruthful when they persist in calling C++/CX or C++/CLI or
> C++/whatever "C++".
>
> It is not. And it is harmful to the integrity of C++ to do so, IMHO.

Does the implementation compile conforming C++? Yes, so it is an
implementation of C++. However the code itself is not pure C++.

G++ also has non-conforming modes in which it supports various
extensions. That code using those extensions is also often just
presented as C++, which is more confusing for the novice because there
is no upfront extension to the name (OK the implementation is called G++
but it is presented as a C++ implementation).

Almost every existing implementation has support for some extensions.
What sets Microsoft apart is that it actually gives a specific name to
its extended C++. At least in theory using that name to describe code
using the extensions should help inexperienced programmers.

Where MS caused great difficulty in the past was in getting support for
its extensions so interwoven with the basic language that genuine fully
conforming C++ code would fail to compile.

>
> If it were C++, I would be able to compile it with my
> highly-accommodating C++ compiler.
>
> Microsoft has been, for years, attempting to mislead C++ programmers
> into thinking that their "variants" of C++ is essentially C++ with a
> bit of flavoring. Experienced programmers know better, but it causes
> me some dismay to think of all the young programmers who are just
> starting out with "Hello World" being told that highly non-standard
> extensions are C++. Aside from the non-standard syntax, which, alone
> would break any compliant C++ compiler, they use keywords like:
>
> 1. sealed
> 2. ref
> 3. get
>
> Scattered across the Internet are statements like:
>
> "You're still coding in C++, and you can access the STL, the CRT, and
> any other C++ libraries, except that you can't invoke certain
> functions directly, such as those related to file I/O."
>
> If you use those three keywords in your code, you are ~not~ coding in
> C++. You're coding in something else that just so happens to share a
> lot of keywords and syntax with C++.

Sorry, but I disagree. You are programming in an extended C++.

>
> A few years ago, in this very group, I castigated a Microsoft writer
> for naming his MSDN article "Pure C++", when it was anything but, and
> he relented, but Microsoft persists with this inaccuracy everywhere.

You really need to keep a clear distinction between marketing hype and
those actually responsible for the product. It is the former in cahoots
with some text churning authors who are responsible for the
miss-information. But that has been around for a couple of decades as
using C++ for windows rather than for a console resulted in use of
extensions.

>
> Experienced coders like those who lurk here know better, and for that
> reason, we have a responsibility to make sure young coders are not
> corrupted by misrepresentations before they even get started.
>
>

Well perhaps, but it is the responsibility of the wider community to
continue to draw attention to the disservice provided by some writers
who insist on writing about dialects of C++ without making it clear
(probably because they do not know that it is a dialect)

[DeMarcus]

>> I asked the question because I believe that Microsoft is being
>> somewhat untruthful when they persist in calling C++/CX or C++/CLI or
>> C++/whatever "C++".
>>
>> It is not. And it is harmful to the integrity of C++ to do so, IMHO.
>>
>> If it were C++, I would be able to compile it with my
>> highly-accommodating C++ compiler.
>>
>> Microsoft has been, for years, attempting to mislead C++ programmers
>> into thinking that their "variants" of C++ is essentially C++ with a
>> bit of flavoring. ...
>
> IMHO this is just hair splitting. It's C++ with extensions, what else
> would you call it?
>

I guess the problem isn't that Microsoft supports C++ with extensions, the problem is that you can't compile portable code for the Microsoft platform because they have flavored their C++ with various mandatory unstandardized extensions like ___stdcall.

Hopefully all future C++ extensions will be optional on all platforms, otherwise the portability of C++ will be gone.


Regards,
Daniel




--

[Le Chaud Lapin]

On Sunday, July 1, 2012 7:53:37 AM UTC-5, Francis Glassborow wrote:
> On 01/07/2012 08:12, Le Chaud Lapin wrote:
>> Microsoft has been, for years, attempting to mislead C++ programmers
>> into thinking that their "variants" of C++ is essentially C++ with a
>> bit of flavoring. Experienced programmers know better, but it causes
>> me some dismay to think of all the young programmers who are just
>> starting out with "Hello World" being told that highly non-standard
>> extensions are C++. Aside from the non-standard syntax, which, alone
>> would break any compliant C++ compiler, they use keywords like:
>>
>> 1. sealed
>> 2. ref
>> 3. get
>>
>> Scattered across the Internet are statements like:
>>
>> "You're still coding in C++, and you can access the STL, the CRT, and
>> any other C++ libraries, except that you can't invoke certain
>> functions directly, such as those related to file I/O."
>>
>> If you use those three keywords in your code, you are ~not~ coding in
>> C++. You're coding in something else that just so happens to share a
>> lot of keywords and syntax with C++.
>
> Sorry, but I disagree. You are programming in an extended C++.

I am responding to Francis [since I like Francis :)], but please
take this response as a response to all replies to my OP so far,
as they all share similar rebuttals to my argument.

As several have pointed out, there are numerous C++ compilers that
provide their own extensions. These, I have no problem with, because
they generally:

1. Add a feature that is not present in C++ proper.
2. Allow tweaking of feature that is present in C++ proper.

C++/CLI actually changes the meaning of existing C++ keywords sometimes.

To continue with the analogy regarding US English vs British
English, naturally, there are many words that are not shared
in everyday English between the two. Some words have different
meanings depending on which context. But the differences are not
so large so as to make prose written in one dialect unreadable by
someone not familiar with that dialect. I have no problem reading
British or Australian English, but if the grammatical structure
were changed to force use of the the various cases of, say,
Swedish, I would have trouble.

I have no problem reading C++ code that uses Microsoft COM extension
keywords. I have enormous problems reading the so-called C++/CLI.
I have no idea what the '^' character means in that context,
and I have no intention of learning, unless, of course, their
extensions become standardized by ISO, as a variant of C++,
in which case I will learn it. But therein lies the problem. They
are not extensions, but fundamental changes to the language.

UK representation of ISO pointed this out entitling one of their
sections of an objection letter:

"IV. A new language needs a new name "

...and also by writing:

"The UK request that Ecma withdraw this document from
fast-track voting and if they must re-submit it to JTC1,
do so under a name which does not include “C++”.

See:

http://www2.research.att.com/~bs/uk-objections.pdf

-Le Chaud Lapin-

[Edward Diener]

Please give an example that supports your assertion.

>
> To continue with the analogy regarding US English vs British
> English, naturally, there are many words that are not shared
> in everyday English between the two. Some words have different
> meanings depending on which context. But the differences are not
> so large so as to make prose written in one dialect unreadable by
> someone not familiar with that dialect. I have no problem reading
> British or Australian English, but if the grammatical structure
> were changed to force use of the the various cases of, say,
> Swedish, I would have trouble.
>
> I have no problem reading C++ code that uses Microsoft COM extension
> keywords. I have enormous problems reading the so-called C++/CLI.
> I have no idea what the '^' character means in that context,
> and I have no intention of learning, unless, of course, their
> extensions become standardized by ISO, as a variant of C++,
> in which case I will learn it. But therein lies the problem. They
> are not extensions, but fundamental changes to the language.

Microsoft makes it very plain that C++/CLI is a language extension to
C++ which allows programmers to program the .Net framework using a C++
dialect. It is clearly not standard C++, nor does it intend to be. I
cannot believe that anybody really professional using it does not know
almost immediately that it is not standard C++.

My disagreement with Microsoft is not that C++/CLI is not C++ but that
Microsoft originally inferred that it was to be a first-class .Net
language, like C#, but never carried out that promise.

Borland created C++ Builder, which is also an extension to C++, well
before Microsoft crreated C++/CLI. I do not recall an outcry about C++
Builder not being standard C++ from anybody.

I do not agree that your complaint against Microsoft is a valid one in
regards to labelling C++/CLI as C++.

[Robert Wessel]

On Sun, 1 Jul 2012 15:04:21 -0700 (PDT), DeMarcus
<use_my_a...@hotmail.com> wrote:

>>> I asked the question because I believe that Microsoft is being
>>> somewhat untruthful when they persist in calling C++/CX or C++/CLI
>>> or C++/whatever "C++".
>>>
>>> It is not. And it is harmful to the integrity of C++ to do so,
>>> IMHO.
>>>
>>> If it were C++, I would be able to compile it with my
>>> highly-accommodating C++ compiler.
>>>
>>> Microsoft has been, for years, attempting to mislead C++
>>> programmers into thinking that their "variants" of C++ is
>>> essentially C++ with a bit of flavoring. ...
>>
>> IMHO this is just hair splitting. It's C++ with extensions, what
>> else would you call it?
>
> I guess the problem isn't that Microsoft supports C++ with
> extensions, the problem is that you can't compile portable code for
> the Microsoft platform because they have flavored their C++ with
> various mandatory unstandardized extensions like ___stdcall.
>
> Hopefully all future C++ extensions will be optional on all
> platforms, otherwise the portability of C++ will be gone.

MS's C++ implementation is pretty good, standards wise. Sure they
have non-standard extensions, but so does everyone else. They also
have a couple of languages, C++/CX, C++/CLI, which are less
straight-forward extensions of C++. But if you were porting a C++
program, you'd probably want to stick to the standard C++ dialect (not
that the port to the other dialects would usually be all that
difficult, but almost certainly more work than the straight C++ port).

And the need for __stdcall in Windows is not really different than the
need for __attribute__((stdcall)) in GCC - mainly you need to use it
when building interfaces to shared/system libraries (DLLs) (which is
not covered by the standard anyway).

[Le Chaud Lapin]

On Sunday, July 1, 2012 7:15:45 AM UTC-5, Zeljko Vrba wrote:
> { Please avoid useless quotes, but do provide the minimum
> necessary to establish context -mod }

> On 2012-07-01, Le Chaud Lapin wrote:

> Also, a question for you: many C++ projects can be compiled with
> MSVC and GCC, i.e., they are syntactically correct ISO C++ programs.
> Yet, they rely on behavior that is UB according to the standard, but
> which both compilers define in a useful way. Since code exhibiting
> UB at run-time is technically not "valid C++ code", should the
> authors of such projects be allowed to say that they are coding in
> C++?

Because such UB code would be, in fact, valid C++. About this code,
the standard would say: "This code is will be compiled by a conforming
compiler, but the behavior would be undefined.

> When criticizing somebody for saying "C++" when they actually mean
> "C++ as compiled by compilers X,Y on platforms A,B,C", why do you
> (arbitrarily) draw the line at minor syntax extensions, use of which
> is fully avoidable [at the cost of more complexity/verbosity]?

Because the extensions are not minor. In some cases, they are
wholesale replacements for concepts that C++ already offers.

To play devil's advocate, one could argue that in my own programming,
I contradict my argument: I never use STL, ever. I never use set<>,
list<>, vector<>, or string. But I do use Set<>, List<>, Vector<>, and
String, and I claim that my new classes are "C++. There are two
reasons that I can legitimately make this claim.

1. An ISO-compliant compiler will compile my code.
2. If I were an instructor teaching C++ to beginners, and my students
were aware of the existence of a standard library that included
things like set<>, vector<>, list<>, etc...I would tell them that
the classes that I am recommending that they use: Set<>, List<>,
Vector<>, String; are not the classes that they heard about from
the standard library, even though the names are the similar, and I
would issue copious warnings that they should not expect such code
to run anywhere my library binary code does not exist, which is
pretty much everywhere.
I would not tell them when they employ my library, "You are still
programming in the standard library." This is what is sometimes
stated by Microsoft when Microsoft uses non-standard extensions
like "^". They say, "It is still C++.", and it looks like C++,
because the keywords are the same, but the semantics of those
keywords have been changed in subtle ways. Here is what they did
to 'const' and 'volatile':

"The semantics of const and volatile are changed. const (frequently
used in C++ code) is only an optional modifier (modopt) in the CLI
bindings, and therefore can be ignored by compilers and other
tools, whereas volatile (rarely used in C++ code) is a required
modifier (modreq)."

See:

http://www2.research.att.com/~bs/uk-objections.pdf


-Le Chaud Lapin-

[Le Chaud Lapin]

On Sunday, July 1, 2012 7:33:18 AM UTC-5, Martin B. wrote:
> On 01.07.2012 09:12, Le Chaud Lapin wrote:
> > Microsoft has been, for years, attempting to mislead C++
> > programmers into thinking that their "variants" of C++ is
> > essentially C++ with a bit of flavoring. ...
>
> IMHO this is just hair splitting. It's C++ with extensions, what
> else would you call it?

The UK representation of ISO C++ offered the following
suggestions for names to Microsoft:

*** In a spirit of helpful cooperation we even offer a few suggestions
on possible new names: CLIpp or CliPP, CLI++ (the emphasis is on
powerful access to CLI and more, since it supports unmanaged code
too), or ++CLI (ditto, and also note that it contains "C++" spelled
backwards), Ceeli (though this may conflict with an old ICL language
for its mainframes), or even eCma++ (an obvious sister language to
Ecmascript). ***

See penultimate paragraph of:

http://www2.research.att.com/~bs/uk-objections.pdf

-Le Chaud Lapin-


--

[Dave Harris]

jaibu...@gmail.com (Le Chaud Lapin) wrote (abridged):

> // Is this C++?
> SyndicationClient^ client = ref new SyndicationClient();
> for(wstring url : urls)
> // Perhaps it is, and my compiler is simply out of compliance.

The for-loop is C++. That syntax is one of the improvements in C++11.
The other line is not standard C++.

> Aside from the non-standard syntax, which, alone would break any

> compliant C++ compiler, ...

You say that as if it were a bad thing. It's actually key to being a
legitimate C++ extension. The standard says:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any well-formed program. Implementations are required
to diagnose programs that use such extensions that are ill-formed
according to this Standard. Having done so, however, they can
compile and execute such programs.

So a requirement for Microsoft was that every C++/CX program that also
conforms to standard C++ syntax, have the same semantics as the
corresponding C++ program, and all the new behaviour be triggered by
new syntax.

-- Dave Harris, Nottingham, UK.

[Martin B.]

On 02.07.2012 00:04, DeMarcus wrote:
>>> I asked the question because I believe that Microsoft is being
>>> somewhat untruthful when they persist in calling C++/CX or C++/CLI
>>> or C++/whatever "C++".
>>>
>>> It is not. And it is harmful to the integrity of C++ to do so,
>>> IMHO.
>>>
>>> If it were C++, I would be able to compile it with my
>>> highly-accommodating C++ compiler.
>>>
>>> Microsoft has been, for years, attempting to mislead C++
>>> programmers into thinking that their "variants" of C++ is
>>> essentially C++ with a bit of flavoring. ...
>>
>> IMHO this is just hair splitting. It's C++ with extensions, what
>> else would you call it?
>>
> I guess the problem isn't that Microsoft supports C++ with
> extensions, the problem is that you can't compile portable code for
> the Microsoft platform because they have flavored their C++ with
> various mandatory unstandardized extensions like ___stdcall.

Huh??

stdcall is a calling convention for functions and I fail to see both
inhowfar this annotation is mandatory(??!) and how it inhibits
compilation of standard compliant code?

Care to give an non-contrieved example of standard C++ (03 or 11 as
far as implemented) code that won't compile with VC?

(Yes, I am aware that there are situations where MSVC isn't fully
standard compliant - but that doesn't imply "you can't compile
portable code".)

cheers,
Martin


--
Good C++ code is better than good C code, but
bad C++ can be much, much worse than bad C code.

[Dave Harris]

eldi...@tropicsoft.invalid (Edward Diener) wrote (abridged):

> My disagreement with Microsoft is not that C++/CLI is not C++ but
> that Microsoft originally inferred that it was to be a first-class
> .Net language, like C#, but never carried out that promise.

Note that C++/CLI and C++/CX are different things. C++ is about
zero-overhead abstractions, and arguably C++/CLI failed because it
compiled to the .NET byte-code platform which is intrinsically
incapable of delivering that.

C++/CX, on the other hand, compiles to native code, and does deliver
zero-overhead abstractions. The original post was about C++/CX.

-- Dave Harris, Nottingham, UK.

[Chris Uzdavinis]

On Monday, July 2, 2012 8:41:01 AM UTC-5, Le Chaud Lapin wrote:
...

> Because such UB code would be, in fact, valid C++. About this code,
> the standard would say: "This code is will be compiled by a
> conforming compiler, but the behavior would be undefined.

Undefined behavior is syntactically valid C++, but not semantically.
To me it does seem a bit arbitrary to draw the line of distinction
between language extensions and undefined behavior.

Semantic difference is usually much, much more difficult to debug and
understand, as opposed to funny-looing annotations or keywords in the
language. And it has usually been better (for me at least) to see a
compile-time error rather than runtime errors, so I'd prefer to run
into code with extensions rather than undefined-behavior dependencies.

(Not that it's fun to fix either...)

> Because the extensions are not minor. In some cases, they are
> wholesale replacements for concepts that C++ already offers.

Sometimes they're not replacements, but simply new features. Like,
say, g++'s ability to take the address of labels and do computed
gotos. Very, very nice feature, but non-standard. Is it bad?

> To play devil's advocate, one could argue that in my own programming,
> I contradict my argument: I never use STL, ever. I never use set<>,
> list<>, vector<>, or string. But I do use Set<>, List<>, Vector<>, and
> String, and I claim that my new classes are "C++. There are two
> reasons that I can legitimately make this claim.
>
> 1. An ISO-compliant compiler will compile my code.

Ok.

> 2. If I were an instructor teaching C++ to beginners, and my students
> were aware of the existence of a standard library that included
> things like set<>, vector<>, list<>, etc...I would tell them that
> the classes that I am recommending that they use: Set<>, List<>,
> Vector<>, String; are not the classes that they heard about from
> the standard library, even though the names are the similar, and I
> would issue copious warnings that they should not expect such code
> to run anywhere my library binary code does not exist, which is
> pretty much everywhere.

When it comes to instruction, I do side with your purist attitude.
I'm a former purist, now just "mostly purist except when other things
are more important." People should know what is pure C++ and know
what are extensions, and probably should learn the langauge properly
before going into implementation-specific areas. That said, there is
NOTHING wrong with implementation-specific features in a compiler if
it makes your code better or easier or faster or (whatever), compared
to code not using that extention.

Knowing the tradeoffs, I have no qualms about using non-portable java
interfaces either, even though it's virtually taboo to say that
online.

> I would not tell them when they employ my library, "You are still
> programming in the standard library." This is what is sometimes

Correct, that would be lying.

> stated by Microsoft when Microsoft uses non-standard extensions
> like "^". They say, "It is still C++.", and it looks like C++,

Would you be happier if they said it was a C++ "environment"?

> because the keywords are the same, but the semantics of those
> keywords have been changed in subtle ways. Here is what they did
> to 'const' and 'volatile':
>
> "The semantics of const and volatile are changed. const (frequently
> used in C++ code) is only an optional modifier (modopt) in the CLI
> bindings, and therefore can be ignored by compilers and other
> tools, whereas volatile (rarely used in C++ code) is a required
> modifier (modreq)."

But nothing forces you to use their CLI bindings, right?


Chris

[Francis Glassborow]

On 02/07/2012 14:43, Le Chaud Lapin wrote:
> On Sunday, July 1, 2012 7:33:18 AM UTC-5, Martin B. wrote:
>> On 01.07.2012 09:12, Le Chaud Lapin wrote:
>>> Microsoft has been, for years, attempting to mislead C++
>>> programmers into thinking that their "variants" of C++ is
>>> essentially C++ with a bit of flavoring. ...
>>
>> IMHO this is just hair splitting. It's C++ with extensions, what
>> else would you call it?
>
> The UK representation of ISO C++ offered the following
> suggestions for names to Microsoft:
>
> *** In a spirit of helpful cooperation we even offer a few suggestions
> on possible new names: CLIpp or CliPP, CLI++ (the emphasis is on
> powerful access to CLI and more, since it supports unmanaged code
> too), or ++CLI (ditto, and also note that it contains "C++" spelled
> backwards), Ceeli (though this may conflict with an old ICL language
> for its mainframes), or even eCma++ (an obvious sister language to
> Ecmascript). ***
>

However you need to get the context correct. The UK was objecting to
C++/CLI becoming and ISO Standard. I think we would have objected to
Borland's C++ Builder becoming a Standard as well. The later was, IME,
much harder to use without all its extensions. Over the last decade I
cannot recall any time where I had a problem getting my C++ code to
compile with Visual C++. The last time I had a problem was when they had
failed to implement the alternative operator keywords (and, xor etc.).
Even that was immediately visible when using colour coded syntax so it
was no more than an irritation and was quickly corrected when I had
cornered one of their implementers at a conference to draw attention to
the failing.

On the positive side, over the last decade MS have made considerable
efforts to track the development of C++0x. They contributed a great deal
of helpful insights and expertise (but that was the implementation side
of MS not its marketing department)


Francis

[Tobias Müller]

Dave Harris <bran...@cix.compulink.co.uk> wrote:
> eldi...@tropicsoft.invalid (Edward Diener) wrote (abridged):

> Note that C++/CLI and C++/CX are different things. C++ is about
> zero-overhead abstractions, and arguably C++/CLI failed because it
> compiled to the .NET byte-code platform which is intrinsically
> incapable of delivering that.

That's not true.
C++/CLI covers the whole spectrum. You have managed code, unmanaged code,
managed data structures, and unmanaged data structures.
You can even mix those.

Tobi

[Le Chaud Lapin]

On Monday, July 2, 2012 1:03:29 AM UTC-5, Edward Diener wrote:
> On 7/1/2012 6:05 PM, Le Chaud Lapin wrote:
> > C++/CLI actually changes the meaning of existing C++ keywords sometimes.
>
> Please give an example that supports your assertion.

See the following paper, where it is written:

"C++/CLI uses some existing C++ keywords in new, non-standard constructs"
"C++/CLI changes the meaning of currently valid C++ syntax."

http://www2.research.att.com/~bs/uk-objections.pdf

> Microsoft makes it very plain that C++/CLI is a language extension to
> C++ which allows programmers to program the .Net framework using a C++
> dialect. It is clearly not standard C++, nor does it intend to be. I
> cannot believe that anybody really professional using it does not know
> almost immediately that it is not standard C++.

Actually, they do not.

Certainly you know that it is not standard. And I know that. And
probably 99.9% of the people reading this post know that. But some people
do not. They are just starting out. I did not know that 'overload' was
a deprecated keyword when I first started learning C++ (1996) until a
compiler told me. I was using an old book. Programmers (beginners) only
know what they read, and if you scrutinize Microsoft's method way
of presenting C++/CLI, you will see that it is not in the spirit of how
GCC might present its extensions. Microsoft has tried numerous times
to assert C++/CLI ~the~ "natural evolution" of C++, and caught and
rejected by sagacious individuals across the pond.

> My disagreement with Microsoft is not that C++/CLI is not C++ but that
> Microsoft originally inferred that it was to be a first-class .Net
> language, like C#, but never carried out that promise.

I do not think it is possible to make C++ mirror the fundamental concepts
of .NET without changing the language fundamentally. That is part of
the problem. They want standard C++ programmers to migrate over to
.NET, but they realize that C++, by its very nature, is incompatible
with many of those concepts. So they've changed C++ in ways
that bring it closer to .NET concepts, while telling the world, "We
have not changed C++. These are merely extensions." Again, the UK

ISO body saw what they were doing and wrote:

"IV. A new language needs a new name"

(see same link above)

> Borland created C++ Builder, which is also an extension to C++, well
> before Microsoft crreated C++/CLI. I do not recall an outcry about C++
> Builder not being standard C++ from anybody.
>
> I do not agree that your complaint against Microsoft is a valid one in
> regards to labelling C++/CLI as C++.

Do you believe that it is a new language or not?

-Le Chaud Lapin-

[Le Chaud Lapin]

On Monday, July 2, 2012 8:53:46 AM UTC-5, Dave Harris wrote:
(Le Chaud Lapin) wrote (abridged):

> > Aside from the non-standard syntax, which, alone would break any
> > compliant C++ compiler, ...
>
> You say that as if it were a bad thing. It's actually key to being a
> legitimate C++ extension. The standard says:
>
> A conforming implementation may have extensions (including
> additional library functions), provided they do not alter the
> behavior of any well-formed program. Implementations are required
> to diagnose programs that use such extensions that are ill-formed
> according to this Standard. Having done so, however, they can
> compile and execute such programs.
>
> So a requirement for Microsoft was that every C++/CX program that also
> conforms to standard C++ syntax, have the same semantics as the
> corresponding C++ program, and all the new behaviour be triggered by
> new syntax.

According to the following quote, C++/CLI's compiler redefines the
semantics of currently valid C++ syntax:

"C++/CLI changes the meaning of currently valid C++ syntax"

See the second page of:

http://www2.research.att.com/~bs/uk-objections.pdf

-Le Chaud Lapin-

[Le Chaud Lapin]

On Monday, July 2, 2012 8:21:40 AM UTC-5, Robert Wessel wrote:
> On Sun, 1 Jul 2012 15:04:21 -0700 (PDT), DeMarcus
> <use_my_a...@hotmail.com> wrote:
> > I guess the problem isn't that Microsoft supports C++ with
> > extensions, the problem is that you can't compile portable code for
> > the Microsoft platform because they have flavored their C++ with
> > various mandatory unstandardized extensions like ___stdcall.
>

> MS's C++ implementation is pretty good, standards wise. Sure they
> have non-standard extensions, but so does everyone else. They also
> have a couple of languages, C++/CX, C++/CLI, which are less
> straight-forward extensions of C++. But if you were porting a C++
> program, you'd probably want to stick to the standard C++ dialect (not
> that the port to the other dialects would usually be all that
> difficult, but almost certainly more work than the straight C++ port).
>
> And the need for __stdcall in Windows is not really different than the
> need for __attribute__((stdcall)) in GCC - mainly you need to use it
> when building interfaces to shared/system libraries (DLLs) (which is
> not covered by the standard anyway).

Agreed.

To be clear, I have no problem at all with Microsoft extensions like:

_declspec()
__stdcall
__pascal
__uuidof()
etc.

All of these are things that are additive to standard C++,
and I use them at my own risk. When I look at them, I think
"These are not C++ keywords.", and they do not interfere with my
C++ concept space.

But if I see the word "class", as a keyword, then I have
certain expectations about the semantics of that keyword, according
to the C++ standard, and if those expectations are violated by,
for example, not making the member functions private by default,
then to me, that is changing the semantics of a fundamental C++
keyword.

-Le Chaud Lapin-

[Bo Persson]

Le Chaud Lapin skrev 2012-07-02 20:15:
>
> To be clear, I have no problem at all with Microsoft extensions like:
>
> _declspec()
> __stdcall
> __pascal
> __uuidof()
> etc.
>
> All of these are things that are additive to standard C++,
> and I use them at my own risk. When I look at them, I think
> "These are not C++ keywords.", and they do not interfere with my
> C++ concept space.
>
> But if I see the word "class", as a keyword, then I have
> certain expectations about the semantics of that keyword, according
> to the C++ standard, and if those expectations are violated by,
> for example, not making the member functions private by default,
> then to me, that is changing the semantics of a fundamental C++
> keyword.
>

But you have to accidentally write "interface class" for that to happen.
What are the odds for doing that by mistake?

And if you were to write "enum class", also mentioned in the paper, that
now IS correct C++.


Bo Persson

[Zeljko Vrba]

On 2012-07-02, Le Chaud Lapin <jaibu...@gmail.com> wrote:

> compiler told me. I was using an old book. Programmers (beginners) only
> know what they read, and if you scrutinize Microsoft's method way

Bad books get published too. How do you expect beginners to correctly
judge a book that might be obsolete, full of bad advice or which talks
about some non-standard dialect? Why do you think that beginners have
access to information channels that can point them to good books, but
that at the same time won't tell them that C++/CX isn't standard C++?

Also, the said beginner will see that, e.g., 10 lines of C++/CX
translates to, say, 50 lines of standard C++. At that point he will
(rightfully!) wonder WHY he should care about standard C++ at all!
And when you tell him about other platforms and show that
accomplishing the same thing on some other platform (if possible at
all) requires writing, possibly even more, and *completely different*
code, he will (again, rightfully!) ask WHY he should care about other
platforms!

With CLR, C#, C++/CX, embedding more and more metadata into binaries
(even native!) etc., Microsoft has, IMO, done great things for
programmer productivity, and if the said hypothetical beginner should
ask ME those two WHYs, I would have had a really tough time finding
convincing answers.

And when the beginner sees that the standard C++ offers a meager
pallette of features in comparison with rich platform APIs, the
said beginner will (rightfully!) conclude that standard C++ is a
rather limited environment from program development and will even
further question the need for abandoning extensions.

Heck, when I answer honestly to myself to these questions, the only
reason is "having wider prospects for future jobs". I don't think
this would be a very motivating answer to an absolute beginner in C++.

[Le Chaud Lapin]

On Monday, July 2, 2012 4:52:07 PM UTC-5, Bo Persson wrote:
> Le Chaud Lapin skrev 2012-07-02 20:15:

> > But if I see the word "class", as a keyword, then I have
> > certain expectations about the semantics of that keyword, according
> > to the C++ standard, and if those expectations are violated by,
> > for example, not making the member functions private by default,
> > then to me, that is changing the semantics of a fundamental C++
> > keyword.
> >
>
> But you have to accidentally write "interface class" for that to happen.
> What are the odds for doing that by mistake?

Not very high for a veteran C++ coder. But imagine an 18-year-old
student who is just learning C++. Actually, lets skip the hypothetical
and use an actual situation:

One of my students is a 32-year-old mother of three.
She is just starting to learn C++ and very busy with a full-time job.
She has no idea what is standard and what is not. Being on Windows,
she was going to use Visual Studio Express, but I talked her out of
it because Microsoft decided, at one point, that the upcoming version
of Visual Studio Express would only allow Metro development.

http://www.wired.com/wiredenterprise/2012/06/visual-studio-pricing/

Note the significance of this. Even "Hello, World." would require
managed (non-standard) C++. The console was forbidden.

You can imagine, trying to explain to a student who does not know
what a FOR loop is, the difference between managed and unmanaged code,
and why she should abstain from an IDE that only allows non-standard
C++ development. It took effort, but she got a copy of full Visual
Studio, and wrote her "Hello, World!" two weeks ago. and instead of it
containing a bunch of .NET code, it looked very much like the "Hello,
World!" that we all wrote when we first started.

Had it not been for my insistence, she likely would have been immersed
in a world of .NET, with only a vague realization, if that, that she
was limiting herself intellectually. If I had told her, "You're using
a language that has C++ in the name, but it really is not..", I am
not sure she would have believed me.

> And if you were to write "enum class", also mentioned in the paper, that
> now IS correct C++.

[meaning this paper - LCL]:
http://www2.research.att.com/~bs/uk-objections.pdf

So basically, what you are saying is that, the first blob of code is
not C++, and the second blob is. I agree.

I just wish Microsoft would stop saying that the first blob is C++.

-Le Chaud Lapin-

[Edward Diener]

On 7/2/2012 2:12 PM, Le Chaud Lapin wrote:
> On Monday, July 2, 2012 1:03:29 AM UTC-5, Edward Diener wrote:
>> On 7/1/2012 6:05 PM, Le Chaud Lapin wrote:
>>> C++/CLI actually changes the meaning of existing C++ keywords sometimes.
>>
>> Please give an example that supports your assertion.
>
> See the following paper, where it is written:
>
> "C++/CLI uses some existing C++ keywords in new, non-standard constructs"
> "C++/CLI changes the meaning of currently valid C++ syntax."
>
> http://www2.research.att.com/~bs/uk-objections.pdf

I do not agree that the link above shows the second assertion to be
true. It is not shown there that standard C++ constructs, without any
C++/CLI additions/changes, behave differently than one expects in
standard C++. All that is shown is that if one uses C++/CLI
additions/changes, the C++ syntax changes. These are two different
things completely and I see absolutely nothing wrong with what C++/CLI
did in this regard.

>
>> Microsoft makes it very plain that C++/CLI is a language extension to
>> C++ which allows programmers to program the .Net framework using a C++
>> dialect. It is clearly not standard C++, nor does it intend to be. I
>> cannot believe that anybody really professional using it does not know
>> almost immediately that it is not standard C++.
>
> Actually, they do not.
>
> Certainly you know that it is not standard. And I know that. And
> probably 99.9% of the people reading this post know that. But some people
> do not. They are just starting out. I did not know that 'overload' was
> a deprecated keyword when I first started learning C++ (1996) until a
> compiler told me. I was using an old book. Programmers (beginners) only
> know what they read, and if you scrutinize Microsoft's method way
> of presenting C++/CLI, you will see that it is not in the spirit of how
> GCC might present its extensions. Microsoft has tried numerous times
> to assert C++/CLI ~the~ "natural evolution" of C++, and caught and
> rejected by sagacious individuals across the pond.

The fact that "some people do not" means little. Technology can appeal
to experienced professionals and certainly MS did this with C++/CLI.

>
>> My disagreement with Microsoft is not that C++/CLI is not C++ but that
>> Microsoft originally inferred that it was to be a first-class .Net
>> language, like C#, but never carried out that promise.
>
> I do not think it is possible to make C++ mirror the fundamental concepts
> of .NET without changing the language fundamentally.

I agree that they changed C++ fundamentally to create a new language.
But they also retained compatibility with standard C++ where those
language changes are not in effect.

> That is part of
> the problem. They want standard C++ programmers to migrate over to
> .NET, but they realize that C++, by its very nature, is incompatible
> with many of those concepts. So they've changed C++ in ways
> that bring it closer to .NET concepts, while telling the world, "We
> have not changed C++. These are merely extensions." Again, the UK
> ISO body saw what they were doing and wrote:
>
> "IV. A new language needs a new name"

This is where we disagree. Using C++ in the name of a language does not
claim the implementation is purely standard C++.

>
> (see same link above)
>
>> Borland created C++ Builder, which is also an extension to C++, well
>> before Microsoft crreated C++/CLI. I do not recall an outcry about C++
>> Builder not being standard C++ from anybody.
>>
>> I do not agree that your complaint against Microsoft is a valid one in
>> regards to labelling C++/CLI as C++.
>
> Do you believe that it is a new language or not?

Yes I believe it is a new language, which extends C++ in various ways. I
see absolutely no harm in including the sequence "C++" in the name of
that new language. I think you are very much disturbed by that but you
should understand that other people are not and they have a very good
reason not to be. The history of computer software shows that fairly
regularly technology is created under a name which is very similar to
another name, reflecting the use of other technology. This is so common
as to really need no further justification. if Microsoft had claimed
that C++/CLI was just their version of the C++ standard under their own
"name", much like "Visual C++" is considered to be, I could understand
your being upset. But Microsoft so clearly has explained that C++/CLI is
an extension to C++ for .Net programming that it simply cannot be
misunderstood.

[Le Chaud Lapin]

On Monday, July 2, 2012 1:08:33 PM UTC-5, Tobias Müller wrote:
> Dave Harris

> wrote:
> > Note that C++/CLI and C++/CX are different things. C++ is about
> > zero-overhead abstractions, and arguably C++/CLI failed because it
> > compiled to the .NET byte-code platform which is intrinsically
> > incapable of delivering that.
>
> That's not true.
> C++/CLI covers the whole spectrum. You have managed code, unmanaged code,
> managed data structures, and unmanaged data structures.
> You can even mix those.

I think what Dave is saying is that, if you want zero-overhead
abstraction, then you can use a compiler that is capable of compiling
C++/CLI code, but the code that you write will necessarily be C++,
without the CLI.

The moment that you commence using the CLI aspect of C++/CLI,
you lose the zero-overhead feature.

I take it a step further in saying that the code is no longer C++,
depending on what extensions are employed. If keywords assume new
semantics in the C++/CLI, semantics that deviate from those of C++,
then IMO, it is no longer C++.

-Le Chaud Lapin-

[Le Chaud Lapin]

On Monday, July 2, 2012 1:06:18 PM UTC-5, Francis Glassborow wrote:
> >> On 01.07.2012 09:12, Le Chaud Lapin wrote:
> >>> Microsoft has been, for years, attempting to mislead C++
> >>> programmers into thinking that their "variants" of C++ is
> >>> essentially C++ with a bit of flavoring. ...

> However you need to get the context correct. The UK was objecting to
> C++/CLI becoming and ISO Standard. I think we would have objected to
> Borland's C++ Builder becoming a Standard as well. The later was, IME,
> much harder to use without all its extensions. Over the last decade I
> cannot recall any time where I had a problem getting my C++ code to
> compile with Visual C++. The last time I had a problem was when they had
> failed to implement the alternative operator keywords (and, xor etc.).
> Even that was immediately visible when using colour coded syntax so it
> was no more than an irritation and was quickly corrected when I had
> cornered one of their implementers at a conference to draw attention to
> the failing.

Yes, you are correct. The UK was rejecting C++/CLI becoming an ISO
standard. And in the process of rejecting C++/CLI, they stated, if
not explicitly, very implicitly, that C++/CLI is a new language,
meaning, "C++/CLI is not C++".

Thus is the essence of my argument. A C++ standard's body, of all
organizations, plainly stated that C++/CLI is not C++, yet Microsoft
persists in saying that it is.

What is the truth? They cannot both be right.

To be clear, I have no issue with any compiler anywhere adding
new keywords to their C++ compiler. The issue I have is that they
take existing keywords of C++, redefine the semantics, then tell
programmers, "Yes, it's slightly different, but it is still C++."

Fortunately, UK ISO showed that it is not.

> On the positive side, over the last decade MS have made considerable
> efforts to track the development of C++0x. They contributed a great deal
> of helpful insights and expertise (but that was the implementation side
> of MS not its marketing department)

I do agree that there is stellar talent inside Microsoft that has
been giving us an outstanding C/C++ compiler for over 20 years.
But in case you have not been watching, things are changing inside
Microsoft. Not everyone believes in the virtue of Standard C++, and
some of these people are now part of the team that makes Visual
Studio.

This is why we must be vigilant in laying out the truth for all
to see, then let each programmer make his/her own decision.

-Le Chaud Lapin-

[Zeljko Vrba]

On 2012-07-03, Le Chaud Lapin <jaibu...@gmail.com> wrote:

> Thus is the essence of my argument. A C++ standard's body, of all
> organizations, plainly stated that C++/CLI is not C++, yet Microsoft
> persists in saying that it is.
>
> What is the truth? They cannot both be right.

Technically, they can't both be right, but establishing the truth
would require:

1. Establishing the formal semantics of ISO C++ (let's call it S1)
2. Establishing the formal semantics of C++/CLI (let's call it S2)
3. Use an automated system to prove or disprove that the set of
defined behaviors of S1 is a subset of the set of defined
behaviors of S2.
4. If it is proven that S2 is a superset of S1, then C++/CLI is C++.

Given that this has not been done, I consider the truth currently
"unknown", regardless of how the humans on both sides of the
discussion "feel". The said humans are engaged in a political power
struggle with little technical merit.

[Martin B.]

{ Please limit your quoting to the minimum needed to establish
context. -mod }

On 03.07.2012 03:06, Le Chaud Lapin wrote:
> On Monday, July 2, 2012 4:52:07 PM UTC-5, Bo Persson wrote:
>> Le Chaud Lapin skrev 2012-07-02 20:15:
>>
>>> But if I see the word "class", as a keyword, then I have certain
>>> expectations about the semantics of that keyword, according to the
>>> C++ standard, and if those expectations are violated by, for
>>> example, not making the member functions private by default, then
>>> to me, that is changing the semantics of a fundamental C++
>>> keyword.
>>
>> But you have to accidentally write "interface class" for that to
>> happen. What are the odds for doing that by mistake?
>
> Not very high for a veteran C++ coder. But imagine an 18-year-old
> student who is just learning C++. Actually, lets skip the
> hypothetical and use an actual situation:
>
> One of my students is a 32-year-old mother of three. She is just
> starting to learn C++ and very busy with a full-time job. She has
> no idea what is standard and what is not. Being on Windows, she was
> going to use Visual Studio Express, but I talked her out of it
> because Microsoft decided, at one point, that the upcoming version
> of Visual Studio Express would only allow Metro development.
>
> http://www.wired.com/wiredenterprise/2012/06/visual-studio-pricing/

> ...

Outdated information:

MS rowed back on a few stupid decisions recently:

There will be a VS2012Express for "normal" C++ Desktop development:
http://blogs.msdn.com/b/vcblog/archive/2012/06/12/10318952.aspx

And, just aside, they even plan to fix VS 2012 to allow normal native
builds for XPsp3:
http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320645.aspx


cheers,
Martin

[Bo Persson]

{ Please limit your quoting to the minumum need to establish
context -mod }

Le Chaud Lapin skrev 2012-07-03 03:06:
> On Monday, July 2, 2012 4:52:07 PM UTC-5, Bo Persson wrote:
>> Le Chaud Lapin skrev 2012-07-02 20:15:
>>
>>> But if I see the word "class", as a keyword, then I have certain
>>> expectations about the semantics of that keyword, according to the
>>> C++ standard, and if those expectations are violated by, for
>>> example, not making the member functions private by default, then
>>> to me, that is changing the semantics of a fundamental C++
>>> keyword.
>>
>> But you have to accidentally write "interface class" for that to
>> happen. What are the odds for doing that by mistake?
>
> Not very high for a veteran C++ coder. But imagine an 18-year-old
> student who is just learning C++. Actually, lets skip the
> hypothetical and use an actual situation:
>
> One of my students is a 32-year-old mother of three. She is just
> starting to learn C++ and very busy with a full-time job. She has
> no idea what is standard and what is not. Being on Windows, she was
> going to use Visual Studio Express, but I talked her out of it
> because Microsoft decided, at one point, that the upcoming version
> of Visual Studio Express would only allow Metro development.
>
> http://www.wired.com/wiredenterprise/2012/06/visual-studio-pricing/
>
> Note the significance of this. Even "Hello, World." would require
> managed (non-standard) C++. The console was forbidden.

That was a mistake, and they have changed this decision. Another
flavor of the compiler will be available as well.

http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx



Bo Persson

[Francis Glassborow]

{ Please limit your quoting to the minumum need to establish
context -mod }

So why on earth did you suggest she invest in a full copy. What is
wrong with Code::blocks? You can download that with MinGW as a single
item and it is easy to install.

Granted that upgrading to later versions of G++ takes a little (not
much) expertise. Currently I use that IDE with either G++ 4.7 or (when
access to as much of C++11 as possible is desirable) a snapshot of 4.8

The real problem is that too many authors trot out books that treat
C++ programming as if it is centred on Windows programming. That is no
way to learn C++.

I also note that the outcry about VC++ 11 express purported to come
from developers. Those people SHOULD be paying for full commercial
versions and I have absolutely no sympathy with them and every
sympathy with MS.

If you want to learn C++ rather than Windows programming, use console
programming for which GCC/G++ are more than adequate. Perhaps if this
became standard MS might recognise that once programmers have got used
to this implementation in its MinGW form they might choose to stick
with it when they move on to Windows programming and eventually
commercial work.

Encouraging students to buy full versions of VC++ just plays into MS
hands (fully validates their marketing strategy).

It would be nice if all authors of introductory books on C++ stuck
with free implementations, there really is no justification not to
(well I suppose some of them want to ride on the back of MS marketing
by getting 'Visual' into their book titles)

Francis

[Roman W]

On Tuesday, July 3, 2012 2:04:32 AM UTC+1, Le Chaud Lapin wrote:

> Thus is the essence of my argument. A C++ standard's body, of all
> organizations, plainly stated that C++/CLI is not C++, yet Microsoft
> persists in saying that it is.

I don't think Microsoft means it's C++ in the "ISO C++ standard" sense, just that
it's for practical purposes, C++. The string "C++" may mean different things in
different contexts. Such is human speech.

RW

[Tobias Müller]

Le Chaud Lapin <jaibu...@gmail.com> wrote:

> On Monday, July 2, 2012 1:08:33 PM UTC-5, Tobias Müller wrote:
>> Dave Harris
>> wrote:
>>> Note that C++/CLI and C++/CX are different things. C++ is about
>>> zero-overhead abstractions, and arguably C++/CLI failed because it
>>> compiled to the .NET byte-code platform which is intrinsically
>>> incapable of delivering that.
>>
>> That's not true.
>> C++/CLI covers the whole spectrum. You have managed code, unmanaged code,
>> managed data structures, and unmanaged data structures.
>> You can even mix those.
>
> I think what Dave is saying is that, if you want zero-overhead
> abstraction, then you can use a compiler that is capable of compiling
> C++/CLI code, but the code that you write will necessarily be C++,
> without the CLI.

Which implies that C++/CLI is a superset of C++. Or an extension if you
like it.

> The moment that you commence using the CLI aspect of C++/CLI,
> you lose the zero-overhead feature.

C++ has not only zero overhead features (think of RTTI, virtual methods,
virtual inheritance, vectors vs. arrays, ...). But the point is, that you
don't have to use them if you don't need them, and you don't pay for it.
With the CLI features it's exactly the same. Use only what you need, where
you need it and the rest remains untouched.

BTW, C++/CLI is the only CLR language with that capabilities, you cannot
create mixed mode assemblies with C# or VB.Net

Tobi

[Le Chaud Lapin]

On Tuesday, July 3, 2012 8:43:09 AM UTC-5, Zeljko Vrba wrote:

> On 2012-07-03, Le Chaud Lapin wrote:
>
> > Thus is the essence of my argument. A C++ standard's body, of all
> > organizations, plainly stated that C++/CLI is not C++, yet Microsoft
> > persists in saying that it is.
> >
> > What is the truth? They cannot both be right.
>
> Technically, they can't both be right, but establishing the truth
> would require:
>
> 1. Establishing the formal semantics of ISO C++ (let's call it S1)
> 2. Establishing the formal semantics of C++/CLI (let's call it S2)
> 3. Use an automated system to prove or disprove that the set of
> defined behaviors of S1 is a subset of the set of defined
> behaviors of S2.
> 4. If it is proven that S2 is a superset of S1, then C++/CLI is C++.

Let's say I have:

1. C1: a compiler capable of compiling only C++.
2. C2: a compiler capable of compiling both C++ and FORTRAN.

C2 determines at compile time, using techniques from natural
language determination, whether the source code that it is
compiling is C++, FORTRAN, or some strange combination of both.

Hypothetical questions:

1. If source code contains only standard C++, is the code being
compiled C++?
2. If source code contains only FORTRAN, is the code being
compiled FORTRAN?
3. If source code consists of 95,000 lines of C++, but has
5,000 lines of FORTRAN, and the compiler vendor has added a few
keywords and perhaps a few #pragma's that allow invocation
of the FORTRAN functions from C++ functions, is the code C++?
4. If the code consist of 95,000 lines of C++, but has 5,000 lines
of FORTRAN code in it, and, in order for the FORTRAN play well
together with the C++ code, the C++ code for defining...
a. classes
b. structs
c. references
d. function calls
e. string literals
f. arrays
g. general function invocation
h. introspection
i. assignment
j. memory management (garbage collection)

...has been altered such that even the semantics of
traditional keywords have been fundamentally redefined for the
purpose of binding to the FORTRAN code, is this still C++?

My answers:

1. Silly question - Answer is obviously "yes".
2. More silliness - Answer is obviously "yes".
3. Just because a compiler is able to compile a source code from
two different languages that have been juxtaposed does not
mean that the compiler has become deficient in either language.
So the answer to this question is "yes".
4. Here, the answer is no. If the answer were "yes", that would mean
that I could take all the keywords from C++, give
them vaguely similar semantics to what they have in C++, create
my own language, and say, "Hey everyone!!! I have extended C++!
I call it C++/Rabbit. Your standard compiler will break on it and,
a person who knows C++ inside-out will not be able to understand
it, and it changes the semantics of existing C++ keywords...but
that's OK...because the concepts are sorta-kinda the same, and
the keywords are the same...well...you will see some words in it
that are in C++, like class, etc...so technically, it's still C++."

The question here seems to be:

"When is an extension, not?"

-Le Chaud Lapin-

[Zeljko Vrba]

On 2012-07-03, Le Chaud Lapin <jaibu...@gmail.com> wrote:

> 4. If the code consist of 95,000 lines of C++, but has 5,000 lines
> of FORTRAN code in it, and, in order for the FORTRAN play well
> together with the C++ code, the C++ code for defining...

-cut-

>
> ...has been altered such that even the semantics of traditional
> keywords have been fundamentally redefined for the purpose of
> binding to the FORTRAN code, is this still C++?

Semantics is changed ONLY if you opt-in for that, which you must do
ONLY if you want to interface C++ and FORTRAN. In your particular
example, point 4. is actually: 5000 lines of FORTRAN code, let's say
80000 lines of C++ code and 15000 lines of a 3rd language vaguely
resembling C++. The problem is that this 3rd language is inseparable
from C++ because it is THE glue necessary to get C++ and FORTRAN
talking with each other.

In the light of this I can give you a qualified answer: if a heavily
extended C++ dialect is the ONLY technically feasbile way of glueing
together C++ and CLR, then this dialect is still C++. If such glueing
would be doable through an ISO C++ library without unreasonably
burdening the programmer, then this dialect is in actuality a
different language.

According to Stroustrup's explanation here

http://www.research.att.com/~bs/bs_faq.html#CppCLI

it seems to indeed be the case that ISO C++ without CLI extensions
cannot be a 1st-class citizen on the CLR. Thus, I still view C++/CLI
as a heavily extended dialect of C++, but C++ nevertheless since
extensions are opt-in. [Nobody forces you to target your application
to CLR, and you might even get to use CLR facilities from ISO C++ at
considerable inconvenience, but you won't be able to create CLR
modules with ISO C++.]

According to that criterion, C++/CX could possibly be viewed as a
separate language since MS docs say that extensions can be avoided and
that everything can be done with standard C++. Whether it really IS a
new language, or just an acceptable extension to C++, depends on
whether the developer is unreasonably burdened by using ONLY ISO C++.

In any case, I believe the point is moot since a beginner should NOT
start their learning path with an IDE since it hides important details
of the complete build pipeline (preprocessor, compiler, assembler
linker). [Not to mention that an IDE made for professional developers
will seem overwhelming to a beginner.]

[Dave Harris]

jaibu...@gmail.com (Le Chaud Lapin) wrote (abridged):

> According to the following quote, C++/CLI's compiler redefines the
> semantics of currently valid C++ syntax:

Your original post was about C++/CX, which is different to C++/CLI.
Some of the differences are due to lessons learnt from mistakes made
in C++/CLI, so it's not fair to tar them both with the same brush.

> "C++/CLI changes the meaning of currently valid C++ syntax"
>
> See the second page of:
>
> http://www2.research.att.com/~bs/uk-objections.pdf

For what it's worth, I disagree with that section. Their example code
is not conforming C++ because it uses "interface" or "ref class"
rather than "class". Their later point about constructor and destructor
semantics, on the other hand, is valid. It is also an example of a
mistake that C++/CX avoids.

-- Dave Harris, Nottingham, UK.

[Le Chaud Lapin]

On Tuesday, July 3, 2012 12:29:17 PM UTC-5, Roman W wrote:
> On Tuesday, July 3, 2012 2:04:32 AM UTC+1, Le Chaud Lapin wrote:
>
> > Thus is the essence of my argument. A C++ standard's body, of all
> > organizations, plainly stated that C++/CLI is not C++, yet Microsoft
> > persists in saying that it is.
>
> I don't think Microsoft means it's C++ in the "ISO C++ standard" sense, just that
> it's for practical purposes, C++. The string "C++" may mean different things in
> different contexts. Such is human speech.

I find it hard to believe that I am the only who sees that Microsoft has
been engaged in a sustained, concerted, deliberate effort to divert as,
many coders as possible from standard C++ to a .NET form of C++. The
supporting evidence in this thread alone should be at least an indicator.

1. Microsoft hoped to get their C++/CLI standardize by ISO. When they
learned that that route would be problematic, they went through ECMA,
likely because ECMA would present lower standards (pun intended) for
acceptance. That strategy worked..
2. In the ECMA specification, it is written:
"This specification is a superset of Standard C++." Page 10 of:

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-372.pdf

But ISO UK found that C++/CLI is a new language. These two standards
bodies cannot both be right. Either it is a new language or it is not.

Also, there is an interesting direct question posed on Code Project:
"Is ISO C++ code directly compilable in C++/CLI?"

One programmer responds:
"NO IT WILL NOT"

http://stackoverflow.com/questions/4206574/is-iso-c-code-directly-compilable-in-c-cli

"According to the MSDN documentation it will. But it's a nasty lie.
I have fallen into this trap. When already thousands LOC's were
written, it turned out that CLI has problems with boost::thread.
The latter just doesn't work. So I assume that there may be other
things too. So just don't go there, that's my good advice."

3. Microsoft had a column called "Pure C++". The strategy here is based
on psychological pre-emption. It works like this: You're trying out
various motorcycles to buy, and the one you like has very low power.
The salesmen know this is a problem, so they put out ads saying,
"Feel The Power!!!" One says the exact opposite of what the customer
is thinking. In this case, the C++ is ~not~ pure, so you preempt the
customer by calling it pure up-front.

http://msdn.microsoft.com/en-us/magazine/cc163852.aspx

4. Microsoft got Visual Studio Express into universities everywhere.
Then they abruptly decided that it would only allow .NET
development. Coders rebelled, and they relented...but the key
point is that they tried.

5. An article was written on Code Project by someone with the
alias Qwertie called:
"Head-to-head benchmark: C++ vs .NET"

http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET

The article is professional grade.
It should take perhaps 30-60 seconds to figure out which prominent
C++ expert, working for Microsoft, is behind this article.

6. Microsoft, having been successful at fast-tracking C++/CLI through ECMA,
figured that the pipe would be greased for ISO standardization.
As pointed out, ISO UK/France/Germany/etc. proved them wrong.

7. Microsoft, in its MSDN documentation, has had a long history of making
a distinction between Standard C++ constructs, and those that are
"Microsoft-specific", which is precisely the label that they use for
those things that are Microsoft-specific. But for CLI, they deliberately
omitted the "Microsoft-specific" annotation until some in the community
complained. They started revising their documentation to point out
that CLI was Microsoft-specific.

8. Yet still, Microsoft is crafty with their wording. In their
documentation for Visual Studio 2008, they state:
"Keywords are predefined reserved identifiers that have special
meanings. They cannot be used as identifiers in your program.
The following keywords are reserved for Microsoft C++. "

And now the most important statement:

>> "Names with leading underscores are Microsoft extensions." <<

http://msdn.microsoft.com/en-us/library/2e6a4at9(v=vs.90).aspx

This leads the reader to infer that names ~without~ leading
underscores are not extensions, and therefore standard.
But names without leading underscores on that page include:

* array
* const_cast
* delegate
* deprecated
* enum struct
* event
* finally
* friend_as
* gc_new
* generic
* initonly
* interface class
* interface struct
* literal
* naked
* property
* ref struct
* ref class
* safecast
* sealed
* using
* value struct
* value class

To drive home the point of how to distinguish between Microsoft-specific
keywords and those that are standard, Microsoft writes, again:

"In Microsoft C++, identifiers with two leading underscores are
reserved for compiler implementations. Therefore, the Microsoft
convention is to precede Microsoft-specific keywords with double
underscores. These words cannot be used as identifier names."

...thereby implying, once again, that keywords lacking leading
underscores are not Microsoft-specific.

I could go on with hundreds of examples like this from across the
Internet of text and videos where Microsoft essentially claim that
C++/CLI is the future of C++, as well as show the confusion that
resulted when programmers asking if their ISO C++ will work under
C++/CLI context or not, etc..

-Le Chaud Lapin


{ redundant link and quoting removed -mod }

[Ivan Godard]

On 7/3/2012 12:16 PM, Zeljko Vrba wrote:
> On 2012-07-03, Le Chaud Lapin <jaibu...@gmail.com> wrote:

<snip>

> According to that criterion, C++/CX could possibly be viewed as a
> separate language since MS docs say that extensions can be avoided
> and that everything can be done with standard C++. Whether it
> really IS a new language, or just an acceptable extension to C++,
> depends on whether the developer is unreasonably burdened by using
> ONLY ISO C++.

You miss the point: CC++/CX is standard-conforming and can be called
"C++" if and only if *any* standard-conforming program from a
different system will successfully compile and (other than where the
standard explicitly asserts behavior is undefined) execute correctly
on the MS platform.

As I understand it (as a non-CX user) C++/CX etc. fails this
qualification trivially when the program uses MS "keywords" as
identifiers. The UK report cites other examples of failure to conform.

As for using "C++" in the name "C++/CX", there are trademark issues
when names are "similar enough to cause confusion".
http://en.wikipedia.org/wiki/Trademark. Judging by the contents of
this thread, it appears that confusion is triumphing.

[Le Chaud Lapin]

On Tuesday, July 3, 2012 5:06:54 PM UTC-5, Dave Harris wrote:
> Your original post was about C++/CX, which is different to C++/CLI.
> Some of the differences are due to lessons learnt from mistakes made
> in C++/CLI, so it's not fair to tar them both with the same brush.

Well, actually, I guess this is a nit, but I wrote in my original post
was:

<quote>

I asked the question because I believe that Microsoft is being
somewhat untruthful when they persist in calling C++/CX or C++/CLI or
C++/whatever "C++".

</quote>

So I was referring to both C++/CLI and C++/CX, as all versions from
Microsoft that extend C++ have new keywords, etc. I lump them together
because they all share the same issue (from my point of view).

> > "C++/CLI changes the meaning of currently valid C++ syntax"
> >
> > See the second page of:
> >
> > http://www2.research.att.com/~bs/uk-objections.pdf
>
> For what it's worth, I disagree with that section. Their example
> code is not conforming C++ because it uses "interface" or "ref
> class" rather than "class". Their later point about constructor and
> destructor semantics, on the other hand, is valid. It is also an
> example of a mistake that C++/CX avoids.

Ahhh...then we are in agreement. To see this, allow me to restate what
you just wrote:

<quote>

Their example code is not conforming C++ because it uses "interface"
or "ref class rather than "class"

</quote>

Their example code is "not conforming". That is all I am saying. And
because it is not conforming, Microsoft should not portray it as such.

Allow me to reiterate that:

1. I do not take issue with calling their language C++/CLI or C++/CX.
2. I do not take issue with programmers learning C++/CX as their first
language (or 10th language).
3. I do not take issue with infusing normally portable code with
C++/CLI or C++/CX constructs.

The only thing I take issue with is writing code that is clearly
non-standard, and not just in a tweak sense (think #pragma's), but
fundamentally different, where traditional C++ keywords take on new,
incompatible meaning, and calling it "C++" without qualification.

If Microsoft makes the mistake of omitting the /CLI or /CX qualifier
when presenting C++/CLI or C++/CX code, that would be one thing, but
the evidence on the Internet indicates, at least to me, that there is
a a deliberate campaign of misrepresentation. This would be the
logical next step, since ISO rejected their standardization effort,
saying that they should at least give the language a new name first.

-Le Chaud Lapin-

[goran...@gmail.com]

On Sunday, July 1, 2012 9:12:43 AM UTC+2, Le Chaud Lapin wrote:
>
> I asked a rhetorical question in a recent post, and the post was
> rejected, perhaps because I did not explain why I was asking the
> question. The question was:
>
> "Is this valid C++ code or not?"
>
> "this" was code like:
>
> // Is this C++?
> SyndicationClient^ client = ref new SyndicationClient();
> for(wstring url : urls)
> // Perhaps it is, and my compiler is simply out of compliance.
>
> ...found on this page:
>
> http://msdn.microsoft.com/en-us/library/windows/apps/hh465045.aspx
>
> The Moderator pointed out that it was obviously not.

>
> I asked the question because I believe that Microsoft is being
> somewhat untruthful when they persist in calling C++/CX or C++/CLI or
> C++/whatever "C++".
>

> It is not. And it is harmful to the integrity of C++ to do so, IMHO.
>
> If it were C++, I would be able to compile it with my
> highly-accommodating C++ compiler.

>
> Microsoft has been, for years, attempting to mislead C++ programmers
> into thinking that their "variants" of C++ is essentially C++ with a

> bit of flavoring. Experienced programmers know better, but it causes
> me some dismay to think of all the young programmers who are just
> starting out with "Hello World" being told that highly non-standard
> extensions are C++. Aside from the non-standard syntax, which, alone
> would break any compliant C++ compiler, they use keywords like:
>
> 1. sealed
> 2. ref
> 3. get
>
> Scattered across the Internet are statements like:
>
> "You're still coding in C++, and you can access the STL, the CRT, and
> any other C++ libraries, except that you can't invoke certain
> functions directly, such as those related to file I/O."
>
> If you use those three keywords in your code, you are ~not~ coding in
> C++. You're coding in something else that just so happens to share a
> lot of keywords and syntax with C++.

{ Please limit your text to fit within 80 columns, preferably around 70,
so that readers don't have to scroll horizontally to read each line.
This article has been reformatted manually by the moderator. -mod }

Yes. C++/CX and C++/CLI are effectively DSLs based on C++. I don't see a
problem.

"Pure C++" is IIRC, traditional name for series of articles on C++ on
MSDN. MS is not the guardian of "C++, The Name", and I don't see why
they should be.

I also don't see why I should get worked up about it.

If you need to interoperate with .NET or WinRT, C++/CX/CLI are some ways
to do it. Neither .NET or WinRT have anything to do with C++ itself, in
fact, both are +/- language-agnostic. MS way of crossing this chasm are
C++/CX, C++/CLI, and various other bits for other languages.

IOW: to access language-agnostic and platform-specific tech from a language,
you use implementation-specific, platform-specific tech. Whether that is a
library that implements a DSL in pure C++, or an implementation extension -
who cares? Resulting code is platform-specific either way.

Finally, if your problem is usage of the name "C++" - I don't think
there's a trademark on that, for one, and also, given the similarity and
the possibility to actually use "pure" C++ in this code, some other
name, not having "C++" in it, is none the better.

Goran.

[Martin B.]

On 04.07.2012 06:30, Ivan Godard wrote:
> On 7/3/2012 12:16 PM, Zeljko Vrba wrote:
>> On 2012-07-03, Le Chaud Lapin <jaibu...@gmail.com> wrote:
>
> <snip>
>
>> According to that criterion, C++/CX could possibly be viewed as a
>> separate language since MS docs say that extensions can be avoided
>> and that everything can be done with standard C++. Whether it
>> really IS a new language, or just an acceptable extension to C++,
>> depends on whether the developer is unreasonably burdened by using
>> ONLY ISO C++.
>
> You miss the point: CC++/CX is standard-conforming and can be called
> "C++" if and only if *any* standard-conforming program from a
> different system will successfully compile and (other than where the
> standard explicitly asserts behavior is undefined) execute correctly
> on the MS platform.
>
> As I understand it (as a non-CX user) C++/CX etc. fails this
> qualification trivially when the program uses MS "keywords" as
> identifiers. The UK report cites other examples of failure to conform.
>

I thought the UK report were about C++/CLI and not about C++/CX?

Anyway, can we please stop this hair splitting? I feel this is ridiculous.

So any compiler extension that adds new keywords not reserved and not
beginning with two underscores (that's the rule I think?) shouldn't be
"allowed" to call the resulting language C++? (Btw. last time I read up
on this, I may remember it wrong though, the MS keywords were context
sensitive, so I'm not even sure that (all) identifiers that are new
keywords would break such a program.)

As it stands, the MS C++ compiler is not 100% standard compliant (I'm
too lazy to look up specifics) but rather like a high 9x% percentage IIRC.

So you guys please go and write a non-contrived standard C++ example
that severely breaks because of the CLI (or CX) extension.

cheers,
Martin


--
Good C++ code is better than good C code, but
bad C++ can be much, much worse than bad C code.

[Martin B.]

On 04.07.2012 00:11, Le Chaud Lapin wrote:
> On Tuesday, July 3, 2012 12:29:17 PM UTC-5, Roman W wrote:
>> On Tuesday, July 3, 2012 2:04:32 AM UTC+1, Le Chaud Lapin wrote:
>>
>>> Thus is the essence of my argument. A C++ standard's body, of all
>>> organizations, plainly stated that C++/CLI is not C++, yet Microsoft
>>> persists in saying that it is.
>>
>> I don't think Microsoft means it's C++ in the "ISO C++ standard" sense, just that
>> it's for practical purposes, C++. The string "C++" may mean different things in
>> different contexts. Such is human speech.
>
> I find it hard to believe that I am the only who sees that Microsoft has
> been engaged in a sustained, concerted, deliberate effort to divert as,
> many coders as possible from standard C++ to a .NET form of C++. The
> supporting evidence in this thread alone should be at least an indicator.
>

> 1. Microsoft hoped to get their C++/CLI standardize by ISO. ...

I find it hard to interpret that as a conspiracy against C++.


> ...

> Also, there is an interesting direct question posed on Code Project:
> "Is ISO C++ code directly compilable in C++/CLI?"
>
> One programmer responds:
> "NO IT WILL NOT"
>
> http://stackoverflow.com/questions/4206574/is-iso-c-code-directly-compilable-in-c-cli
>
> "According to the MSDN documentation it will. But it's a nasty lie.
> I have fallen into this trap. When already thousands LOC's were
> written, it turned out that CLI has problems with boost::thread.
> The latter just doesn't work. So I assume that there may be other
> things too. So just don't go there, that's my good advice."
>

And I will add a comment from that answer:

boost::thread isn't "vanilla ISO C++" to begin
with. It supports certain implementations, but if
C++/CLI isn't one of them it doesn't necessarily
prove anything. – Steve Jessop Nov 17 '10

To which I mostly agree.

>
> 4. Microsoft got Visual Studio Express into universities everywhere.
> Then they abruptly decided that it would only allow .NET
> development. Coders rebelled, and they relented...but the key
> point is that they tried.

>...

Can you please stop your MS bashing and first get the facts straight.

MS' (stupid) plan was for VS Express 2012 to only allow the development
of Metro style C++, that is C++/CX and has *zero* to do with .NET (which
is C++/CLI). In a Metro Style C++/CX application there is no .NET
runtime or overhead whatsoever.

cheers,
Martin

--
Good C++ code is better than good C code, but
bad C++ can be much, much worse than bad C code.

[Francis Glassborow]

On 04/07/2012 05:35, Le Chaud Lapin wrote:

> If Microsoft makes the mistake of omitting the /CLI or /CX qualifier
> when presenting C++/CLI or C++/CX code, that would be one thing, but
> the evidence on the Internet indicates, at least to me, that there is
> a a deliberate campaign of misrepresentation. This would be the
> logical next step, since ISO rejected their standardization effort,
> saying that they should at least give the language a new name first.
>
> -Le Chaud Lapin-
>

OK I think we are all reaching a level of agreement. When I proposed
delegating ctors for C++0x the Microsoft lead representative raised a
number of serious issues concerning such things as what exactly should
happen when a delegated ctor threw an exception. At what point was the
object complete requiring full destruction etc. The issues were quite
complex and after a space of 9 years I cannot summarise it. However the
most important issue was that what we wished to do (and eventually did)
conflicted with what Microsoft needed to do to support C++/CLI. That was
a direct example of why WG21 opposed fast tracking ECMA's C++/CLI
standard. We found it unacceptable that a secondary standard should
prevent us from doing what we believed to be in C++ programmers' best
interest.

It is in that context that C++/CLI (and possibly C++/CX) is a separate
language. It causes future compatibility issues. Whilst C++ is not a
trademark (wish that it were like Java in that respect) the use of C++
in the name C++/CLI was obviously going to cause confusion and exactly
because it was compatible with C++98 that, in BSI's (UK NB) view made it
unacceptable as an ISO Standard (there is an ISO rule prohibiting
multiple standards for the same language). If it was the same language
(but with extensions) then it was the responsibility of WG21 not ECMA to
produce and maintain a secondary standard covering the extensions and
that we had neither the time nor the motivation to do. If it was a
different language then its name was too similar and needed change.

Please note that Microsoft withdrew its application for fast-tracking
the ECMA Standard once it had been persuaded that the above was
essentially the case.

Yes, the world and Microsoft have moved on over the last 9 years and we
need to remain vigilant, especially that MS language implementers remain
conscious of the issues. That is best done by supporting the good and
persuading them that it is in their interests to avoid the bad and
problematic.

I have now largely retired from the arena (well I did celebrate my 70th
birthday last month so perhaps I am due a break) and no longer track
every new development. I hope that MS continues to produce compilers
that support pure C++. I note that it quickly responded to the concerns
raised wrt the proposed express version of VS 2012. It is that
responsiveness that we should welcome and encourage.

The express versions of its IDE need to provide a good student
environment and help those who want to use similar tools at home to
those they use at work. Though the latter might be better supported by
some form of extended license based on their employers. It would be nice
to have a Home/Student edition of VS to go alongside the Home/Student
editions of MSOffice.

Francis

[Gerhard Fiedler]

On 2012-07-03 19:11:36, in comp.lang.c++.moderated Le Chaud Lapin wrote:

> I find it hard to believe that I am the only who sees that Microsoft
> has been engaged in a sustained, concerted, deliberate effort to
> divert as, many coders as possible from standard C++ to a .NET form
> of C++. The supporting evidence in this thread alone should be at
> least an indicator.

That may be, and IMO this is their right. But for me at least, it's
pretty obvious that anything that is not "ISO C++" or "C++ conforming to
ISO ..." or something like this is not "ISO C++". It's as simple as
that.

Any prospective C++ programmer needs to know this, from before writing
the first line of code. You can't just go out there, take some C++
example code and expect that it will compile and work on your
combination of hardware, OS and compiler -- unless it is specifically
"ISO C++" (or something like this), and you have a setup that supports
"ISO C++".

This is nothing new with Microsoft. Many programs and snippets out there
claim to be C++ and don't compile or run on many C++ environments -- be
it OS or hardware dependencies, be it dependencies on compiler
extensions, be it dependencies on libraries that introduce OS, hardware
or compiler dependencies. This is just something one needs to know.

And once one knows that, it is obvious that "C++/CLI" or "C++/CX" is not
"ISO C++" until proven (which may also mean "generally recognized by
qualified people") to be so.

Gerhard

[Tobias Müller]

Le Chaud Lapin <jaibu...@gmail.com> wrote:

> I find it hard to believe that I am the only who sees that Microsoft has
> been engaged in a sustained, concerted, deliberate effort to divert as,
> many coders as possible from standard C++ to a .NET form of C++.

But not because they don't like standard C++, but because they don't want
no more Windows Applications written with old APIs like plain WinAPI, MFC,
ATL, etc. They wan't people to use modern APIs like WPF, WCF...
Those are all .Net APIs and it is just not possible to use them in standard

C++.

> The supporting evidence in this thread alone should be at least an indicator.

Well, the alternative would be just no C++ support at all for .Net APIs,
and thus for modern Windows programming. That's just pragmatic.

> [...]

> 2. In the ECMA specification, it is written:
> "This specification is a superset of Standard C++." Page 10 of:
>
> http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-372.pdf

Until now noone on this thread could disprove that.

> But ISO UK found that C++/CLI is a new language. These two standards
> bodies cannot both be right. Either it is a new language or it is not.

What's the reasoning of the ISO commitee?

> Also, there is an interesting direct question posed on Code Project:

You probably mean StackOverflow

> "Is ISO C++ code directly compilable in C++/CLI?"
> One programmer responds:
> "NO IT WILL NOT"

An answer on StackOverflow from "One Programmer" is not exactly what I
would call a reliable source.

> http://stackoverflow.com/questions/4206574/is-iso-c-code-directly-compilable-in-c-cli
> "According to the MSDN documentation it will. But it's a nasty lie.
> I have fallen into this trap. When already thousands LOC's were
> written, it turned out that CLI has problems with boost::thread.
> The latter just doesn't work. So I assume that there may be other
> things too. So just don't go there, that's my good advice."

That answer has not even a single upvote. Quite in contrary, there is a
good comment to that answer (4 upvotes):
<quote>

boost::thread isn't "vanilla ISO C++" to begin with. It supports certain
implementations, but if C++/CLI isn't one of them it doesn't necessarily

prove anything. – Steve Jessop Nov 17 '10 at 16:51
</quote>

> 3. Microsoft had a column called "Pure C++". The strategy here is based
> on psychological pre-emption. It works like this: You're trying out
> various motorcycles to buy, and the one you like has very low power.
> The salesmen know this is a problem, so they put out ads saying,
> "Feel The Power!!!" One says the exact opposite of what the customer
> is thinking. In this case, the C++ is ~not~ pure, so you preempt the
> customer by calling it pure up-front.
>
> http://msdn.microsoft.com/en-us/magazine/cc163852.aspx

That article was referring to a Beta Version of Visual Studio 2005. In the
final article (just read the red text and follow the link) the summary (and
similarly the first Paragraph of the article) is
<quote>
C++/CLI is a self-contained, component-based dynamic programming language
that, like C# or Java, is derived from C++. In fact, you can look at it as
a natural step in the evolution of C. Stanley Lippman, who was there from
the beginning, provides some insight.
</quote>
That's not really misleading, even if probably most C++ programmers don't
see that step as a natural one.

> 4. Microsoft got Visual Studio Express into universities everywhere.
> Then they abruptly decided that it would only allow .NET
> development. Coders rebelled, and they relented...but the key
> point is that they tried.

See my first comment, this is not about languages but about APIs.

> 5. An article was written on Code Project by someone with the
> alias Qwertie called:
> "Head-to-head benchmark: C++ vs .NET"
>
> http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET
>
> The article is professional grade.
> It should take perhaps 30-60 seconds to figure out which prominent
> C++ expert, working for Microsoft, is behind this article.

What's your point?

> 6. Microsoft, having been successful at fast-tracking C++/CLI through ECMA,
> figured that the pipe would be greased for ISO standardization.
> As pointed out, ISO UK/France/Germany/etc. proved them wrong.

That's point 1 & 2 again. Already commented that.

> 7. Microsoft, in its MSDN documentation, has had a long history of making
> a distinction between Standard C++ constructs, and those that are
> "Microsoft-specific", which is precisely the label that they use for
> those things that are Microsoft-specific. But for CLI, they deliberately
> omitted the "Microsoft-specific" annotation until some in the community
> complained. They started revising their documentation to point out
> that CLI was Microsoft-specific.

Probably because that set of extensions has a name (CLI) and they thought
that it would be clear from that name that it was not standard ISO C++.
previous extensions were just single extensions here and there, that makes
it necessary to mark them as such.

That's really misleading, you're right.

> I could go on with hundreds of examples like this from across the
> Internet of text and videos where Microsoft essentially claim that
> C++/CLI is the future of C++, as well as show the confusion that
> resulted when programmers asking if their ISO C++ will work under
> C++/CLI context or not, etc..

"The future of C++" is certainly wrong, a "Natural step in the evolution of
C++" (as in the cited article) is merely an opinion or a marketing phrase.
When programmers meet marketing people there's always confusion ;-)

Tobi

[Dave Abrahams]

on Mon Jul 02 2012, Le Chaud Lapin <jaibuduvin-AT-gmail.com> wrote:

> On Sunday, July 1, 2012 7:15:45 AM UTC-5, Zeljko Vrba wrote:
>> { Please avoid useless quotes, but do provide the minimum
>> necessary to establish context -mod }
>> On 2012-07-01, Le Chaud Lapin wrote:
>
>> Also, a question for you: many C++ projects can be compiled with
>> MSVC and GCC, i.e., they are syntactically correct ISO C++
>> programs. Yet, they rely on behavior that is UB according to the
>> standard, but which both compilers define in a useful way. Since
>> code exhibiting UB at run-time is technically not "valid C++ code",
>> should the authors of such projects be allowed to say that they are
>> coding in C++?
>
> Because such UB code would be, in fact, valid C++. About this code,
> the standard would say: "This code is will be compiled by a
> conforming compiler, but the behavior would be undefined.

Actually, it would say "undefined behavior; no diagnostic required."
When code has undefined behavior, the compiler is free to diagnose it
as soon as it can, including at runtime or even at compile-time. It's
just that in some cases, the standard either can't or doesn't mandate
such diagnosis.

Cheerily,

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

[Edek Pienkowski]

Dnia Wed, 04 Jul 2012 09:17:26 -0700, goran.pusic napisal:

> On Sunday, July 1, 2012 9:12:43 AM UTC+2, Le Chaud Lapin wrote:
>>
>> I asked a rhetorical question in a recent post, and the post was
>> rejected, perhaps because I did not explain why I was asking the
>> question. The question was:
>>
>> "Is this valid C++ code or not?"
>>
>> "this" was code like:
>>
>> // Is this C++?
>> SyndicationClient^ client = ref new SyndicationClient();
>> for(wstring url : urls)
>> // Perhaps it is, and my compiler is simply out of compliance.
>>
>> ...found on this page:
>>
>> http://msdn.microsoft.com/en-us/library/windows/apps/hh465045.aspx
>>
>> The Moderator pointed out that it was obviously not.
>>
>> I asked the question because I believe that Microsoft is being
>> somewhat untruthful when they persist in calling C++/CX or C++/CLI
>> or C++/whatever "C++".
>>
>> It is not. And it is harmful to the integrity of C++ to do so,
>> IMHO.
>>
>> If it were C++, I would be able to compile it with my
>> highly-accommodating C++ compiler.
>>
>> Microsoft has been, for years, attempting to mislead C++
>> programmers into thinking that their "variants" of C++ is

>> essentially C++ with a [...]

>
> Yes. C++/CX and C++/CLI are effectively DSLs based on C++. I don't
> see a problem.

When a new language is created, usually the creator can choose a name
for it. There were a lot of possible names which do not contain the
substring "C++". It could have been called "RuteCLI" or whatever. Why,
isn't it a reasonable name? Then there were a lot of other options.

> "Pure C++" is IIRC, traditional name for series of articles on C++
> on MSDN. MS is not the guardian of "C++, The Name", and I don't see
> why they should be.

Out of pure decency, one does not call "nat. gas" something which you
cannot be used as natural gas. Unless of course one wants to dump a
lot of one's product in the market with the hope that their product
will be called "natural gas" and not the commodity which has always
been called natural gas, or at least that they will be confused. Try
that on any exchange market and you will find that there are
regulations, and that these regulations are a Good Thing. And the
regulations are arbitrary, they are agreed upon.

Now, I cannot even read C++/CLI, I just don't understand it. It is not
C++ with extensions, I would understand the core language with
extensions if they are nicely separated, like __attribute__((aligned))
or something. I could ignore extensions for a moment and understand
the language. C++/CLI changes the core semantics and the fact that
these are addons one does not have to use does not change this basic
fact. Compatibility goes both ways. If C++/CLI with the addons used
would still work when compiled when C++ compiler, maybe with some
performance degradation, I would be fine with it. Different #pragma's
are an example of such a feature, they can be substituted easily with
something else that just does the same job - "easily" is the key word
- like #pragma once can be substituted.

[...]

> Finally, if your problem is usage of the name "C++" - I don't think
> there's a trademark on that, for one, and also, given the similarity
> and the possibility to actually use "pure" C++ in this code, some
> other name, not having "C++" in it, is none the better.

I think most people would be upset if they were sold some goldish
looking metal at the price of gold. But "gold" is not any trademark as
far as I know, so you wouldn't see any problem, would you? I mean, no
one protects the term "gold", so everyone can call whatever they
choose "gold". Are you fine with that? It will look goldish, and it
would contain some "pure" gold in it...

Edek Pienkowski

[Tobias Müller]

Edek Pienkowski <edek.pi...@gmail.com> wrote:
> [...]

> When a new language is created, usually the creator can choose a name
> for it. There were a lot of possible names which do not contain the
> substring "C++". It could have been called "RuteCLI" or whatever. Why,
> isn't it a reasonable name? Then there were a lot of other options.

Then why does the name "C++" contain the substring "C"?

>> "Pure C++" is IIRC, traditional name for series of articles on C++
>> on MSDN. MS is not the guardian of "C++, The Name", and I don't see
>> why they should be.
>
> Out of pure decency, one does not call "nat. gas" something which you
> cannot be used as natural gas. Unless of course one wants to dump a
> lot of one's product in the market with the hope that their product
> will be called "natural gas" and not the commodity which has always
> been called natural gas, or at least that they will be confused. Try
> that on any exchange market and you will find that there are
> regulations, and that these regulations are a Good Thing. And the
> regulations are arbitrary, they are agreed upon.

If "pure C++" is the name of a series of articles in C++, then why
shouldn't it be allowed to present/discuss C++/CLI in one of those
articles? I mean this is comp.lang.c++.moderated and we're doing the same.

> Now, I cannot even read C++/CLI, I just don't understand it. It is not
> C++ with extensions, I would understand the core language with
> extensions if they are nicely separated, like __attribute__((aligned))
> or something. I could ignore extensions for a moment and understand
> the language. C++/CLI changes the core semantics and the fact that
> these are addons one does not have to use does not change this basic
> fact. Compatibility goes both ways. If C++/CLI with the addons used
> would still work when compiled when C++ compiler, maybe with some
> performance degradation, I would be fine with it. Different #pragma's
> are an example of such a feature, they can be substituted easily with
> something else that just does the same job - "easily" is the key word
> - like #pragma once can be substituted.

As the name already suggests, you should know C++ but also CLI to
understand it. If you do, most of it is pretty obvious IMO.

> [...]
>> Finally, if your problem is usage of the name "C++" - I don't think
>> there's a trademark on that, for one, and also, given the similarity
>> and the possibility to actually use "pure" C++ in this code, some
>> other name, not having "C++" in it, is none the better.
>
> I think most people would be upset if they were sold some goldish
> looking metal at the price of gold.

If I buy something called gold/copper I'd be a fool to believe that it was
pure gold.

> But "gold" is not any trademark as
> far as I know, so you wouldn't see any problem, would you? I mean, no
> one protects the term "gold", so everyone can call whatever they
> choose "gold". Are you fine with that? It will look goldish, and it
> would contain some "pure" gold in it...

Just as all golden rings are made of 100% pure gold?

Tobi

[Robert Wessel]

On Fri, 6 Jul 2012 11:55:29 -0700 (PDT), Edek Pienkowski
<edek.pi...@gmail.com> wrote:

>Dnia Wed, 04 Jul 2012 09:17:26 -0700, goran.pusic napisal:

(...)

Would this argument not prohibit the name "C++" itself? After all,
idiomatic C++ is pretty incomprehensible to anyone knowing only C. As
the C folks never tire of pointing out, C++ is not a strict superset
of C, and they even raise the issue of new keywords (as has been done
in this thread about one or both of the MS extensions). And certainly
the name "C++" was picked *precisely* to indicate it was an extension
of C. Why is "C++/CX" or "C++/CLI" different?

And to quibble with your natural gas analogy - consider biodiesel,
which is chemically a fair bit different than the regular stuff, but
compatible in some, but definitely *not* all, applications.

[Le Chaud Lapin]

On Friday, July 6, 2012 5:29:57 PM UTC-5, Robert Wessel wrote:
> On Fri, 6 Jul 2012 11:55:29 -0700 (PDT), Edek Pienkowski
> wrote:

> >Out of pure decency, one does not call "nat. gas" something which
> >you cannot be used as natural gas. Unless of course one wants to
> >dump a lot of one's product in the market with the hope that their
> >product will be called "natural gas" and not the commodity which
> >has always been called natural gas, or at least that they will be
> >confused. Try that on any exchange market and you will find that
> >there are regulations, and that these regulations are a Good
> >Thing. And the regulations are arbitrary, they are agreed upon.

> Would this argument not prohibit the name "C++" itself? After all,
> idiomatic C++ is pretty incomprehensible to anyone knowing only C.
> As the C folks never tire of pointing out, C++ is not a strict
> superset of C, and they even raise the issue of new keywords (as has
> been done in this thread about one or both of the MS extensions).
> And certainly the name "C++" was picked *precisely* to indicate it
> was an extension of C. Why is "C++/CX" or "C++/CLI" different?

Because that is not what Microsoft is doing, however. What they are
doing is making "C++/CLI" synonymous with "C++". You will note also
that C++ is additive to C, not disruptive. C++ does not redefine the
semantics of keywords that are already extant in C.

While I agree with Edek that, out of respect for C++, Microsoft should
not be calling their new conceptual framework, C++/CLI, merely an
"extension" of C++/CLI, I was willing to make a concession here -
using "C++" in their name would be OK so long as there were some
modification to indicate that it was not ISO C++.

I spent an hour on the web yesterday scouring for a balanced
discussion on this matter [not that it is not balanced
here. ;)]. There were some interesting articles written by various
authors, but the discussion that was most revealing was one that
followed a video put forth by Microsoft, and, ironically, as you all
know, a senior member of the standardization committee for ISO C++,
entitled:

"Using the Windows Runtime from C++"
http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-532T

The video, and the ensuing comments, provide very good insight to the
various opinions that C++ programmers have on the current topic. The
comments, in particular, are quite illuminating.

-Le Chaud Lapin-

[Le Chaud Lapin]

On Wednesday, July 4, 2012 11:24:03 AM UTC-5, Francis Glassborow wrote:

[Snip of very insightful material, IMO.]

> It is in that context that C++/CLI (and possibly C++/CX) is a
> separate language. It causes future compatibility issues. Whilst C++
> is not a trademark (wish that it were like Java in that respect) the
> use of C++ in the name C++/CLI was obviously going to cause
> confusion and exactly because it was compatible with C++98 that, in
> BSI's (UK NB) view made it unacceptable as an ISO Standard (there is
> an ISO rule prohibiting multiple standards for the same
> language). If it was the same language (but with extensions) then it
> was the responsibility of WG21 not ECMA to produce and maintain a
> secondary standard covering the extensions and that we had neither
> the time nor the motivation to do. If it was a different language

> then its name was too similar and needed change. I have now largely

> retired from the arena (well I did celebrate my 70th birthday last
> month so perhaps I am due a break) and no longer track every new
> development. I hope that MS continues to produce compilers that
> support pure C++. I note that it quickly responded to the concerns
> raised wrt the proposed express version of VS 2012. It is that
> responsiveness that we should welcome and encourage.

You have solidified my conviction that it is our responsibility,
individually and collectively, to guard the integrity of C++, and that
includes protecting the definition of what constitutes C++ and what
does not.

I do have one question regarding trademarks:

Was it not the case that "C" was once a trademark of AT&T Bell Labs?

I gave my K&R to a student a long time ago, and never got a
replacement, but I remember seeing something to that effect in
the colophon.

-Le Chaud Lapin-

[Edek Pienkowski]

Dnia Fri, 06 Jul 2012 15:27:26 -0700, Tobias Müller napisal:

> Edek Pienkowski <edek.pi...@gmail.com> wrote:
>> [...]
>> When a new language is created, usually the creator can choose a name
>> for it. There were a lot of possible names which do not contain the
>> substring "C++". It could have been called "RuteCLI" or whatever. Why,
>> isn't it a reasonable name? Then there were a lot of other options.
>
> Then why does the name "C++" contain the substring "C"?

Good point actually, but ISO had no objections to that.

>
>>> "Pure C++" is IIRC, traditional name for series of articles on C++ on
>>> MSDN. MS is not the guardian of "C++, The Name", and I don't see why
>>> they should be.
>>
>> Out of pure decency, one does not call "nat. gas" something which you
>> cannot be used as natural gas. Unless of course one wants to dump a lot
>> of one's product in the market with the hope that their product will be
>> called "natural gas" and not the commodity which has always been called
>> natural gas, or at least that they will be confused. Try that on any
>> exchange market and you will find that there are regulations, and that
>> these regulations are a Good Thing. And the regulations are arbitrary,
>> they are agreed upon.
>
> If "pure C++" is the name of a series of articles in C++, then why
> shouldn't it be allowed to present/discuss C++/CLI in one of those
> articles? I mean this is comp.lang.c++.moderated and we're doing the
> same.

"Pure C++" suggests that there is another C++, non-pure. Which is
not true, at least according to ISO. There is no agreement there is
another C++, only one company says so, although there are opinions
that back its position.

No one sells "pure natural gas" as far as I know. Just "natural gas".

>> [...]
>>> Finally, if your problem is usage of the name "C++" - I don't think
>>> there's a trademark on that, for one, and also, given the similarity
>>> and the possibility to actually use "pure" C++ in this code, some
>>> other name, not having "C++" in it, is none the better.
>>
>> I think most people would be upset if they were sold some goldish
>> looking metal at the price of gold.
>
> If I buy something called gold/copper I'd be a fool to believe that it
> was pure gold.

True, but it is standardized. I don't know the term for it in english,
but golden rings may have e.g. 99,5% of gold in it, and golden jewellry
makers usually attach this information when they are selling them. That
would be retail, I think it is mostly customary.

On the market when someone has to deliver it is well defined, so that
both buyers and sellers know what they are trading.

Edek

[Edek Pienkowski]

Dnia Fri, 06 Jul 2012 15:29:57 -0700, Robert Wessel napisal:

> On Fri, 6 Jul 2012 11:55:29 -0700 (PDT), Edek Pienkowski
> <edek.pi...@gmail.com> wrote:
>
>>Dnia Wed, 04 Jul 2012 09:17:26 -0700, goran.pusic napisal:
>>

>>Out of pure decency, one does not call "nat. gas" something which you
>>cannot be used as natural gas. Unless of course one wants to dump a lot
>>of one's product in the market with the hope that their product will be
>>called "natural gas" and not the commodity which has always been called
>>natural gas, or at least that they will be confused. Try that on any
>>exchange market and you will find that there are regulations, and that
>>these regulations are a Good Thing. And the regulations are arbitrary,
>>they are agreed upon.
>

> Would this argument not prohibit the name "C++" itself?[...]

>
> And to quibble with your natural gas analogy - consider biodiesel, which
> is chemically a fair bit different than the regular stuff, but
> compatible in some, but definitely *not* all, applications.

Most engines which run on diesel will also run on biodiesel. In general
biodiesel also has strict norms and its introduction did raise some
discussions.

I'll twist it further: only one company's engines run on "tomato
juice gasoline". While it is ingenious, they were asked what kind
of gasoline is that, and the statement was that their engines also
run on "pure gasoline", so the tomato juice is also called gasoline.

I am not sure if the flaw of this reasoning is obvious or not, but
if I pour diesel in my car the effect would be about the same if
I pour tomato juice in it. I would need to have the car
transported to my mechanic, and he would just look at me with
deep worry and say nothing, maybe adding that my car runs
on gasoline, not diesel, and certainly not tomato juice.

But with C++/CLI there is no such problem for some. After all,
Visual Studio can compile both C++ and C++/CLI.

Edek

[Zeljko Vrba]

On 2012-07-07, Le Chaud Lapin <jaibu...@gmail.com> wrote:


> that C++ is additive to C, not disruptive. C++ does not redefine the
> semantics of keywords that are already extant in C.

You complained about MS redefining semantics of 'class' keyword, so
I'll give you an example of how C++ also redefined some keywords. In
C, given a function declared like

f(struct my_struct s);

[struct passed by value] I KNOW what's going to happen when it's called.
In C++ I MUST first look up the definition of my_struct, possibly also
of all its superclasses in order to determine what's going to happen.

So I'm wondering by which criterion in your book 'ref class' is
"redefining" semantics, but the above-described change is merely
"additive"?

[Robert Wessel]

On Fri, 6 Jul 2012 23:11:22 -0700 (PDT), Le Chaud Lapin
<jaibu...@gmail.com> wrote:

>On Friday, July 6, 2012 5:29:57 PM UTC-5, Robert Wessel wrote:

>> Would this argument not prohibit the name "C++" itself? After all,
>> idiomatic C++ is pretty incomprehensible to anyone knowing only C.
>> As the C folks never tire of pointing out, C++ is not a strict
>> superset of C, and they even raise the issue of new keywords (as has
>> been done in this thread about one or both of the MS extensions).
>> And certainly the name "C++" was picked *precisely* to indicate it
>> was an extension of C. Why is "C++/CX" or "C++/CLI" different?
>
>Because that is not what Microsoft is doing, however. What they are
>doing is making "C++/CLI" synonymous with "C++". You will note also
>that C++ is additive to C, not disruptive. C++ does not redefine the
>semantics of keywords that are already extant in C.

While most of the examples are relatively minor, there certainly are
cases of C++ redefining the meaning of C constructs. Consider:

int f();

In C, this declares a functions taking unspecified number of
parameters, in C++, it's basically equivalent to "int f(void);" in C.

C++ doesn't automatically convert void pointers.

C++ struct definitions automatically create a type name.

C++ defines character literals ('a') to be of type char, instead of
int, as in C.

Heck, even the introduction of single line comments in C++ can change
the meaning of a well defined C program (although the case is a bit
convoluted, and probably unlikely to occur in the real world).

As I mentioned, most of these are relatively minor (unless one of them
bites you in a large codebase, of course), but where do you draw the
line?

[Zeljko Vrba]

On 2012-07-07, Edek Pienkowski <edek.pi...@gmail.com> wrote:
> Dnia Fri, 06 Jul 2012 15:27:26 -0700, Tobias M�ller napisal:

>
>>
>> If "pure C++" is the name of a series of articles in C++, then why
>> shouldn't it be allowed to present/discuss C++/CLI in one of those
>> articles? I mean this is comp.lang.c++.moderated and we're doing the
>> same.
>
> "Pure C++" suggests that there is another C++, non-pure. Which is

In this context, I understand the word "pure" being used as an
attribute of the series of articles, and NOT as an attribute of
the proper name C++.

If I saw a *single* article named "Pure C++", I'd expect it to
describe differences between ISO C++ and various extensions.

Now that I know that "Pure C++" is a *series* of articles (I haven't
read it), I'd expect the series to be ONLY about C++, i.e., I wouldn't
expect an article about, say, Visual Basic.

[Le Chaud Lapin]

On Saturday, July 7, 2012 2:53:53 PM UTC-5, Zeljko Vrba wrote:

> On 2012-07-07, Le Chaud Lapin wrote:
>> that C++ is additive to C, not disruptive. C++ does not redefine the
>> semantics of keywords that are already extant in C.
>
> You complained about MS redefining semantics of 'class' keyword, so
> I'll give you an example of how C++ also redefined some keywords. In
> C, given a function declared like
>
> f(struct my_struct s);
>
> [struct passed by value] I KNOW what's going to happen when it's called.
> In C++ I MUST first look up the definition of my_struct, possibly also
> of all its superclasses in order to determine what's going to happen.
>
> So I'm wondering by which criterion in your book 'ref class' is
> "redefining" semantics, but the above-described change is merely
> "additive"?

If I saw the code above, and someone asked me, "Is this C or C++?",
my answer would be: "It depends."

If the code is compiled with a C compiler, then it is C. If it
is compiled with a C++ compiler, then it is C++.

This is an example where there are two languages involved, and it
just so happens that the source script is syntactically valid
in both languages. As you pointed out, the semantics might be
different, depending on whether the members, bases, or self,
of struct mystruct s, have constructors.

What I would not do is say: "This C++ is C, or this C is C++."

By contrast, Microsoft adds entirely ~new~ keywords to to C++ and
calls it C++. So they actually making false statements in two ways:

1. Because the keywords are the same, and syntax is more or less the
same, it is the same language, even though semantics change.

[You just demonstrated above that this is not necessarily true.]

2. It is the same language even though we added keywords to the
fundamental core of the language.

[It should be obvious to any C++ programmer that this is not true.]

-Le Chaud Lapin-