C++/CLI - Microsoft Persists With Suggestive Marketing
Le Chaud Lapin
http://msdn.microsoft.com/msdnmag/issues/06/00/PureC/default.aspx
"C++/CLI is a self-contained, component-based dynamic programming
language that, like C# or Java, is derived from C++. Unlike those
languages, however, we have worked hard to integrate C++/CLI into
ISO-C++, using the historical model of evolving the C/C++ programming
language to support modern programming paradigms. You can say that
C++/CLI is to C++ as C++ is to C. More generally, you can view the
evolution leading to C++/CLI in the following historical context:
BCPL (Basic Computer Programming Language)
B (Ken Thompson, original UNIX work)
C (Dennis Ritchie, adding type and control structure to B)
C with Classes (~1979)
C84 (~1984)
Cfront, release E (~1984-to universities)
Cfront, release 1.0 (1985-to the world )-20th birthday
Multiple/Virtual Inheritance (MI) programming (~1988)
Generic Programming (~1991) (templates)
ANSI C++/ ISO-C++ (~1996)
Dynamic Component programming (~2005) (C++/CLI)"
"You can say that C++/CLI is to C++ as C++ is to C."
Hmmm...is this true?
I find it offensive that Microsoft continues with this suggestive
marketing. I find it even more disturbing that so many programmers
succumb to it. C++ did not "evolve" to CLI. What acutally happened is
that Microsoft believed in some non-sense that it is possible to create
objects that can be wielded from any language while pretty much keeping
the language unchanged. Of course, this did not work (COM), and when
it (barely) did, it was too ugly to bear (even with special keywords
and compilers). So they created C#, and also CLI. Now they are trying
mutate C++ since it is obviously "defective" as it is not quite how
they need it to be to fit with their "types
-are-universal-between-languages" model. I wait for the day when all
programmers will see the error in this mode of thinking - *TYPE* is
fundamental to a language. As a matter of fact, if a programmer
becomes aware of any new language, one of the first questions that
comes to mind is, "What are it's fundamental data types?"
But getting back to the list above, up until the last line, we see
things that were created by academics whose primary objective was to
create something whose most important trait was its own virtue. With
CLI, certainly Microsoft will acknowledge that the primary objective is
to add something to the language that "enables" interaction between
multiple languages. The historical timeline would be entirely accurate
if they would simply eliminate the last line. Few programmers have been
asking for anyone to kill the type system in C++, add new keywords, an
entirely new compiler, and a virtual machine to run the compiled code .
*Microsoft* asked for that, and we need to keep this in mind and beware
of suggestive marketing.
-Le Chaud Lapin-
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Alan Griffiths
> Few programmers have been
> asking for anyone to kill the type system in C++, add new keywords, an
> entirely new compiler, and a virtual machine to run the compiled code .
True, but then no-one is doing this to C++. The "few programmers" that
want this are welcome to their new, hybid language.
The issue for C++ the confusion being caused by not clearly presenting
C++/CLI as a distinct new language.
(More about this here:
http://www.octopull.demon.co.uk/editorial/OverloadEditorial200601.pdf)
--
Alan Griffiths
John Ratcliffe
> The following quotation is copied verbatim from:
>
> http://msdn.microsoft.com/msdnmag/issues/06/00/PureC/default.aspx
>
> "C++/CLI is a self-contained, component-based dynamic programming
> language that, like C# or Java, is derived from C++. Unlike those
> languages, however, we have worked hard to integrate C++/CLI into
> ISO-C++, using the historical model of evolving the C/C++ programming
> language to support modern programming paradigms. You can say that
> C++/CLI is to C++ as C++ is to C. More generally, you can view the
> evolution leading to C++/CLI in the following historical context:
>
> BCPL (Basic Computer Programming Language)
> B (Ken Thompson, original UNIX work)
> C (Dennis Ritchie, adding type and control structure to B)
> C with Classes (~1979)
> C84 (~1984)
> Cfront, release E (~1984-to universities)
> Cfront, release 1.0 (1985-to the world )-20th birthday
> Multiple/Virtual Inheritance (MI) programming (~1988)
> Generic Programming (~1991) (templates)
> ANSI C++/ ISO-C++ (~1996)
> Dynamic Component programming (~2005) (C++/CLI)"
>
> "You can say that C++/CLI is to C++ as C++ is to C."
>
> Hmmm...is this true?
It suits Microsoft to present it this way because it is part of their
promotion for .NET. BCPL, C and C++ are platform agnostic.
Microsoft have a range of marketing techniques that have proved successful
down the decades. A common technique is to present ideas and technologies
as though they have just thought of them, even though these may have been
around for years. This is a variation of that approach. It demonstrates a
proven pedigree, thereby reducing fears about risk and new technologies,
alongside a visionary future. It is not a coincidence that the future is a
Microsoft one.
Technology is what they sell. Does the world *really* need a new operating
system every few years? Or a new programming language? They have to do
these things because they are a business, and a very successful one. They
have to work hard at maintaining existing customers and finding new ones if
they wish to continue as a successful business.
> But getting back to the list above, up until the last line, we see
> things that were created by academics whose primary objective was to
> create something whose most important trait was its own virtue. With
> CLI, certainly Microsoft will acknowledge that the primary objective is
> to add something to the language that "enables" interaction between
> multiple languages. The historical timeline would be entirely accurate
> if they would simply eliminate the last line.
It has been possible to write systems in mixed languages for decades,
leveraging the best features of each language. A platform like .NET was not
required. Granted it has some benefits, but it does not solve all
programming problems.
> Few programmers have been
> asking for anyone to kill the type system in C++, add new keywords, an
> entirely new compiler, and a virtual machine to run the compiled code .
The power and flexibility of C++ has made it a popular and widely used
language. Microsoft are riding on the back of that.
John Ratcliffe
John Ratcliffe
> Microsoft believed in some non-sense that it is possible to create
> objects that can be wielded from any language while pretty much keeping
> the language unchanged. Of course, this did not work (COM),
COM was the Microsoft take on addressing issues that were also covered by
CORBA. Language neutrality, location transparency.... The silly thing was
that Microsoft started pushing it forward with certain goals - e.g. there
were many articles putting it forward as a solution to "DLL hell*" - and
then broke their own marketing with the direction they took VB. VB pretty
much hid the workings of COM.
* a problem they caused in the first place!
> and when
> it (barely) did, it was too ugly to bear (even with special keywords
> and compilers). So they created C#, and also CLI.
>From where I sit C# seems to be the direct result of the tiff with Sun about
Java. The CLR/CLI thing is pure hype. Sure you can get some benefit from
rationalising the compiler back ends - you only have to translate one
Intermediate Language into machine executable code. It does support a
common type system across languages that help with multi-language
development. But this does not solve all development problems, it is just
another way of doing things that comes with its own limitations.
Ironically by providing the common back end they have reduced the need for
mixed language programming. Why bother developing C++/CLI, VB .NET and C#
when they all seem to be converging in syntax and .NET support?
Historically languages were commonly developed to support a particular
research need, a specific programming goal, or were seen as an improvement
to an existing language. There is more than a touch of the solution looking
for a problem here.
> *TYPE* is
> fundamental to a language. As a matter of fact, if a programmer
> becomes aware of any new language, one of the first questions that
> comes to mind is, "What are it's fundamental data types?"
Type, or absence of type, like LISP and Prolog. A language is just a tool in
the software development toolbox. Sometimes you want strong typing,
sometimes you don't.
Microsoft have invested billions in .NET and the technologies that go with
it. They have to push it to recover their investment. It doesn't mean they
are right or that their solution is the best. There is no Holy Grail in
software development.
John Ratcliffe
Edson Manoel
different language... and I think its main objective is to confuse
begginers even more... first there was those "managed" "extensions"
thing, and now this?
Object^ and Type^ ?? [Out] String^% ?? ref class sealed abstract ???
How do they dare to call it a natural evolution of C++??
My fear is that they begin to pu$h^H^H^H^H hype this thing on
universities as Sun did hype Java...
Le Chaud Lapin
> ISO should forbid Microsoft to call it C++... it is a completely
> different language... and I think its main objective is to confuse
> begginers even more... first there was those "managed" "extensions"
> thing, and now this?
>
> Object^ and Type^ ?? [Out] String^% ?? ref class sealed abstract ???
>
> How do they dare to call it a natural evolution of C++??
> My fear is that they begin to pu$h^H^H^H^H hype this thing on
> universities as Sun did hype Java...
Please tell me that that stuff I see up above is not something that I
would find in my C++ code. I have purposely avoided looking at CLI so
that I can maintain my frame of reference.
The more I learn about this, the more I am convinced that Microsoft is
not trying to evolve C++ but to subvert it.
-Le Chaud Lapin-
Aaron Graham
> not trying to evolve C++ but to subvert it.
Almost all new languages over the last 10 years have sprinkled the word
"dynamic" all over their feature set bullet point lists. "Dynamic
<insert feature here>" usually refers to some aspect of the language
that they've moved from the compile-time domain into the runtime
domain. To the uninitiated, this is a good thing. But usually it just
means that the compiler would have been too difficult to write, and
that the language design would have taken more effort and insight than
the designers were capable of producing.
In Microsoft's case, using a single CLR for all languages is less
expensive for many reasons. The first reason is mentioned above:
compiler and language design is simply easier. The other reasons are
more obvious. But a common CLR has another side effect: all languages
must be fundamentally similar in semantics, despite syntax differences.
C++ must be modified to move code "management" (template
instantiation, type checking, range checks, memory mgmt, etc.) from the
compiler and associated libraries to the run time system. This gives
Microsoft more control, since it's now possible to change the
implementation/behavior of the CLR on a whim and have all applications
immediately fall in line (or break). Microsoft has done this before
with DLLs but now they'll have more control over code they didn't
write. It could be a good thing, though Microsoft has _never_ shown
itself to be a good steward of my confidence.
When you add "dynamic <feature>" to C++, you're not adding anything at
all. You're taking something away! In fact, you're negating one of
the best aspects (to call it a feature is not enough) of C++: it gives
the compiler the information it needs to do things that compilers do
really well.
What depresses me more than anything about C++/CLI is that people like
Stan Lippman and Herb Sutter, people who have contributed greatly to
the C++ community in the past, are part of it. Their efforts have been
diverted to a black hole, a "language" that nobody (especially
Microsoft) will still be talking about in 10 years. Well meaning but
ignorant programmers will also be caught off-guard, fracturing the
development community even more, and continuing to make it difficult to
write good code in any language (for want of good implementations and
libraries).
Aaron
Chris Hills
Chaud Lapin <unorigina...@yahoo.com> writes
>Edson Manoel wrote:
>> ISO should forbid Microsoft to call it C++... it is a completely
>> different language... and I think its main objective is to confuse
>> begginers even more... first there was those "managed" "extensions"
>> thing, and now this?
>>
>> Object^ and Type^ ?? [Out] String^% ?? ref class sealed abstract ???
>>
>> How do they dare to call it a natural evolution of C++??
>> My fear is that they begin to pu$h^H^H^H^H hype this thing on
>> universities as Sun did hype Java...
>
>Please tell me that that stuff I see up above is not something that I
>would find in my C++ code. I have purposely avoided looking at CLI so
>that I can maintain my frame of reference.
>
>The more I learn about this, the more I am convinced that Microsoft is
>not trying to evolve C++ but to subvert it.
Just look at the Safe C and Safe C++ Library TR's and what MS is saying
about them then the ECMA C# and CLI and there is a pattern evolving.
It is a pity we let the Safe C library TR go through in the first place.
Though in reality as most C users are still using C90 + A1 what MS wants
to do with the current C standard is irrelevant to most of us.
As someone pointed out if you take all of it together soon the only
platform that you can compile "standard" code on will be Windows and
anything else will be "non-standard"
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Le Chaud Lapin
[excellent statements snipped]
> What depresses me more than anything about C++/CLI is that people like
> Stan Lippman and Herb Sutter, people who have contributed greatly to
> the C++ community in the past, are part of it. Their efforts have been
> diverted to a black hole, a "language" that nobody (especially
> Microsoft) will still be talking about in 10 years. Well meaning but
> ignorant programmers will also be caught off-guard, fracturing the
> development community even more, and continuing to make it difficult to
> write good code in any language (for want of good implementations and
> libraries).
Sigh. I feel exactly the same. I remember learning how to program
from P. J. Plauger back in the 1980's. At the time, I couldn't afford
a computer or a book on programming, so I would wait for second-hand
programming magazines from a nearby medical facility to read and then
imagine the the programs running. I did this for almost two years until
I could buy a Commodore Vic-20 (which incidentally caused me great
distress when it said that squrare-root of 49 was 6.99998). The thing
I appreciated the most about Plauger's writings was the clarity of
exposition, and the his evident appreciation for form and detail.
So when I read that Dinkumware would be writing libraries for C++/CLI,
with full knowledge of the ramifications that Plauger's tacit
endorsement would have on others, I was puzzled.
Good stewardship *is* the responsibility of those who lead. As Aaron
said, it is critical that people like Stan Lippman and Herb Sutter and
P. J. Plauger be extra careful about the company they keep and the
technology they espouse.
Too often we find this scenario in corporate struggles. One moment you
see David reloading his sling for the 10,000th time to hurl against
Goliath, and the next moment you see David and Goliath sitting
together, at a press conference, with someone from Gartner Group acting
as mediator. Goliath says: "David and I may have had our differences
in the past, but we have always shared a common vision of advancing the
efficacy weapons in combat, and I look forward to our mutually
beneficial relationship."
What I have yet to figure out is what Goliath is giving David to make
him promulgate the preposterous.
-Le Chaud Lapin-
kanze
[What he wrote is, in fact, very close to slander, and I'm
somewhat surprised that the moderators allows such personal
insinuations by...]
[...]
> Good stewardship *is* the responsibility of those who lead.
> As Aaron said, it is critical that people like Stan Lippman
> and Herb Sutter and P. J. Plauger be extra careful about the
> company they keep and the technology they espouse.
> Too often we find this scenario in corporate struggles. One
> moment you see David reloading his sling for the 10,000th time
> to hurl against Goliath, and the next moment you see David and
> Goliath sitting together, at a press conference, with someone
> from Gartner Group acting as mediator. Goliath says: "David
> and I may have had our differences in the past, but we have
> always shared a common vision of advancing the efficacy
> weapons in combat, and I look forward to our mutually
> beneficial relationship."
> What I have yet to figure out is what Goliath is giving David
> to make him promulgate the preposterous.
Maybe they don't find what they are promulgating so
preposterous. I find the insinuations that these people have
somehow been "bought off" insulting -- to date, I've seen more
changes in Microsoft policy than in Herb Sutter's positions
since Herb is with Microsoft, and I'm not sure how Plauger fits
into this discussion at all, except that Microsoft is one of his
customers (but far from the only one).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
david...@gmail.com
Aaron Graham wrote:
<snip>
> But a common CLR has another side effect: all languages
> must be fundamentally similar in semantics, despite syntax differences.
<snip>
I thought this was the case also but the disparate set of languages
that can now target .Net (Cobol, Python, C++, VB) shows this to be
false.
Cheers,
Dave Boyle
P.J. Plauger
news:1138713116.7...@o13g2000cwo.googlegroups.com...
As usual, Kanze says what needs saying with simple clarity.
My direct response would never have made it past the moderators.
Thanks, James.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Allan W
> "kanze" <ka...@gabi-soft.fr> wrote
> > [What he wrote is, in fact, very close to slander, and I'm
> > somewhat surprised that the moderators allows such personal
> > insinuations by...]
I've been surprised by this entire thread.
The original post was extremely close to that line,
and most of the posts since then have gone even further.
> > Maybe they don't find what they are promulgating so
> > preposterous. I find the insinuations that these people have
> > somehow been "bought off" insulting -- to date, I've seen more
> > changes in Microsoft policy than in Herb Sutter's positions
> > since Herb is with Microsoft, and I'm not sure how Plauger fits
> > into this discussion at all, except that Microsoft is one of his
> > customers (but far from the only one).
P.J. Plauger wrote:
> As usual, Kanze says what needs saying with simple clarity.
> My direct response would never have made it past the moderators.
Then thank you for making your response indirect, because I do want
to read whatever response I can.
But let's get specific.
I agree with Alan Griffiths, the real issue is that "C++/CLI" is
re-using
the name C++, instead of being presented as a new language. In fact,
Microsoft's support of pure C++ is very good -- you just have to know
how to ask for it.
John Ratcliffe talked about Microsoft's marketing techniques.
Off-topic,
I would have guessed... he didn't use the word evil, but it was
implied.
Please, did Microsoft invent marketing? In the 1970's I read a textbook
that basically suggested that the purpose of electricity was to allow
IBM to invent computers; it devoted 40 pages to explaining EBCDIC,
with 4 paragraphs at the end that said there was also this ASCII thing
but it wasn't very common. I haven't seen anyone recently calling IBM
evil.
John Ratcliffe also posted a message about "DLL Hell..." again,
off topic, but somehow it got through moderation.
Edson Manoel said "ISO should forbid Microsoft to call it C++"...
ISO doesn't own the name C++, nor should it. If someone wants to
claim that their implementation is "ISO-compliant," they're making
a very specific claim and will have to back it up... but let's please
remember that Microsoft (and lots of other vendors!) were selling
something called C++ *LONG* before either ANSI or ISO finished
with the first version of their standard...
The OP (Le Chaud Lapin) also lements the fact that Microsoft compilers
extend C++. As if they're the only ones that ever did.
I could say a lot more, but I think I ought to wrap it up now... the
free
market principle is that if you give customers something they want,
they'll pay for it... nobody is forcing you to use Microsoft, but they
must be doing something right. Anyone who says that everything
from Microsoft is evil, is even more wrong that anyone who buys
everything Microsoft says without question. If you must bash
Microsoft, at least double-check your facts... and be sure that
you're being at least somewhat fair!
Moderators, I know I've been off-topic and opinionated, but I'm just
replying to various other posts that have done the same... only fair
to let this through, I think.
David Abrahams
> Maybe they don't find what they are promulgating so
> preposterous. I find the insinuations that these people have
> somehow been "bought off" insulting -- to date, I've seen more
> changes in Microsoft policy than in Herb Sutter's positions
> since Herb is with Microsoft, and I'm not sure how Plauger fits
> into this discussion at all, except that Microsoft is one of his
> customers (but far from the only one).
I am not a fan of everything Microsoft's been doing, but as someone
who knows most of the major players mentioned here and who has no
ongoing relationship with MS, I have to agree with James. If I were
going to attack anything about these people, their integrity would
fall near the bottom of the list.
In fact, Microsoft's support for good old industry-standard C++98/03
has become quite good over the past few years. They've become a
strong supporter of the standard and of the process.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
Patrick May
> Aaron Graham wrote:
> > But a common CLR has another side effect: all languages must be
> > fundamentally similar in semantics, despite syntax differences.
>
> that can now target .Net (Cobol, Python, C++, VB) shows this to be
> false.
I believe the point of the original poster is that only a
subset/variant of C++ is supported by the CLR. The CLR can definitely
not support Common Lisp, for just one example.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
p...@spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
Le Chaud Lapin
David Abrahams wrote:
> "kanze" <ka...@gabi-soft.fr> writes:
>
> > Maybe they don't find what they are promulgating so
> > preposterous. I find the insinuations that these people have
> > somehow been "bought off" insulting -- to date, I've seen more
> > changes in Microsoft policy than in Herb Sutter's positions
> > since Herb is with Microsoft, and I'm not sure how Plauger fits
> > into this discussion at all, except that Microsoft is one of his
> > customers (but far from the only one).
>
> I am not a fan of everything Microsoft's been doing, but as someone
> who knows most of the major players mentioned here and who has no
> ongoing relationship with MS, I have to agree with James. If I were
> going to attack anything about these people, their integrity would
> fall near the bottom of the list.
I certainly did not mean to imply that there is lack of integrity in
any of the people mentioned. But what I would like to know, if given to
chance is to ask all of the gurus who espouse/embrace/support CLI with
C++...
"Do you have the same regard of C++/CLI as Microsoft does? When
Microsoft writes that CLI is merely a "natural evolution of C++", do
you actually believe this? Do you detect that Microsoft's marketing
literature could be misleading to the ignorant/naive/uninitiated?"
I would like to ask similar questions to the gurus and get
unadulterated answers. If any of them would respond to these questions
with unqualified "yes's", then I would have to accept that that is how
they really feel, and I doubt that I would have any suspicions of
collusion. What I am concerned with is that there might have been some
resistance early on, perhaps feelings of "no...Microsoft...that's not
quite right.." that gradually waned as the grind of time and
familiarity took its toll.
So, like many others who see CLI as corrosive to the language, and
given that we have such strong opinions about what constitutes simple
extensions versus gross violations of principle and purity, we'd simply
like to know, objectively and explicitly stated, exactly what is it
that the gurus really think.
-Le Chaud Lapin-
P.J. Plauger
news:1138803676.8...@g49g2000cwa.googlegroups.com...
> David Abrahams wrote:
>> "kanze" <ka...@gabi-soft.fr> writes:
>>
>> > Maybe they don't find what they are promulgating so
>> > preposterous. I find the insinuations that these people have
>> > somehow been "bought off" insulting -- to date, I've seen more
>> > changes in Microsoft policy than in Herb Sutter's positions
>> > since Herb is with Microsoft, and I'm not sure how Plauger fits
>> > into this discussion at all, except that Microsoft is one of his
>> > customers (but far from the only one).
>>
>> I am not a fan of everything Microsoft's been doing, but as someone
>> who knows most of the major players mentioned here and who has no
>> ongoing relationship with MS, I have to agree with James. If I were
>> going to attack anything about these people, their integrity would
>> fall near the bottom of the list.
>
> I certainly did not mean to imply that there is lack of integrity in
> any of the people mentioned.
Then you did a damn poor job of not implying that when you said:
: What I have yet to figure out is what Goliath is giving David to make
: him promulgate the preposterous.
> But what I would like to know, if given to
> chance is to ask all of the gurus who espouse/embrace/support CLI with
> C++...
>
> "Do you have the same regard of C++/CLI as Microsoft does?
No, I have my own regard, thank you very much.
> When
> Microsoft writes that CLI is merely a "natural evolution of C++", do
> you actually believe this?
Yes. In fact, if you read the papers submitted to WG21 the past
few years, by the very people who developed the current C++
Standard, you'll find them proposing much the same sorts of
extensions as have been incorporated into C++/CLI. An important
difference is that C++/CLI is out in the world now as prior art,
giving us all real-world experience. I was once taught that
this was the most desirable way to prove in enhancements to
a programming language before standardizing them.
> Do you detect that Microsoft's marketing
> literature could be misleading to the ignorant/naive/uninitiated?"
Sure, as can *most* marketing literature, and even quite a bit of
technical literature. You, and some others, see this as nefarious;
I see it as a common byproduct of simplification, promotion,
comparison, what have you. Could be some of the marketeers at
Microsoft, perhaps even people up the management line, have a few
nefarious purposes. I have no way of knowing one way or the other.
But the folks I do know at Microsoft have espoused in my presence
nothing but upright motives for doing what they've done; and those
motives are congruent with the concrete evidence I have seen.
> I would like to ask similar questions to the gurus and get
> unadulterated answers.
There's that integrity thing again -- why should you even *suspect*
that any of us would be motivated to adulterate an answer?
> If any of them would respond to these questions
> with unqualified "yes's", then I would have to accept that that is how
> they really feel, and I doubt that I would have any suspicions of
> collusion.
Why do they have to be unqualified? I personally don't give a rat's
patootie whether you suspect me of collusion, but I *do* object to
your making public statements to that effect as though they were
the obvious truth. You then compound it by setting a high bar for
us to jump over if we're to prove we're pure of heart.
> What I am concerned with is that there might have been some
> resistance early on, perhaps feelings of "no...Microsoft...that's not
> quite right.." that gradually waned as the grind of time and
> familiarity took its toll.
I really appreciate your concern. Sort of.
> So, like many others who see CLI as corrosive to the language, and
> given that we have such strong opinions about what constitutes simple
> extensions versus gross violations of principle and purity, we'd simply
> like to know, objectively and explicitly stated, exactly what is it
> that the gurus really think.
I think that C++ can be considered corrosive to Standard C. I feel
strongly that what many consider simple extensions made to C by
C++ are gross violations of principle and purity. In fact, given
the position that BSI seem to be working toward with C++/CLI, I'm
inclined to ask WG14 to petition ISO to rescind WG21's right to use
the letter C in the name of their language. ISO++ works for me.
Look, I've watched C++/CLI evolve over several years now. I've
attended more meetings than I'd like to count, at my expense,
reviewing the language as it's evolved, first within Microsoft
and then through ECMA standardization. I've influenced the final
ECMA standard only in small ways; some of the things I would
like to have seen changed were dismissed; but I can understand
why. You can't expect to alter the direction of an ocean liner
more than at tiny bit, and only from time to time.
I've also written STL for C++/CLI, several versions now in fact.
(Yes, my company got paid to do it, but it was nowhere near the
biggest source of revenue for us over the past couple of years.
And I *asked* for the work because I was enthusiastic about the
project.) Writing STL/CLR (or whatever they call it these days)
puts me in the top percentile of people with nitty-gritty
experience with C++/CLI. I can attest that:
1) C++/CLI is highly compatible with Standard C++. It's about
the most honest extension you could possibly expect.
2) It's an elegant and powerful language, in some important
ways distinctly *better* than Standard C++. Sure, it has its
surprises, but so did C and C++ when I learned them.
3) It's way better than the old Managed C++ kludge. Now VC++
is a first-class citizen in the .NET environment, not a
bare survivor.
Finally, it's worth observing that Microsoft *has* ceded control
of C++/CLI, and other parts of the .NET architecture, to ECMA.
I have no illusions about what that means -- Microsoft will
clearly dominate the ECMA committees for the foreseeable future.
Nevertheless, ceding control like that is more than just a
gesture; and it's something that Sun could never quite bring
itself to do with Java. So perhaps Microsoft deserves a bit
more credit for trying to be a good citizen, at least these
days, than some people are willing to concede.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Ted
"Allan W" <all...@my-dejanews.com> wrote in message news:1138739723....@o13g2000cwo.googlegroups.com...
> I could say a lot more, but I think I ought to wrap it up now... the
> free
> market principle is that if you give customers something they want,
> they'll pay for it... nobody is forcing you to use Microsoft, but they
> must be doing something right.
There's the common "misconception" at best, "propoganda" at worst.
<your favorite example of a company "doing it for the money and supplying
the wrong thing and marketing the crap out of it as long as the cash cow can
be milked" vs. "building the right thing", here>
Time to grow up kids. Everything is not how mommy said it was (especially
when money is involved).
Ted
Allan W
> > I could say a lot more, but I think I ought to wrap it up now... the
> > free
> > market principle is that if you give customers something they want,
> > they'll pay for it... nobody is forcing you to use Microsoft, but they
> > must be doing something right.
Ted wrote:
> There's the common "misconception" at best, "propoganda" at worst.
> <your favorite example of a company "doing it for the money and supplying
> the wrong thing and marketing the crap out of it as long as the cash cow can
> be milked" vs. "building the right thing", here>
This is unclear.
I think you're disagreeing with me, but you're VERY short on specifics.
What are you trying to say? That Microsoft should implement exactly
what the standard mandates, without ANY innovations at all?
If that's what you think, why? Are there any other companies that are
held to this standard?
> Time to grow up kids. Everything is not how mommy said it was (especially
> when money is involved).
Which one of my mother's statements do you object to?
Francis Glassborow
W <all...@my-dejanews.com> writes
>Ted wrote:
>> There's the common "misconception" at best, "propoganda" at worst.
>> <your favorite example of a company "doing it for the money and supplying
>> the wrong thing and marketing the crap out of it as long as the cash cow can
>> be milked" vs. "building the right thing", here>
>
>This is unclear.
>I think you're disagreeing with me, but you're VERY short on specifics.
>
>What are you trying to say? That Microsoft should implement exactly
>what the standard mandates, without ANY innovations at all?
>If that's what you think, why? Are there any other companies that are
>held to this standard?
I think some people (not you) do not distinguish between pure extensions
that carry no implications for the general idioms of a language and
those that radically modify them.
I believe that 'C with classes' became C++ exactly because the
designer(s) of C objected to the suggestion that the new language was
just C with something added on. BS could have stuck to his guns and
continued to call it 'C with classes' but he understood the objection
and responded to it.
Do names matter? Yes, IMNSHO, they very definitely do. The official
standard for Javascript is Ecmascript (sorry if I have the
capitalisation wrong).
If I wrote a Fortran compiler that accepted C++ source code would that
be primarily a Fortran or C++ compiler. It would depend on my
motivation. If my intent was to help Fortran programmers utilise some
C++ then it is an extended Fortran compiler. If, OTOH, it is intended to
support some use of Fortran source code in C++ then it is an extended
C++ compiler.
Now what is the motivation for the latest MS C++ compiler? I do not
know, but I am pretty sure that a compiler that abandons such
fundamentals as const correctness is not C++ as I know it.
I think MS have wrapped up two distinct compilers into one. The first is
becoming a pretty good C++ compiler (which makes it attractive to C++
programmers). The second is a compiler for a heavily modified language
which is superficially similar to C++ but has a whole bundle of idioms
that are nothing like the C++ most people here are accustomed to.
Quite apart from anything else, having a new distinct name for this
second language would make it much easier to talk about source code and
which 'language' it was intended for. If, for example we called the new
language Clipp, we could say that C++ supports const correctness and
Clipp does not. But more importantly it would avoid the confusion of
using C++ as an abbreviation for C++/CLI.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
kanze
> > > Maybe they don't find what they are promulgating so
> > > preposterous. I find the insinuations that these people
> > > have somehow been "bought off" insulting -- to date, I've
> > > seen more changes in Microsoft policy than in Herb
> > > Sutter's positions since Herb is with Microsoft, and I'm
> > > not sure how Plauger fits into this discussion at all,
> > > except that Microsoft is one of his customers (but far
> > > from the only one).
> > I am not a fan of everything Microsoft's been doing, but as
> > someone who knows most of the major players mentioned here
> > and who has no ongoing relationship with MS, I have to agree
> > with James. If I were going to attack anything about these
> > people, their integrity would fall near the bottom of the
> > list.
> I certainly did not mean to imply that there is lack of
> integrity in any of the people mentioned. But what I would
> like to know, if given to chance is to ask all of the gurus
> who espouse/embrace/support CLI with C++...
> "Do you have the same regard of C++/CLI as Microsoft does?
> When Microsoft writes that CLI is merely a "natural evolution
> of C++", do you actually believe this?
I think you put the quotes in the wrong place. Although I don't
feel very concerned by CLI, I rather suspect that it is "a
natural evolution of C++". It is not, however, "the natural
evolution" -- I doubt that there is one single "natural
evolution".
And let's face it: such evolutions are the price of success. I
don't see any Modula3/CLI, for example, although I suspect that
Modula3 would fit quite well in the CLI model. If you don't
like that kind of evolution, there's only one way to avoid it:
use a language that no one wants to evolve. Because in a domain
as dynamic as ours, anything that gets used will evolve. In
many different directions at once.
Another frequent poster here constantly talks about D. Another
"natural evolution" of C++.
At some point in the future, the standardization committee will
define a new version of C++. That will then become the
"official" evolution. But it will never be the only one.
> Do you detect that Microsoft's marketing literature could be
> misleading to the ignorant/naive/uninitiated?"
Isn't that what marketing literature is for? Look at how Sun
sold Java. For that matter, look at how Walter Bright sells D.
Do you really expect to take all marketing claims at their face
value?
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kolaric
> re-using the name C++, instead of being presented as
> a new language.
I agree with Griffiths as well.
David Pottruck, former CEO of Schwab, was once
asked "what do you do when you don't have a moat"?
(Moat = means to protect your business.) He answered:
"I keep trying to move the castle". (Castle = business.)
Le Chaud Lapin
> Le Chaud Lapin wrote:
> > David Abrahams wrote:
> Do you really expect to take all marketing claims at their face
> value?
No I don't. That's why it is so important for the experts to be clear
in their guidance, When the young/ignorant/naive get confused and their
radars start going off, the first thing they do is try to find an
honest, facts-based, objective opinion. Maybe they will read their
favorite blogger, or maybe they will go to someone whose opinion they
have trusted for 20 years. This is all they can do, because, unlike
most of you, they are not yet able to effectively evaluate the
long-term implications of "evolutions" like CLI. If it is the case
that CLI is bad for C++, then someone with clout must take the
responsibility of checking them at the early stages.
In any case, I would like to issue a direct apology to P.J. Plauger and
anyone else whom I have offended by insinuating that there is collusion
with Microsoft.
-Le Chaud Lapin-
Gabriel Dos Reis
[...]
| In fact, given
| the position that BSI seem to be working toward with C++/CLI, I'm
| inclined to ask WG14 to petition ISO to rescind WG21's right to use
| the letter C in the name of their language. ISO++ works for me.
I'm sure some are awaiting the ballot on the matter.
--
Gabriel Dos Reis
g...@integrable-solutions.net
kanze
> kanze wrote:
> > Le Chaud Lapin wrote:
> > > David Abrahams wrote:
> > Do you really expect to take all marketing claims at their
> > face value?
> No I don't. That's why it is so important for the experts to
> be clear in their guidance,
But where have the experts mislead? I've not seen marketing
drivel written by Herb Sutter or Stan Lipman.
It's important to realize that large companies -- or large
organizations in general -- have split personalities. Different
departments have different agendas, and they don't always
communicate as well as they should. So the marketing droids
spit out marketing drivel, and the technical people continue to
do good technical work, and produce reasoned and rational
technical content. When I want technical information about a
product, I keep this in mind. For small companies, this is not
a problem: if I ask Plauger about Dinkumware, or Bright about
Mars, I feel confident that any marketing statements will be
based on concrete technical facts. If I ask the sales
department of Microsoft or of Sun, I don't believe anything they
say until I've got a confirmation from someone technical. Even
without a conscious desire to fraud, communication in large
companies being what it is...
And of course, that has nothing to do with C++, or even data
processing. If I want to technically evaluate a new car that
I'm purchasing, I don't ask the salesman -- I try to find
someone who actually has the model, or I read articles in the
automotive press. So this attitude is something that we can
expect from C++ newbies as well.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
David Abrahams
> kanze wrote:
>> Le Chaud Lapin wrote:
>> > David Abrahams wrote:
>> Do you really expect to take all marketing claims at their face
>> value?
No, I did *not* write that. Please watch your attributions to make
sure they're accurate.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Andrew Browne
news:b$apxJam1...@robinton.demon.co.uk...
> Now what is the motivation for the latest MS C++ compiler? I do not
> know, but I am pretty sure that a compiler that abandons such
> fundamentals as const correctness is not C++ as I know it.
>
> I think MS have wrapped up two distinct compilers into one. The first is
> becoming a pretty good C++ compiler (which makes it attractive to C++
> programmers). The second is a compiler for a heavily modified language
> which is superficially similar to C++ but has a whole bundle of idioms
> that are nothing like the C++ most people here are accustomed to.
>
> Quite apart from anything else, having a new distinct name for this
> second language would make it much easier to talk about source code and
> which 'language' it was intended for. If, for example we called the new
> language Clipp, we could say that C++ supports const correctness and
> Clipp does not. But more importantly it would avoid the confusion of
> using C++ as an abbreviation for C++/CLI.
The main confusion I see at the moment is that many people appear to believe
that C++/CLI is a variant or subset language with superficial syntactic
similarities to C++ but which does not support C++ in its entirety. (If this
were actually the case then I would entirely agree that the name should be
changed.) As it is, apart from some very minor incompatibilities, code that
is intended for C++ is also valid C++/CLI code with its meaning preserved.
All the idioms and features that are supported in C++ are therefore
supported at least as much in C++/CLI.
What is, of course, true is that you cannot use some of these idioms and
features in an unconstrained or unchanged way with CLR "managed" types. To
take the example of const correctness, it isn't currently possible for a
member function of a managed type to be qualified with const or volatile.
(Herb Sutter has said in this newsgroup, however, that a future revision may
support this.) I feel, though, that to say that this means that the compiler
has abandoned or does not support const correctness is overstating the case
and likely to create further misunderstanding.
I agree that confusion between C++ and C++/CLI is undesirable, but so is
confusion as to what C++/CLI actually is. Personally I feel that the name
conveys this quite well. It doesn't suggest that C++/CLI is a successor to
C++ or "a better C++" but does suggest that it supports C++ and a specific
platform. You could try to convey this accurately in a less succinct name
but then I think the danger of abbreviation would probably be greater.
Andrew
Bob Hairgrove
<clcppm...@this.is.invalid> wrote:
>The main confusion I see at the moment is that many people appear to believe
>that C++/CLI is a variant or subset language with superficial syntactic
>similarities to C++ but which does not support C++ in its entirety. (If this
>were actually the case then I would entirely agree that the name should be
>changed.) As it is, apart from some very minor incompatibilities, code that
>is intended for C++ is also valid C++/CLI code with its meaning preserved.
>All the idioms and features that are supported in C++ are therefore
>supported at least as much in C++/CLI.
Have you read this?
http://www.datanom.net/c++/Objection_to_Fast-track_Ballot_ECMA-372_in_JTC1_N8037.pdf
This was a link posted on comp.lang.c++ in a message in the thread
with the subject: "ECMA-372 is stepping in on C++".
I never touched CLI yet, but if what they say is true, you're quite
mistaken in the sentence ending "with its meaning preserved".
--
Bob Hairgrove
NoSpam...@Home.com
Bo Persson
"Andrew Browne" <clcppm...@this.is.invalid> skrev i meddelandet
news:dFREf.6375$K42....@newsfe7-win.ntli.net...
> "Francis Glassborow" <fra...@robinton.demon.co.uk> wrote in message
> news:b$apxJam1...@robinton.demon.co.uk...
>
>> second language would make it much easier to talk about source code
>> and
>> which 'language' it was intended for. If, for example we called the
>> new
>> language Clipp, we could say that C++ supports const correctness
>> and
>> Clipp does not. But more importantly it would avoid the confusion
>> of
>> using C++ as an abbreviation for C++/CLI.
>
> The main confusion I see at the moment is that many people appear to
> believe
> that C++/CLI is a variant or subset language with superficial
> syntactic
> similarities to C++ but which does not support C++ in its entirety.
Probably the same people who belive that ISO C++ is not the same
language as ISO C, even though it contains most of that language
unchanged.
> (If this
> were actually the case then I would entirely agree that the name
> should be
> changed.) As it is, apart from some very minor incompatibilities,
> code that
> is intended for C++ is also valid C++/CLI code with its meaning
> preserved.
> All the idioms and features that are supported in C++ are therefore
> supported at least as much in C++/CLI.
But if you don't use the new features, why would you want a new
language (or a heavy dose of extensions)?
The C++/CLI compiler can compile most Standard C++ code, just as it
can compile most C code. That doesn't in any way make it all a single
language.
>
> What is, of course, true is that you cannot use some of these idioms
> and
> features in an unconstrained or unchanged way with CLR "managed"
> types. To
> take the example of const correctness, it isn't currently possible
> for a
> member function of a managed type to be qualified with const or
> volatile.
> (Herb Sutter has said in this newsgroup, however, that a future
> revision may
> support this.) I feel, though, that to say that this means that the
> compiler
> has abandoned or does not support const correctness is overstating
> the case
> and likely to create further misunderstanding.
But const correctness is just a small part. There are also different
rules for overloading, name lookup, destruction, etc. Some extension
have more capabilities than the base language, some have actually
fewer, and some are just different. That makes it very hard to talk
about a "pure" extension.
>
> I agree that confusion between C++ and C++/CLI is undesirable, but
> so is
> confusion as to what C++/CLI actually is. Personally I feel that the
> name
> conveys this quite well. It doesn't suggest that C++/CLI is a
> successor to
> C++ or "a better C++" but does suggest that it supports C++ and a
> specific
> platform.
Others have a different opinion:
"You can say that C++/CLI is to C++ as C++ is to C."
(Stan Lippman)
http://msdn.microsoft.com/msdnmag/issues/06/00/PureC/default.aspx
Bo Persson
Andrew Browne
news:44k6c8F...@individual.net...
>
> "Andrew Browne" <clcppm...@this.is.invalid> skrev i meddelandet
> news:dFREf.6375$K42....@newsfe7-win.ntli.net...
>>
>> believe
>> that C++/CLI is a variant or subset language with superficial
>> syntactic
>> similarities to C++ but which does not support C++ in its entirety.
>
> Probably the same people who belive that ISO C++ is not the same
> language as ISO C, even though it contains most of that language
> unchanged.
I am trying to correct a misapprehension that C++/CLI is not a superset of
C++. I am not trying to argue that they are the same language.
> But if you don't use the new features, why would you want a new
> language (or a heavy dose of extensions)?
I would like people to be able to make an informed choice about whether, why
and when they might want to use them.
> The C++/CLI compiler can compile most Standard C++ code, just as it
> can compile most C code. That doesn't in any way make it all a single
> language.
See the first sentence of my reply.
> But const correctness is just a small part. There are also different
> rules for overloading, name lookup, destruction, etc. Some extension
> have more capabilities than the base language, some have actually
> fewer, and some are just different. That makes it very hard to talk
> about a "pure" extension.
That is all true, but I think it is only right that it be made clear that
the differences only apply to the extensions and do not affect the meaning
of C++ code compiled with C++/CLI.
> "You can say that C++/CLI is to C++ as C++ is to C."
In the sense that C++/CLI is an (almost) superset of C++, that statement is
entirely accurate. In other senses I don't think it is really. (For example
C and C++ are highly platform independent and C++/CLI is an extension to
support a specific platform.) I am well aware that there have been some
potentially (and probably unintentionally) misleading statements made in
support of C++/CLI, but there have also been some potentially (and probably
unintentionally) misleading negative statements about it and I think it is
right to try to clear up confusion caused by either.
Andrew
Andrew Browne
news:kbh9u11jd25kq5h52...@4ax.com...
> On 4 Feb 2006 07:03:16 -0500, "Andrew Browne"
> <clcppm...@this.is.invalid> wrote:
>> As it is, apart from some very minor incompatibilities, code that
>>is intended for C++ is also valid C++/CLI code with its meaning preserved.
>
> Have you read this?
> http://www.datanom.net/c++/Objection_to_Fast-track_Ballot_ECMA-372_in_JTC1_N8037.pdf
>
> I never touched CLI yet, but if what they say is true, you're quite
> mistaken in the sentence ending "with its meaning preserved".
Yes I have read it, and I'm afraid I think there are several statements in
it (some of them highlighted in bold) that, taken out of context, serve to
add to the confusion.
For example:-
"C++/CLI changes the meaning of currently valid C++ syntax." This is
followed by two code examples. Example A is currently valid C++ syntax and
its meaning is unchanged in C++/CLI. Example B uses C++/CLI managed types
and is not C++ code.
"C++/CLI changes the behavior of constructor and destructor functions." Only
for managed types, which are not part of C++.
"The semantics of const and volatile are changed." If they are (and I'm not
sure they are really) this also only applies to managed types.
"... the C++/CLI preprocessor is incompatible with the preprocessor for
standard C++." The #using directive is an extension and is not part of C++.
Yes there may be corner case incompatibilities with the parsing of the
two-word keywords but I think this probably falls into the realm of "some
very minor incompatibilities."
The document also makes a potentially misleading analogy with Java which
quite clearly does not support standard C++ code and merely has some
superficial similarities in keywords and syntax. Calling Java "C++/VM"
would not have been a parallel situation.
I don't believe what I said was mistaken, but please do say so (and why) if
you still disagree.
Andrew
Francis Glassborow
<clcppm...@this.is.invalid> writes
>"Bo Persson" <b...@gmb.dk> wrote in message
>news:44k6c8F...@individual.net...
>>
>> "Andrew Browne" <clcppm...@this.is.invalid> skrev i meddelandet
>> news:dFREf.6375$K42....@newsfe7-win.ntli.net...
>>>
>>> The main confusion I see at the moment is that many people appear to
>>> believe
>>> that C++/CLI is a variant or subset language with superficial
>>> syntactic
>>> similarities to C++ but which does not support C++ in its entirety.
>>
>> Probably the same people who belive that ISO C++ is not the same
>> language as ISO C, even though it contains most of that language
>> unchanged.
>
>I am trying to correct a misapprehension that C++/CLI is not a superset of
>C++. I am not trying to argue that they are the same language.
In so far that Microsoft's Visual C++ compiler compiles both C++ and
C++/CLI it might seem that the latter is a superset of C++. However C++
used as C++/CLI code actually behaves differently. IOWs a statement that
can compile as pure C++ may actually compile with different semantics
if, for example, one of the types is a C++/CLI type.
Just because a compiler can compile source code from more than one
language does not make those languages the same one. We already have a
substantial number of programmers who think there is a language called
VC++ or Visual C++ (I suppose by contrast with Basic and Visual Basic
which are definitely distinct languages).
On the one hand MS are intent on persuading us that the Visual Studio
C++ compiler is an excellent and almost (whatever that may mean)
conforming C++ implementation (actually it is now among the best) OTOH
they are making the same implementation compile source code that is only
superficially a form of C++ and confusing punters by calling it C++/CLI.
There are so many differences (many of them actually useful and
generally beneficial in the context of the CLI platform) between
Standard C++ and C++/CLI that the similarity in names (particularly in
view of the habit of many programmers of talking about VC++) is just a
recipe for confusion.
I have heard all the arguments about making C++ a first class CLI
language and the simple answer is that this is smoke and mirrors. The
C++ object model is in conflict with the CLI one and there is no way to
resolve it other than with a new language. Calling it C++/CLI cannot be
motivated by technical issues only by political ones.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Andrew Browne
>
> In so far that Microsoft's Visual C++ compiler compiles both C++ and
> C++/CLI it might seem that the latter is a superset of C++.
I am not saying that C++/CLI is a superset of C++ just because it happens
that a particular compiler can act as both a C++/CLI and a C++ compiler. I
am saying that C++/CLI as it is specified in the ECMA standard is an
(almost) superset of C++ and that valid C++ code is (almost always) valid
C++/CLI code with the same meaning.
> However C++
> used as C++/CLI code actually behaves differently. IOWs a statement that
> can compile as pure C++ may actually compile with different semantics
> if, for example, one of the types is a C++/CLI type.
If one of the types is a C++/CLI type then the code will not compile as C++.
Could you perhaps give some very small example program(s) whose source code
compiles both in C++ and in C++/CLI but with different semantics or
behaviour? Could you give any small example program(s) that will compile in
C++ but will not compile in C++/CLI? (I'm asking for examples that don't
exploit corner cases.)
> On the one hand MS are intent on persuading us that the Visual Studio
> C++ compiler is an excellent and almost (whatever that may mean)
> conforming C++ implementation (actually it is now among the best) OTOH
> they are making the same implementation compile source code that is only
> superficially a form of C++ and confusing punters by calling it C++/CLI.
Playing devil's advocate for a second, ISO C++ permits a conforming
implementation to have extensions provided they do not alter the behaviour
of any well-formed program. To the extent that (I believe) this is very
nearly true of C++/CLI, Microsoft could actually be said to have a case for
just calling it C++. Fortunately they don't do that (at least some of the
time, anyway!)
Andrew
Thant Tessman
> Le Chaud Lapin wrote:
[...]
>>No I don't. That's why it is so important for the experts to
>>be clear in their guidance,
>
>
> But where have the experts mislead? [...] So the marketing droids
> spit out marketing drivel, and the technical people continue to
> do good technical work, and produce reasoned and rational
> technical content. When I want technical information about a
> product, I keep this in mind. [...]
Are you suggesting that an expert would never "sell" whatever it is
they're an expert at? I've certanly seen more than one well-known C++
expert in this forum oversell the virtues of C++. The "experts" are just
as likely as any marketing droid to have an agenda. The only difference
is that their target audience requires a more sophisticated message.
Yes, Microsoft's C++ implementation is (finally!) pretty good, but
Microsoft's history on these matters doesn't make the OP's concerns so
easy to dismiss out of hand. Better to address them directly instead of
derailing the argument with accusations of slander.
My first and distant impression is that C++/CLI is an attempt to provide
a C++ API to Microsoft's CLR. The remarkable thing is that they decided
to do it by *adding* stuff to C++ (or modifiying C++, depending on
who'stalking). The more important question is not whether it should have
"C++" in its name, but: Why do it that way in the first place? Why not
provide a CLR API via a straight-ahead C++ library?
I can imagine three answers:
1) They want to make the task of the C++ CLR developer easier,
2) It was the easiest way for Microsoft to provide the capability,
3) It's part of a larger business strategy of locking developers into
the Microsoft platform.
My guess is that all three are true to one degree or another. The one
answer that I would find totally unbelievable is that Microsoft
developed C++/CLI for the benefit of the C++ developer community as a
whole. Unfortunately, when C++ expert Stanley B. Lippman implies that
C++/CLI is the next evolutionary step in the development of C++, he
clearly doesn't seem concerned over the possibility that someone might
infer exactly that. And knowing what I know about C++, and Microsoft,
and experts, I'd be suspicious of #1 as well until I actually learned it
for myself. Luckily, I don't care about the CLR. I just don't want to
have to revert back to maintaining two sets of my libraries; one written
in C++, and one written in Microsoft C++.
-thant
--
"War is God's way of teaching Americans geograpy." -- Ambrose Bierce
Le Chaud Lapin
[snipped]
> I have heard all the arguments about making C++ a first class CLI
> language and the simple answer is that this is smoke and mirrors.
I heard the same thing a while ago. The very phrase, "first class",
has a somewhat pejorative connotation - it implies that there are other
languages that are superior because they are CLI languages, and C++,
the poor guy, has not caught up, and is second-class, at least in some
respect. It also connotes without substantiation that, in general, it
is desiable that generic languages be made first-class CLI languages.
Perhaps they are right. I think I shall start programming in C++/CLI
so that I am "compliant", and "conformant", and "managed", and
"first-class", and B.C.B.G, and all that other good stuff.
-Le Chaud Lapin-
Francis Glassborow
<clcppm...@this.is.invalid> writes
>"Francis Glassborow" <fra...@robinton.demon.co.uk> wrote in message
>news:B17PjhIl...@robinton.demon.co.uk...
>>
>> In so far that Microsoft's Visual C++ compiler compiles both C++ and
>> C++/CLI it might seem that the latter is a superset of C++.
>
>I am not saying that C++/CLI is a superset of C++ just because it happens
>that a particular compiler can act as both a C++/CLI and a C++ compiler. I
>am saying that C++/CLI as it is specified in the ECMA standard is an
>(almost) superset of C++ and that valid C++ code is (almost always) valid
>C++/CLI code with the same meaning.
Quote from Stan Lippman
C++/CLI is a self-contained, component-based dynamic programming
language that, like C# or Java, is derived from C++.
Note that he unambiguously states that it is a new language. Yet MS
continue to refer to it as C++ in the bodies of much of their
documentation. It is so easy to drop the '/CLI' even though Stan clearly
seems to believe that the name of the language is C++/CLI. If someone as
bright and clear thinking as Stan knows that the languages name is not
just C++ yet people of equal intelligence drop the /CLI the names are
clearly too similar and will get confused.
No one talking about C++ would drop the '++' and refer to it as C. Now
if this new language was called C#++ or ++C# or any of a multitude of
other symbol based names there would never be the temptation to call it
C++. Even C++# would work.
Names matter and bad names cause confusion. New things merit new names
to keep them distinct.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Le Chaud Lapin
> Le Chaud Lapin wrote:
>
> http://www.octopull.demon.co.uk/editorial/OverloadEditorial200601.pdf)
Very nice article! It includes all the salient points about what
Microsoft is doing, plus a lot more!
It seems that even the standards bodies are complaining that Microsoft
is trying to pretend that C++/CLI is an extension of C++ when the
syntax says otherwise.
And since we are on the subject, I still haven't figure out what to do
whenever I see in Visual Studio 2005 the message:
"sprintf as been deprecated....."
Since when did sprintf become deprecated?
-Le Chaud Lapin-
Andrew Browne
> In article <fOrFf.78705$W4.1...@newsfe4-gui.ntli.net>, Andrew Browne
> <clcppm...@this.is.invalid> writes
>>"Francis Glassborow" <fra...@robinton.demon.co.uk> wrote in message
>>news:B17PjhIl...@robinton.demon.co.uk...
>>>
>>> In so far that Microsoft's Visual C++ compiler compiles both C++ and
>>> C++/CLI it might seem that the latter is a superset of C++.
>>
>>I am not saying that C++/CLI is a superset of C++ just because it happens
>>that a particular compiler can act as both a C++/CLI and a C++ compiler. I
>>am saying that C++/CLI as it is specified in the ECMA standard is an
>>(almost) superset of C++ and that valid C++ code is (almost always) valid
>>C++/CLI code with the same meaning.
>
> Quote from Stan Lippman
>
> C++/CLI is a self-contained, component-based dynamic programming
> language that, like C# or Java, is derived from C++.
>
> Note that he unambiguously states that it is a new language.
Once again, I am not trying to argue about whether or not C++/CLI is a "new
language." I am trying to correct the misunderstanding that C++/CLI is not a
superset of C++. Your sentence ending in "it might seem that the latter is a
superset of C++" seems, on face value to suggest that perhaps C++/CLI is not
a superset of C++ and I maintain that this is wrong. This is why I asked you
if you could provide code examples to support the contention that C++/CLI is
not a superset of C++. Let me ask you directly:-
1) Is C++/CLI a superset of C++ in the sense that a well-formed C++ program
is a well-formed C++/CLI program with the same meaning?
2) If your answer to (1) is "no", can you give an example of a well-formed
C++ program that isn't a well-formed C++/CLI program with the same meaning?*
* Yes, there are some minor exceptions. I'm asking for an example that
doesn't exploit those.
This isn't anything to do with the politics of the language name or
whatever. It is an issue of great practical relevance. I have used C++/CLI
to deploy my ISO standard C++ code in a web environment, where the
alternative would seem to be to write significant parts of the application
in several other languages (e.g. JavaScript, HTML, maybe an IDL, maybe some
XML, or maybe another .NET language) with all the impedance mismatch etc
that that would involve. When I include one of my C++ header files in my
C++/CLI program I need to be confident firstly that C++/CLI will compile the
code in that header file, and secondly that when I use the classes and
functions and so on declared in that header file within my C++/CLI code they
will behave exactly as they always have done. Fortunately the C++/CLI
standard gives me that confidence. C++/CLI is a superset of C++, and I am
just trying to get that message across.
Andrew
Hyman Rosen
> 1) They want to make the task of the C++ CLR developer easier,
Yes, that's the one.
> 2) It was the easiest way for Microsoft to provide the capability,
No. They tried it with Managed C++ first, and decided it was a
failure, disadvantaging the C++ CLR developer.
> 3) It's part of a larger business strategy of locking developers into
> the Microsoft platform.
Much of programming for the Microsoft platform deals with working
with the incredibly rich environment that the platform makes available.
For programs like these, portability isn't of much use.
> My guess is that all three are true to one degree or another. The one
> answer that I would find totally unbelievable is that Microsoft
> developed C++/CLI for the benefit of the C++ developer community as a
> whole. Unfortunately, when C++ expert Stanley B. Lippman implies that
> C++/CLI is the next evolutionary step in the development of C++, he
> clearly doesn't seem concerned over the possibility that someone might
> infer exactly that.
People have been very interested in integrating garbage collection
with C++ for a long time now. Inasmuch as C++/CLI appears to have
done this in a very useful and sensible way, it has a good claim
upon being that next evolutionary step.
> Luckily, I don't care about the CLR. I just don't want to
> have to revert back to maintaining two sets of my libraries; one written
> in C++, and one written in Microsoft C++.
In other words, you expect other people to refrain from making
progress in order that your life be made easier. Sorry, but it
doesn't work like that.
kanze
> kanze wrote:
> > Le Chaud Lapin wrote:
> [...]
> >>No I don't. That's why it is so important for the experts to
> >>be clear in their guidance,
> > But where have the experts mislead? [...] So the marketing
> > droids spit out marketing drivel, and the technical people
> > continue to do good technical work, and produce reasoned and
> > rational technical content. When I want technical
> > information about a product, I keep this in mind. [...]
> Are you suggesting that an expert would never "sell" whatever
> it is they're an expert at? I've certanly seen more than one
> well-known C++ expert in this forum oversell the virtues of
> C++.
To some degree, perhaps.
There are certainly dishonest technical experts, but I don't
think that that is the problem here. There is also the very
human tendancy of technical experts to consider their invention
a more important improvement than it is. And let's not forget
that this is a technical forum about the language. IMHO, no
language can ever have the impact a good process will have, but
in this forum, we discuss the language much more than the
process.
On the other hand, the real experts are quite aware that the
language (be it C++ or any other language) isn't a silver
bullet. The "oversell" I've seen from the real experts
(Stroustrup, for example) has been well within the range of
reasonable technical opinion, and not a case of selling C++ for
what it isn't. One may disagree concerning the relative
importance of different features, but it's a far cry from
"marketing" in the sense of what comes out of the marketing
groups of a large company.
> The "experts" are just as likely as any marketing droid to
> have an agenda. The only difference is that their target
> audience requires a more sophisticated message.
I don't think that that is the only difference. To begin with,
they understand what they are selling. And that is a big
difference. For the most part, too, they are honest -- in so
far as the marketing departments don't understand what they are
selling, it is hard to say to what degree their blather is
intentional lies, and to what degree it is just honest
misunderstanding.
> Yes, Microsoft's C++ implementation is (finally!) pretty good,
> but Microsoft's history on these matters doesn't make the OP's
> concerns so easy to dismiss out of hand. Better to address
> them directly instead of derailing the argument with
> accusations of slander.
When he slanders, it will be treated as slander. He directly
implied that any expert supporting CLI was doing so because they
were in some way bought out. That is pure slander.
The issues are complex, and I agree that given their history,
Microsoft (but not only Microsoft) bears watching. On the other
hand, I'm a pragmatist -- I'd like to see an effective C++
standard, and Microsoft seems to want that too, at least at
present. And that's an important positive point. Microsoft has
also hired some very pre-eminent people from the C++ community,
and seems to be paying them largely to continue what they were
doing before; I see no reason in the least to believe that
Microsoft has forced them to change their attitudes, and every
reason to believe that instead, Microsoft hired them to try to
change its attitudes, at least within a certain community --
since Herb Sutter has been employed by Microsoft, Microsoft has
changed more than Herb Sutter has. And I consider that a very
positive sign.
> My first and distant impression is that C++/CLI is an attempt
> to provide a C++ API to Microsoft's CLR. The remarkable thing
> is that they decided to do it by *adding* stuff to C++ (or
> modifiying C++, depending on who's talking). The more
> important question is not whether it should have "C++" in its
> name, but: Why do it that way in the first place? Why not
> provide a CLR API via a straight-ahead C++ library?
> I can imagine three answers:
> 1) They want to make the task of the C++ CLR developer easier,
> 2) It was the easiest way for Microsoft to provide the capability,
> 3) It's part of a larger business strategy of locking developers into
> the Microsoft platform.
Or perhaps simply that there are technical problems concerning
integration with the other languages involved, or in running C++
in a dynamic, mixed language environment. Have you ever tried
Java's interface to C++, JNI? It's not obvious to make several
languages co-habit together.
> My guess is that all three are true to one degree or another.
Plus, no doubt, a number of other reasons, including some that
neither you nor I can even imagine. A large company is a
complex organism, and trying to find a single reason for any
major decision is probably impossible.
> The one answer that I would find totally unbelievable is that
> Microsoft developed C++/CLI for the benefit of the C++
> developer community as a whole.
For what definition of "as a whole". They certainly didn't
develope it for the benefit of embedded programmers. Nor for
those of us working on large scale Unix based servers.
At some level, of course, the motivation of any commercial
enterprise is to make money. Microsoft is no exception. What I
see is that Microsoft seems to have understood that it has
reached the limit just selling wind, and trying to use a strong
arm. I don't doubt that it will still use the strong arm where
it deems it can, but for the moment, it would seem that
Microsoft has decided that the best commercial strategy is some
sort of technical quality, and establishing a dialog, rather
than forcing things down people's throats. At least where
program development environments are concerned.
> Unfortunately, when C++ expert Stanley B. Lippman implies that
> C++/CLI is the next evolutionary step in the development of
> C++, he clearly doesn't seem concerned over the possibility
> that someone might infer exactly that. And knowing what I
> know about C++, and Microsoft, and experts, I'd be suspicious
> of #1 as well until I actually learned it for myself.
> Luckily, I don't care about the CLR. I just don't want to have
> to revert back to maintaining two sets of my libraries; one
> written in C++, and one written in Microsoft C++.
Don't feel bad. I still have to maintain four versions of my
libraries. And that's just for Solaris.
The biggest single problem with C++ today is a lack of
conformity in the compilers. Microsoft used to be one of the
biggest offenders; recently, they seem to want to address the
problem, and even to be addressing it. And the only think I can
regret about their current attitude is that it doesn't affect
me, because their compiler still doesn't target Solaris (nor
Linux).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Francis Glassborow
<a...@standarddeviance.com> writes
>I can imagine three answers:
>
>1) They want to make the task of the C++ CLR developer easier,
>2) It was the easiest way for Microsoft to provide the capability,
>3) It's part of a larger business strategy of locking developers into
>the Microsoft platform.
Or the real answer, the object model for CLR just does not fit with C++.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Francis Glassborow
<clcppm...@this.is.invalid> writes
>> Quote from Stan Lippman
>>
>> C++/CLI is a self-contained, component-based dynamic programming
>> language that, like C# or Java, is derived from C++.
>>
>> Note that he unambiguously states that it is a new language.
>
>Once again, I am not trying to argue about whether or not C++/CLI is a "new
>language." I am trying to correct the misunderstanding that C++/CLI is not a
>superset of C++. Your sentence ending in "it might seem that the latter is a
>superset of C++" seems, on face value to suggest that perhaps C++/CLI is not
>a superset of C++ and I maintain that this is wrong. This is why I asked you
>if you could provide code examples to support the contention that C++/CLI is
>not a superset of C++. Let me ask you directly:-
We are going round in circles.
>
>1) Is C++/CLI a superset of C++ in the sense that a well-formed C++ program
>is a well-formed C++/CLI program with the same meaning?
Today, that is generally the case but my answer would still be no
because there are places where it is not true (as you admit below).
However C++ is currently undergoing a substantial revision. WG21 does
not want to find itself locked into only making changes that are fully
compatible with C++/CLI.
Almost 2 years ago we first encountered such a potential problem in the
proposal to add delegating constructors to C++. There is an issue as to
how code should behave in the event that an exception is raised during a
construction where one constructor has delegated to another. The clearly
correct answer in C++ was vehemently argued against in the ECMA
committee preparing the C++/CLI standard. This was a harbinger of things
to come.
>2) If your answer to (1) is "no", can you give an example of a well-formed
>C++ program that isn't a well-formed C++/CLI program with the same meaning?*
>
>* Yes, there are some minor exceptions. I'm asking for an example that
>doesn't exploit those.
And be your definition anything that is different is minor? Hard to
respond in such circumstances. Let me give an example of why C++ is not
a superset of C:
int i = sizeof('a');
Of course it is only a minor difference (and possibly no difference at
all if the system happens to use the same amount of storage for char and
int) But it is a potential for radically different behaviour depending
on whether you use a C or C++ compiler for the source code.
However, a very important point is that C++ is most definitely NOT a
superset of C99. WG14 and WG21 have worked hard to try and retain a
compatible common subset. Now this is not a problem for most users of C
& C++ (though it is for some because they have to write common code in
that subset) because the languages are different and no one would think
they could just drop the '++' when discussing C++. However MS already
frequently drop the '/CLI' when discussing C++/CLI and expect that when
referring to ISO Standard C++ more than just 'C++' will be
written/spoken.
I have reason to believe that Herb Sutter has moved on from his original
presentation of C++/CLI as just a binding of C++ to the CLI platform. I
hope he has because the object model of C++ just does not work for CLI.
Stan Lippman has clearly moved on.
It is time that MS moved on and gave this new language a proper name of
its own and then marketed it as having the advantage that it provides a
mechanism for using your C++ source code. (Just as C++ promoted itself
as being able to use C source code.)
Whether or not anyone wishes to consider the current release of C++/CLI
to be a superset of the current version of C++ is immaterial. C++
already carries a big enough burden in trying to ensure that a common
core with C is maintained. If we are to further burden it with being a
sub-set of C++/CLI we might as well all pack up our bags and go away.
For a long time I believed that it would be possible to produce C++/CLI
as effectively a binding + pure extensions to C++. However I have now
come to understand the issues clearly enough to realise that this is
simply not achievable. Note that I have absolutely no problem with the
idea of a CLI language with facilities to use C++ source code. I think
the technical experts involved have done an excellent job with C++/CLI
(for the record, IMO, a much better job than Java) but the result is
NOT an extended C++ and so should not include C++ in its name (certainly
not in a form that encourages people to drop part of the name.)
Had the BSI Panel for C++ realised the full implications earlier we
would have been far more demanding of a name change from ECMA (though I
have reason to believe that MS was strongly wedded to the inclusion of
C++ in the name).
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Hyman Rosen
> I heard the same thing a while ago. The very phrase, "first class",
> has a somewhat pejorative connotation - it implies that there are other
> languages that are superior because they are CLI languages, and C++,
> the poor guy, has not caught up, and is second-class, at least in some
> respect.
Well, that's perfectly true. CLI languages live in a garbage-collected
world, and bare pointers and pointers to insides of objects are not
compatible with such a world. At least, severe compromises are needed
to meld the two. C++/CLI sidesteps this by extending C++ to have new
kinds of pointers which conform much better to the GC model. Inasmuch
as programmers for the CLR expect their languages to deal properly with
GC and to the extent that C++ does not, C++ is a second-class language
in that world.
> It also connotes without substantiation that, in general, it
> is desiable that generic languages be made first-class CLI languages.
It is desirable for Microsoft, who are therefore doing the work to
make it happen. It's your choice not to participate. It's not your
choice to prevent others from doing so.
Hyman Rosen
> Since when did sprintf become deprecated?
Since the time it started being used as an attack vector
for viruses.
P.J. Plauger
news:1139284344.8...@z14g2000cwz.googlegroups.com...
> Alan Griffiths wrote:
>> Le Chaud Lapin wrote:
>>
>> (More about this here:
>> http://www.octopull.demon.co.uk/editorial/OverloadEditorial200601.pdf)
>
> Very nice article! It includes all the salient points about what
> Microsoft is doing, plus a lot more!
>
> It seems that even the standards bodies are complaining that Microsoft
> is trying to pretend that C++/CLI is an extension of C++ when the
> syntax says otherwise.
Well, no. What has happened is a little less formal, and profound,
than that. C++/CLI is a formal ECMA standard. It has been submitted
to ISO using the "fast track" machinery, which is available to
standards bodies that follow procedures approved by ISO. None of the
"standards bodies" within ISO have been called on to express an
opinion yet, complaint or otherwise. My understanding is that two
*national bodies* raised issues during the initial 30-day comment
period:
1) DIN in Germany suggested that SC22 start a New Work Item on
C++/CLI, thus giving ISO five years or so to tinker with C++/CLI.
2) BSI in the UK suggested that the name should be changed, to
avoid any possible confusion with Standard C++.
My understanding is that neither of these comments is enough to
derail the progress of C++/CLI within ISO, which is still subject
to at least one formal vote by the participating national bodies.
It is worth observing that Herb Sutter has taken extraordinary
pains to keep WG21 informed of what's been going on within ECMA
TC39/TG5, including the plan to seek fast-track approval. Members
of WG21, including technical experts from BSI, have attended
meetings of TG5 over the past couple of years. TG5 has solicited,
and heeded, the advice of WG21 on how to avoid preempting
certain design decisions still up in the air with the revision
of Standard C++. *All* papers, and working drafts, of C++/CLI have
been made promptly available to WG21. There are no surprises here.
BSI has/have been building a reputation over the past decade or
so for voting against all sorts of documents, sometimes directly
contradicting the assurances made by technical experts they send
to standards meetings. Maybe they're right this time, and maybe
they'll sway enough votes to change things. But I've learned to
wait and see.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Andrew Browne
> In article <qRRFf.80815$W4.6...@newsfe4-gui.ntli.net>, Andrew Browne
> <clcppm...@this.is.invalid> writes
>>1) Is C++/CLI a superset of C++ in the sense that a well-formed C++
>>program
>>is a well-formed C++/CLI program with the same meaning?
>
> Today, that is generally the case but my answer would still be no
> because there are places where it is not true (as you admit below).
>
>>2) If your answer to (1) is "no", can you give an example of a well-formed
>>C++ program that isn't a well-formed C++/CLI program with the same
>>meaning?*
>>
>>* Yes, there are some minor exceptions. I'm asking for an example that
>>doesn't exploit those.
>
> And be your definition anything that is different is minor? Hard to
> respond in such circumstances. Let me give an example of why C++ is not
> a superset of C:
>
> int i = sizeof('a');
>
> Of course it is only a minor difference (and possibly no difference at
> all if the system happens to use the same amount of storage for char and
> int)
Purely in the interests of accuracy, I don't think there is ever going to be
no difference at all is there? Surely sizeof('a') is always going to be 1 in
C++ and is never going to be 1 in C?
There are, of course, larger reasons why C++ is not a superset of C. For
example C++ has something like 40+ reserved words that are not C89 reserved
words. A C89 program that uses any of these reserved words as identifiers is
an invalid C++ program. The sort of thing I mean when I talk about the
incompatibilities between C++/CLI and C++ only being minor is that there are
(I believe) only three new reserved words in C++/CLI that would break a C++
program in the same way. That was actually the most significant possible
counter-example that I was thinking of.
Anyway, I'm glad that (I think) we broadly agree that C++/CLI compiles
current C++ code and preserves its behaviour, as I felt it was important to
clarify this factual point, whatever one feels its significance to the wider
debate may be.
Andrew
Le Chaud Lapin
> Le Chaud Lapin wrote:
> > Since when did sprintf become deprecated?
>
> Since the time it started being used as an attack vector
> for viruses.
What would you recommend for writing portable C/C++ code that uses
sprintf?
-Le Chaud Lapin-
Bo Persson
"Hyman Rosen" <hyr...@mail.com> skrev i meddelandet
news:200602062326....@mailbox7.ucsd.edu...
> Thant Tessman wrote:
>
>> Luckily, I don't care about the CLR. I just don't want to
>> have to revert back to maintaining two sets of my libraries; one
>> written
>> in C++, and one written in Microsoft C++.
>
> In other words, you expect other people to refrain from making
> progress in order that your life be made easier. Sorry, but it
> doesn't work like that.
The protests are more against the statement that this is a great
improvement, but still no different than before. If it is so much
better, why insist that it should have almost the same name?
Bo Persson
Thant Tessman
[...]
> People have been very interested in integrating garbage collection
> with C++ for a long time now. Inasmuch as C++/CLI appears to have
> done this in a very useful and sensible way, it has a good claim
> upon being that next evolutionary step.
There have been many very good programming languages with garbage
collection designed in right from the start. (No, I'm not talking about
Java.) Consequently, some would describe the integration of C++ and
garbage collection not as evolution, but as a particularly awkward and
unnecessary hack.
>> Luckily, I don't care about the CLR. I just don't want to
>>have to revert back to maintaining two sets of my libraries; one written
>>in C++, and one written in Microsoft C++.
>
>
> In other words, you expect other people to refrain from making
> progress in order that your life be made easier. Sorry, but it
> doesn't work like that.
The objection is not with progress. The objection is with the
possibility that an industry standard is being hijacked for the benefit
of a single corporation (with a history of this kind of thing) and that
it's being called "progress."
Of course Microsoft can do whatever they want with their C++
implementation. Just don't pretend they're doing the rest of us a favor.
-thant
--
"Now, the temptation is going to be, by well-meaning people such as
yourself and others here, as we run up to the issue, to get me to
negotiate with myself in public." -- George W. Bush, December 20, 2004
Andrew Browne
news:5D3Gf.82795$W4.7...@newsfe4-gui.ntli.net...
> "Francis Glassborow" <fra...@robinton.demon.co.uk> wrote in message
> news:UIoaclRk...@robinton.demon.co.uk...
>> Let me give an example of why C++ is not
>> a superset of C:
>>
>> int i = sizeof('a');
>>
>> Of course it is only a minor difference (and possibly no difference at
>> all if the system happens to use the same amount of storage for char and
>> int)
>
> Purely in the interests of accuracy, I don't think there is ever going to
> be
> no difference at all is there? Surely sizeof('a') is always going to be 1
> in
> C++ and is never going to be 1 in C?
I expect someone else may correct me on this as well, but I was, of course,
wrong on the latter point. I don't know what I was thinking!
Sorry.
Hyman Rosen
> What would you recommend for writing portable C/C++ code that uses
> sprintf?
Portable C code should use snprintf (7.19.6.5).
Portable C++ code should use ostrstream (D.7.3.1/2).
Hyman Rosen
> The protests are more against the statement that this is a great
> improvement, but still no different than before. If it is so much
> better, why insist that it should have almost the same name?
It is better for people who want the new features,
and the same for those who don't. The name indicates
both the continuity and the difference.
C++/CLI inherits multiply from C++ and C# and therefore is-a
instance of both. It's a floor wax and a dessert topping.
wka...@yahoo.com
Le Chaud Lapin wrote:
...
> marketing. I find it even more disturbing that so many programmers
> succumb to it. C++ did not "evolve" to CLI. What acutally happened is
> that Microsoft believed in some non-sense that it is possible to create
> objects that can be wielded from any language while pretty much keeping
> the language unchanged. Of course, this did not work (COM), and when
> it (barely) did, it was too ugly to bear (even with special keywords
> and compilers). So they created C#, and also CLI. ...
I think we should not waste our time complaining that Microsoft acts
like what it is: a private for-profit corporation. Relatively
speaking,
MS is fairly cautious about doing things that will seriously piss off
large numbers of PC users and/or SW developers.
I don't get that upset that MS provides alternative proprietary
languages
or a proprietary dialect of C++. The worrisome thing is that .NET is
(among other things) a new (virtual) machine architecture that appears
to be incapable of supporting ISO C++. It seems more likely than not
that the 386-based Windows API will eventually fail behind,
feature-wise, the Windows .NET API. Eventually, it may not be
feasable to write a competitive application in ISO C++ that's
targeted to Windows. Even if this is grounds for an anti-trust
lawsuit, who would sue? ISO? GNU? Borland? Class-action?
Paul Floyd
> Thant Tessman wrote:
[OT, but brief]
>> concerns so easy to dismiss out of hand. Better to address
>> them directly instead of derailing the argument with
>> accusations of slander.
>
> When he slanders, it will be treated as slander. He directly
> implied that any expert supporting CLI was doing so because they
> were in some way bought out. That is pure slander.
Please. Libel, not slander. Libel is written defamation. Slander is
spoken defamation. I'm not defending the OP, but he did seem to be
expressing an opinion, which would be neither.
A bientot
Paul
--
Paul Floyd http://paulf.free.fr (for what it's worth)
Surgery: ennobled Gerald.
Timo Geusch
> Hyman Rosen wrote:
> > Le Chaud Lapin wrote:
> > > Since when did sprintf become deprecated?
> >
> > Since the time it started being used as an attack vector
> > for viruses.
>
> What would you recommend for writing portable C/C++ code that uses
> sprintf?
Either stringstreams or at least the length-limited versions of sprintf
like snprintf that are available on most platforms these days.
Greg Herlihy
Le Chaud Lapin wrote:
> Hyman Rosen wrote:
> > Le Chaud Lapin wrote:
> > > Since when did sprintf become deprecated?
> >
> > Since the time it started being used as an attack vector
> > for viruses.
>
> What would you recommend for writing portable C/C++ code that uses
> sprintf?
snprintf
Greg
P.J. Plauger
> "Andrew Browne" <clcppm...@this.is.invalid> wrote in message
> news:5D3Gf.82795$W4.7...@newsfe4-gui.ntli.net...
>> "Francis Glassborow" <fra...@robinton.demon.co.uk> wrote in message
>> news:UIoaclRk...@robinton.demon.co.uk...
>
>>> Let me give an example of why C++ is not
>>> a superset of C:
>>>
>>> int i = sizeof('a');
>>>
>>> Of course it is only a minor difference (and possibly no difference at
>>> all if the system happens to use the same amount of storage for char and
>>> int)
>>
>> Purely in the interests of accuracy, I don't think there is ever going to
>> be
>> no difference at all is there? Surely sizeof('a') is always going to be 1
>> in
>> C++ and is never going to be 1 in C?
>
> I expect someone else may correct me on this as well, but I was, of
> course,
> wrong on the latter point. I don't know what I was thinking!
This is wandering a bit off topic, but I'm getting a bit tired of
seeing this shibboleth bandied so widely. The C committee discussed
the sizeof 'a' at some length. We determined that it is an rvalue
in a language where rvalues are always subject to type promotion
(widening to int, say) before any other semantics kick in. So, for
completeness and consistency, we ruled that sizeof ('a') shoud be
the same as sizeof (int). Not that it ever amounts to a hill of
beans. C++, OTOH, has contexts where type promotion a la C doesn't
occur. Moreover, it has overloading, template selection, and rvalue
binding contexts where it really helps to treat 'a' as an rvalue of
type char. Thus the result that in C++ sizeof('a') is 1.
If there's a program in the common subset of C and C++ where this
matters, I don't know it. AFAICS, it's in the same league as
howling that C is not a proper subset of C++ because it lets you
use "template" as an identifier. (Closer on topic, I'm suprised
that nobody has howled loudly about "gcnew". So far.)
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
kanze
> On 7 Feb 2006 06:42:58 -0500, kanze <ka...@gabi-soft.fr> wrote:
> > Thant Tessman wrote:
> [OT, but brief]
> >> concerns so easy to dismiss out of hand. Better to address
> >> them directly instead of derailing the argument with
> >> accusations of slander.
> > When he slanders, it will be treated as slander. He
> > directly implied that any expert supporting CLI was doing so
> > because they were in some way bought out. That is pure
> > slander.
> Please. Libel, not slander. Libel is written defamation.
> Slander is spoken defamation. I'm not defending the OP, but he
> did seem to be expressing an opinion, which would be neither.
The exact statement was: "What I have yet to figure out is what
Goliath is giving David to make him promulgate the
preposterous." My understanding of English is that that
statement implies very strongly that the Davids in question (in
previous statements he named Stan Lippman, Herb Sutter and P. J.
Plauger explicitly) as having been bribed to make untrue
statements. And that is slander: "a false and malicious
statement or report about someone" (to quote the definition in
the "American Heritage Dictionary").
The entire tone of the posting in question was one of anger and
"ennervement" -- an emotional context where people do make
statements which they don't really mean. And the poster has
since posted an appology for any personal intuendo; I presume
that while he still doesn't like C++/CLI, he accepts that the
technical experts behind it have a different technical opinion,
and have not just been "bought off". And that's really all I
was asking for; I don't really care one way or another with
regards to C++/CLI. Even the name issue leaves me somewhat
indifferent -- I've been fighting the problem for 15 years with
people writing C and calling it C++, so I guess I can cope with
people writing C++/CLI and calling it C++ as well. (For that
matter, there are compilers which claim to be C++ compilers, but
don't implement the language described by the standard --
several of them omit export, for example. What's the difference
between calling C++/CLI C++, and calling a compiler which
doesn't implement export C++?)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
> "Le Chaud Lapin" <unorigina...@yahoo.com> writes:
> > kanze wrote:
> >> Le Chaud Lapin wrote:
> >> > David Abrahams wrote:
> >> Do you really expect to take all marketing claims at their face
> >> value?
> No, I did *not* write that. Please watch your attributions to
> make sure they're accurate.
Just some careless cutting on the poster's part somewhere along
the line (possibly in my respone). The '>' indenting makes it
clear that I was the one who write that. Since the attribution
line with your name starts with four '>', anything you wrote
must start with five '>'. Since you're not being quoted, the
attribution line should really have been cut, but I know that I
often will start cutting after all attributions, not having
finally decided whether I will keep parts of a given attribution
or not.
It would be well if people did pay attention to the citation
indentation when determining who said what. It would be even
better if there were only technical comments, so it really
wouldn't matter who said what.
Bob Hairgrove
>Le Chaud Lapin wrote:
>> What would you recommend for writing portable C/C++ code that uses
>> sprintf?
>
>Portable C code should use snprintf (7.19.6.5).
>Portable C++ code should use ostrstream (D.7.3.1/2).
ostrstream or ostringstream?
--
Bob Hairgrove
NoSpam...@Home.com
Hyman Rosen
> Eventually, it may not be feasable to write a competitive
> application in ISO C++ that's targeted to Windows.
That statement is most likely already true for a large
number of programming languages. A platform developer
has no responsibility for maintaining the competitiveness
of programming languages.
Francis Glassborow
kanze <ka...@gabi-soft.fr> writes
>What's the difference
>between calling C++/CLI C++, and calling a compiler which
>doesn't implement export C++?)
Quite a lot. One falls short by failing to provide a specified facility
the other will compile without diagnostics a very great deal of source
code that is not only not C++ but that is incompatible with the C++
object model.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Hyman Rosen
> There have been many very good programming languages with garbage
> collection designed in right from the start.
True, but irrelevant for people who want to use C++
(or a C++-like language).
> Consequently, some would describe the integration of C++ and
> garbage collection not as evolution, but as a particularly awkward and
> unnecessary hack.
And those people can choose not to use the integrated version.
But they can't stop other people from using it.
> The objection is not with progress. The objection is with the
> possibility that an industry standard is being hijacked for the benefit
> of a single corporation (with a history of this kind of thing) and that
> it's being called "progress."
As far as I know, Microsoft gets one vote on the C++ committee,
the same as any other company. If they are "hijacking" the
standard, they are doing it by doing useful work which is being
appreciated by others.
P.J. Plauger
> In article <1139405175.6...@g14g2000cwa.googlegroups.com>,
> kanze <ka...@gabi-soft.fr> writes
>>What's the difference
>>between calling C++/CLI C++, and calling a compiler which
>>doesn't implement export C++?)
>
> Quite a lot. One falls short by failing to provide a specified facility
> the other will compile without diagnostics a very great deal of source
> code that is not only not C++ but that is incompatible with the C++
> object model.
You mean things like:
__extension__ extern long long int atoll (__const char *__nptr)
__THROW __attribute_pure__;
(from glibc on PC Linux -- some of those things might be macros,
but this ain't C++ with the long long and it ain't C with any
kind of throw specification)
or:
_CRTIMP2 new_handler __cdecl set_new_handler(new_handler)
_THROW0(); // establish alternate new handler
(from VC++ V8 -- _THROW0 is indeed a macro, but _CRTIMP2 and
__cdecl are language extensions that have been around for years)
Or thread local storage, which does violence to the C++ data
model, yet is implemented in some form on every multithreaded
system I know.
Sorry, but I've yet to see the bright line that puts purported
Standard C++ implementations on one side and C++/CLI on the
other. Unless, of course, you're willing to admit that C++
should no longer corrupt the name C and end the long standing
C/C++ confusion as well.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Linønut
> My first and distant impression is that C++/CLI is an attempt to provide
> a C++ API to Microsoft's CLR. The remarkable thing is that they decided
> to do it by *adding* stuff to C++ (or modifiying C++, depending on
> who'stalking). The more important question is not whether it should have
> "C++" in its name, but: Why do it that way in the first place? Why not
> provide a CLR API via a straight-ahead C++ library?
Borland went the C++ extensions route with the first version of OWL, and
again with C++ Builder. Look what happened to them. But they're not
Microsoft.
Microsoft can do what they want to. They own the platform. If even a
small percentage of people buy in to a Microsoft techonology de jeur,
there's automatic traction.
Ever since I read what Jim McCarthy said in his book, "Dynamics of
Software Developement", I've preferred to avoid Microsoft programming
technologies. Too much deliberate churn. Unfortunately, I'm also
(primarily) a Windows programmer.
--
Q: Why does a GNU/Linux user compile his kernel?
A: Because he can.
Hyman Rosen
> ostrstream or ostringstream?
The deprecated one. That's the one that lets you designate
a buffer for use by the stream, and after formatting is
done, that buffer contains the formatted output.
kevin...@motioneng.com
Evidently so.
People are now also using OSX instead of OS9.
We're now on Linux kernel 2.6. A few years ago we had Linux kernel
2.4. And a few years before that, it was kernel 2.2, etc.... NOTE:
The 2.6 kernel is very different from 2.4 -- new way to write device
drivers, a new thread library, among other things.
We can also discuss RTX, VxWorks, uItron, QNX and the likes if you
really wish, but they have all evolved too.
Honestly, all OS families introduce new OSes every few years.
Le Chaud Lapin
> The exact statement was: "What I have yet to figure out is what
> Goliath is giving David to make him promulgate the
> preposterous." My understanding of English is that that
> statement implies very strongly that the Davids in question (in
> previous statements he named Stan Lippman, Herb Sutter and P. J.
> Plauger explicitly) as having been bribed to make untrue
> statements. And that is slander: "a false and malicious
> statement or report about someone" (to quote the definition in
> the "American Heritage Dictionary").
Bribed no. What I was implying, and which I will no longer imply
anymore, but state explicitly now:
1. Microsoft is engaged in a campaign to [insert whatever term you
prefer here] the primary tool that we use to do our jobs. For example,
only the very naive would read a column entitled "Pure C++" that
contains code that is obviously not pure C++ and not wonder why a
large, influential company insists on calling the column Pure C++.
2. Several experts seem to be unabashedly supporting this process.
3. Junior C++ coders often look to these same experts for advice on
C++.
4. If there is potential for subversion of C++ as we now know it due
to C++/CLI, it might be a good idea for the experts to clearly state
their positions now. Why? See #3.
> The entire tone of the posting in question was one of anger and
> "ennervement" -- an emotional context where people do make
> statements which they don't really mean. And the poster has
> since posted an appology for any personal intuendo; I presume
> that while he still doesn't like C++/CLI, he accepts that the
> technical experts behind it have a different technical opinion,
> and have not just been "bought off".
Actually, I do not really know the technical opinions of the experts.
In fact, that is what I was complaining about originally. Did I think
that Microsoft pulled [insert name of expert] aside and said, "Hey,
here's $350,000.00US help you be more open-minded about the
interpretation of the phrase 'Pure C++'" No. But let's face it. We
are all human. Perhaps there was resistance early on that waned after
time and familiarity.
So my statements are more like a stick to say, "Hey, is is this what
you really want? Because if it's what you want, by default, it's what
5000 other programmers want."
But, if those experts say, "Yes, I see what you mean about the
suggestive marketing, and yes, I see what you are saying about calling
it Pure C++ when there is a foreign syntax all over the page that many
skilled C++ programmers have never seen, and yes, I see that they are
trying to standardize their add-on through a somewhat serendipitous
path, and yes, I am aware of what will probably happen to "pure" (take
note of the lower-case) C++ if Microsoft gets its way, but in spite of
all this, I still support what they are doing."
...I would readily accept their position.
-Le Chaud Lapin-
Le Chaud Lapin
> You mean things like:
> __extension__ extern long long int atoll (__const char *__nptr)
> __THROW __attribute_pure__;
>
> Standard C++ implementations on one side and C++/CLI on the
> other. Unless, of course, you're willing to admit that C++
> should no longer corrupt the name C and end the long standing
> C/C++ confusion as well.
To find the bright line, may I suggest we apply the 19-Year-Old test:
First let us apply the test to the example above. Would a 19-year-old
write that type of code during a typical coding session? Probably not.
Perhaps he might recognize the extra keywords as proprietary
extensions, but say, "That's not really C++, those are extensions to be
used in a specific situation. The code is not even portable."
Now let us apply the 19-Year-Old test to code extracted directly from
the MSDN "Pure C++" column:
http://msdn.microsoft.com/msdnmag/issues/06/00/PureC/default.aspx
First we note that this article is an introduction to C++/CLI. We know
this because there is a section in it entitled, "What is C++/CLI?"
Assuming that this article is an introduction to C++/CLI, one could
conclude that example code provided is indeed something that one would
encounter in a typical coding session:
class native {};
value class V {};
ref class R {};
interface class I {};
Now we ask, "Is this C++, C++/CLI, or both?"
Well it is not C++. No C++ compiler will compile it. It cannot be
both. No C++ compiler will compile it. It must be C++/CLI. But is it
a mere extension of C++? No. If it were, then it would necessarily be
"defective" in someway, mostly notably, non-portable. Certainly
rarely-used extensions would not be in an introductory article, at
least not so close to the beginning.
The point is that that code *is* the regular code. Anyone who uses
C++/CLI is guaranteed be using those constructs. Unlike the example
you gave, it is not possible to write portable C++/CLI code without
using the "extensions" to C++ that C++/CLI proposes.
So in summary, who knows what it is, but it's not just C++ with
extensions. If it were, then any so-called "portable" code written in
it should be compilable by any conformant C++ compiler.
-Le Chaud Lapin-
Francis Glassborow
<p...@dinkumware.com> writes
>Sorry, but I've yet to see the bright line that puts purported
>Standard C++ implementations on one side and C++/CLI on the
>other. Unless, of course, you're willing to admit that C++
>should no longer corrupt the name C and end the long standing
>C/C++ confusion as well.
There is a very simple one, they are just extensions and while some
extensions are more acceptable than others (and I seem to recall that
those responsible for gcc have been pulling back from many of their
earlier extensions). What places C++/CLI (IMO) into an entirely
different domain is the attempt to have ISO make it a standard. Change
the name to one that is not prone to abbreviation to 'C++' and I have no
problem with it and treating it as a new and distinct member of the C
family of languages (and I even think a pretty good one).
How do you think the world would react if those responsible for Symbian
C++ went to ECMA and sought a standard for C++/Symbian and then tried to
fast track it to an ISO C++/Symbian standard? Or perhaps that those
responsible for g++ sought (by the same route) a standard called
C++/GNU?
There should be one C++ Standard that is periodically reviewed. I could
even, just about, live with a TR to cover extensions to C++ for use with
a platform (in this case CLI).
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Francis Glassborow
Chaud Lapin <unorigina...@yahoo.com> writes
>class native {};
>value class V {};
>ref class R {};
>interface class I {};
>
>Now we ask, "Is this C++, C++/CLI, or both?"
>
>Well it is not C++. No C++ compiler will compile it. It cannot be
>both. No C++ compiler will compile it.
Sorry, but I disagree. Any C++ compiler that also compiles C++/CLI will
compile it. In that sense it is exactly like any other case of
extensions. The only requirement is that in conforming mode the compiler
issue a diagnostic which could be:
'Nice to see you using the CLI extensions.'
Extensions are almost by definition 'non-portable'. And while the
C++/CLI extensions are targeted at supporting code for a specific
platform I suspect that someone with enough determination could write a
compiler that compiled C++/CLI for another platform of their choice.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
P.J. Plauger
news:1139439826....@o13g2000cwo.googlegroups.com...
> kanze wrote:
>> The exact statement was: "What I have yet to figure out is what
>> Goliath is giving David to make him promulgate the
>> preposterous." My understanding of English is that that
>> statement implies very strongly that the Davids in question (in
>> previous statements he named Stan Lippman, Herb Sutter and P. J.
>> Plauger explicitly) as having been bribed to make untrue
>> statements. And that is slander: "a false and malicious
>> statement or report about someone" (to quote the definition in
>> the "American Heritage Dictionary").
>
> Bribed no. What I was implying, and which I will no longer imply
> anymore, but state explicitly now:
>
> 1. Microsoft is engaged in a campaign to [insert whatever term you
> prefer here] the primary tool that we use to do our jobs. For example,
> only the very naive would read a column entitled "Pure C++" that
> contains code that is obviously not pure C++ and not wonder why a
> large, influential company insists on calling the column Pure C++.
You can say *exactly* the same thing about what WG21 is currently
doing, under the guidance of Bjarne Stroustrup. C++0X is destined
to look quite different from current Standard C++ in many important
ways; and the committee will certainly want to call it Standard C++.
So who has the franchise on evolving new ideas in programming
languages? And whatever happened to the (successful and prudent)
practice of having standards committees codify existing practice?
> 2. Several experts seem to be unabashedly supporting this process.
I unabashedly support the process. I've always reserved the right
to criticize some of the results. (And I do.)
> 3. Junior C++ coders often look to these same experts for advice on
> C++.
Not as much as you think, but so what if they do? They also
buy books "for Dummies" at Barnes & Noble. Who has the greater
moral obligation, the putative experts or the folks who emit
books (for a profit) with the same shelf life as orange juice
and beer?
> 4. If there is potential for subversion of C++ as we now know it due
> to C++/CLI, it might be a good idea for the experts to clearly state
> their positions now. Why? See #3.
Okay, and what if some expert says his goal is to destroy
Western civilization as we know it? What does that say about
the technical merits of C++/CLI?
>> The entire tone of the posting in question was one of anger and
>> "ennervement" -- an emotional context where people do make
>> statements which they don't really mean. And the poster has
>> since posted an appology for any personal intuendo; I presume
>> that while he still doesn't like C++/CLI, he accepts that the
>> technical experts behind it have a different technical opinion,
>> and have not just been "bought off".
>
> Actually, I do not really know the technical opinions of the experts.
You should know mine. I posted a rather detailed exposition of it,
in response to your request, with a bit of follow up. Be nice if
you noticed that.
> In fact, that is what I was complaining about originally. Did I think
> that Microsoft pulled [insert name of expert] aside and said, "Hey,
> here's $350,000.00US help you be more open-minded about the
> interpretation of the phrase 'Pure C++'" No. But let's face it. We
> are all human. Perhaps there was resistance early on that waned after
> time and familiarity.
Some of us humans also pride ourseves in clinging to a form of
intellectual integrity. You might have considered that possibility
as well in your tirade.
> So my statements are more like a stick to say, "Hey, is is this what
> you really want? Because if it's what you want, by default, it's what
> 5000 other programmers want."
No it isn't, dammit. We *swim* in a marketplace of ideas these days.
Microsoft, experts, and impressionable programmers are all entities
way more complex -- and more buffeted by that marketplace -- than your
simplistic portrayal indicates. And none of this reflects much at
all on the technical merits of C++/CLI, or Standard C++ for that
matter, both of which are more apt topics for this newsgroup.
> But, if those experts say, "Yes, I see what you mean about the
> suggestive marketing, and yes, I see what you are saying about calling
> it Pure C++ when there is a foreign syntax all over the page that many
> skilled C++ programmers have never seen, and yes, I see that they are
> trying to standardize their add-on through a somewhat serendipitous
> path, and yes, I am aware of what will probably happen to "pure" (take
> note of the lower-case) C++ if Microsoft gets its way, but in spite of
> all this, I still support what they are doing."
>
> ...I would readily accept their position.
That's close enough to the words I'd use. So I assume you will now
accept my position. Preferably not as a sellout, but if you think
that, it's your problem.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
P.J. Plauger
> P.J. Plauger wrote:
>> You mean things like:
>> __extension__ extern long long int atoll (__const char *__nptr)
>> __THROW __attribute_pure__;
>>
>> Sorry, but I've yet to see the bright line that puts purported
>> Standard C++ implementations on one side and C++/CLI on the
>> other. Unless, of course, you're willing to admit that C++
>> should no longer corrupt the name C and end the long standing
>> C/C++ confusion as well.
>
> To find the bright line, may I suggest we apply the 19-Year-Old test:
>
> First let us apply the test to the example above. Would a 19-year-old
> write that type of code during a typical coding session? Probably not.
> Perhaps he might recognize the extra keywords as proprietary
> extensions, but say, "That's not really C++, those are extensions to be
> used in a specific situation. The code is not even portable."
You're quoting out of context. What you snipped was the dialog
I was responding to:
: "Francis Glassborow" <fra...@robinton.demon.co.uk> wrote in message
: news:hkyX3vLM...@robinton.demon.co.uk...
:
: > In article <1139405175.6...@g14g2000cwa.googlegroups.com>,
: > kanze <ka...@gabi-soft.fr> writes
: >>What's the difference
: >>between calling C++/CLI C++, and calling a compiler which
: >>doesn't implement export C++?)
: >
: > Quite a lot. One falls short by failing to provide a specified facility
: > the other will compile without diagnostics a very great deal of source
: > code that is not only not C++ but that is incompatible with the C++
: > object model.
This thread keeps skipping among several issues, and only James
Kanze seems to be able to tease them apart with any regularity.
-- Sometimes C++/CLI is criticized for not being exactly Standard
C++. Kanze's point above is that *every* implementation that
calls itself Standard C++ (with the notable exception of those
that use the EDG front end and Dinkumware C and C++ libraries)
does too. And yet the notion of what constitutes Standard C++
survives.
-- Sometimes C++/CLI is criticized for deviating from the purity
of Standard C++ by adding strange new syntax and semantics
(Glassborow's point above). My point in response is that *every*
implementation that calls itself Standard C++ does too. And
yet the notion of what's "portable" Standard C++ survives.
-- Sometimes C++/CLI is criticized for pushing the language in
boldly different directions from Standard C++. Well, that's
what Standard C++ did to traditional C++. Compare ISO/IEC
14882:2003 to the Annotated Reference Manual. And that's what
WG21 is now doing to Standard C++ with C++0X. It's called
exploration, and sometimes progress. And it's *necessary*
to ensure that something meaningfully called Standard C++
survives in the long run.
-- Sometimes C++/CLI is criticized as a possible source of
confusion about what constitutes "true" C++. Well, that's
what Standard C++ has done to Standard C. Despite Glassborow's
easy dismissal, this is an ongoing problem; all you have to
do is read comp.lang.c for a week or two to see that. And
yet Standard C survives. So too will Standard C++ in the
presence of Standard C++/CLI.
We can spend weeks more shuffling between sizeof ('a'), which
only a language lawyer can get exercised over, and how a
19-year-old sees a programming language. We can question the
motives of Microsoft, based on their past performance or our
current state of indigestion. We can postulate scenarios of
doom if the broad tent called C++ gets any broader. But we
shouldn't lose sight of the basic facts:
-- C++/CLI is a major product just released by Microsoft that
includes one of the most conforming C++ compilers you can
buy today.
-- The language it implements is now a formal standard
developed under the aegis of ECMA and submitted to ISO
for fast-track approval. That's a well documented process
that has been used by other stndards and announced well
in advance by Microsoft.
-- It also includes technology that many people in the
standards community have been exploring as useful additions
to Standard C++.
-- The added technology takes the form of a remarkably coherent
dialect that blends quite well with Standard C++. (That's my
opinion, based on a couple of years of developing a nontrivial
commercial product, but others have reported similar findings.)
-- Anything you can say about the confusion between C++ and
C++/CLI you can also say about C and C++.
-- Getting back to the title of this thread, marketing is
*supposed* to be suggestive. It's up to us consumers to
weigh the merits of loud and conflicting suggestions.
Discussions like these tend to be endless because they purport
to be about technical issues but they're really about The
Eternal Battle for Men's (and, at long last, Women's) Minds.
What's "fair" tends to be what your side does, and what's
"dirty pool" what the other guys do. But in the end, the
marketplace will decide. And yes, it's a distorted marketplace
and sometimes the dragon wins. But at least we still have a
marketplace.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
kanze
> wka...@yahoo.com wrote:
> > Eventually, it may not be feasable to write a competitive
> > application in ISO C++ that's targeted to Windows.
> That statement is most likely already true for a large
> number of programming languages.
I don't know about Windows, but that's already true for C++ and
Unix. You cannot write a competitive application targetting a
Posix compatible base in pure C++.
This will remain true as long as standard C++ doesn't cover many
of the functionality we need: threads, interprocess
communication, GUI...
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Nicola Musatti
P.J. Plauger wrote:
[...]
> -- Sometimes C++/CLI is criticized for not being exactly Standard
> C++. Kanze's point above is that *every* implementation that
> calls itself Standard C++ (with the notable exception of those
> that use the EDG front end and Dinkumware C and C++ libraries)
> does too. And yet the notion of what constitutes Standard C++
> survives.
True. On the other hand none of these have been submitted to ISO for
fast track standardization as C++/Something.
> -- Sometimes C++/CLI is criticized for deviating from the purity
> of Standard C++ by adding strange new syntax and semantics
> (Glassborow's point above). My point in response is that *every*
> implementation that calls itself Standard C++ does too. And
> yet the notion of what's "portable" Standard C++ survives.
If I understood Francis correctly his point is not a critique of the
way C++/CLI diverges from C++, but rather that the amount of divergence
is such that calling it C++/Something is misleading. I tend to agree
with this point of view.
> -- Sometimes C++/CLI is criticized for pushing the language in
> boldly different directions from Standard C++. Well, that's
> what Standard C++ did to traditional C++. Compare ISO/IEC
> 14882:2003 to the Annotated Reference Manual. And that's what
> WG21 is now doing to Standard C++ with C++0X. It's called
> exploration, and sometimes progress. And it's *necessary*
> to ensure that something meaningfully called Standard C++
> survives in the long run.
This in itself is certainly good, even though some would have preferred
that other routes (read syntax) be taken to achieve the same results
functionally. This is my case, but I readily admit that I don't have
the experience nor have put in a comparable effort to what was
necessary to make C++/CLI what it is today.
> -- Sometimes C++/CLI is criticized as a possible source of
> confusion about what constitutes "true" C++. Well, that's
> what Standard C++ has done to Standard C. Despite Glassborow's
> easy dismissal, this is an ongoing problem; all you have to
> do is read comp.lang.c for a week or two to see that. And
> yet Standard C survives. So too will Standard C++ in the
> presence of Standard C++/CLI.
That's true and it's a pity, witness how often we read about "the C/C++
language" or "C/C++" as a term of comparison with other languages. I
believe that this is harming both the C and the C++ programming
community. However it's too late to do anything about it. It may also
be too late with C++/CLI, but not as late.
> We can spend weeks more shuffling between sizeof ('a'), which
> only a language lawyer can get exercised over, and how a
> 19-year-old sees a programming language. We can question the
> motives of Microsoft, based on their past performance or our
> current state of indigestion. We can postulate scenarios of
> doom if the broad tent called C++ gets any broader. But we
> shouldn't lose sight of the basic facts:
>
> -- C++/CLI is a major product just released by Microsoft that
> includes one of the most conforming C++ compilers you can
> buy today.
True.
> -- The language it implements is now a formal standard
> developed under the aegis of ECMA and submitted to ISO
> for fast-track approval. That's a well documented process
> that has been used by other stndards and announced well
> in advance by Microsoft.
True. However it is still a process that avoids full confrontation with
the official body that represents the C++ programming community, namely
the standardization committee, no matter the amount of communication
between TC5 and WG21.
> -- It also includes technology that many people in the
> standards community have been exploring as useful additions
> to Standard C++.
True.
> -- The added technology takes the form of a remarkably coherent
> dialect that blends quite well with Standard C++. (That's my
> opinion, based on a couple of years of developing a nontrivial
> commercial product, but others have reported similar findings.)
I have no reason not to believe you.
> -- Anything you can say about the confusion between C++ and
> C++/CLI you can also say about C and C++.
All the more a reason not to repeat the same mistake another time.
> -- Getting back to the title of this thread, marketing is
> *supposed* to be suggestive. It's up to us consumers to
> weigh the merits of loud and conflicting suggestions.
Suggestive is not the same as misleading, but I do understand that
marketing results are measured in terms that have little or nothing to
do with technical correctness.
Cheers,
Nicola Musatti
P.J. Plauger
> In article <1139448213.8...@g47g2000cwa.googlegroups.com>, Le
> Chaud Lapin <unorigina...@yahoo.com> writes
>>class native {};
>>value class V {};
>>ref class R {};
>>interface class I {};
>>
>>Now we ask, "Is this C++, C++/CLI, or both?"
>>
>>Well it is not C++. No C++ compiler will compile it. It cannot be
>>both. No C++ compiler will compile it.
>
> Sorry, but I disagree. Any C++ compiler that also compiles C++/CLI will
> compile it. In that sense it is exactly like any other case of
> extensions. The only requirement is that in conforming mode the compiler
> issue a diagnostic which could be:
>
> 'Nice to see you using the CLI extensions.'
Not necessarily. I know the Standard C rules were worked over when
they got picked up by the C++ Standard, but I think they still
agree in essential details. If a compiler gives meaning to
otherwise undefined behavior, it is not obliged to issue a
diagnostic.
A closer analog is a program that conforms to Posix. A
*program* can be well formed for using many parts of Posix,
but an *implementation* doesn't conform to the extent that
it puts certain Posix function declarations in standard
header files. Sometimes you want your compiler to provide
the Posix extensions to Standard C, like when you're writing
a program to run under Posix. Sometimes you don't, like when
you're checking for portability. A compiler vendor that
insists on providing just one of these two modes will find
a smaller marketplace than one more accommodating to the
needs of real programmers.
> Extensions are almost by definition 'non-portable'. And while the
> C++/CLI extensions are targeted at supporting code for a specific
> platform I suspect that someone with enough determination could write a
> compiler that compiled C++/CLI for another platform of their choice.
I'm told that sort of thing is happening, though there is no
question that Microsoft got there first. Just like AT&T once
did with C and C++.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
kanze
> kanze wrote:
> > The exact statement was: "What I have yet to figure out is
> > what Goliath is giving David to make him promulgate the
> > preposterous." My understanding of English is that that
> > statement implies very strongly that the Davids in question
> > (in previous statements he named Stan Lippman, Herb Sutter
> > and P. J. Plauger explicitly) as having been bribed to make
> > untrue statements. And that is slander: "a false and
> > malicious statement or report about someone" (to quote the
> > definition in the "American Heritage Dictionary").
> Bribed no.
That is, never the less, what is insinuated by the statement I
quoted.
> What I was implying, and which I will no longer imply
> anymore, but state explicitly now:
> 1. Microsoft is engaged in a campaign to [insert whatever
> term you prefer here] the primary tool that we use to do our
> jobs.
Improve?
Without knowing what verb you are thinking of, it's hard to
judge the statement. And FWIW, I've not seen Microsoft make the
slightest effort to affect any of the tools I use to do my job.
G++ remains g++, Sun CC remains Sun CC (and Solaris remains
Solaris, SQL remains SQL, etc., etc.). While I've seen some
talk that Microsoft wants to make a portable platform, for the
moment, Microsoft is only relevant in the Windows world.
Now, it's quite possible that people using Microsoft development
tools under Windows end up with unportable code, code which
won't work if they use g++ or Sun CC under Solaris. But that's
not really anything new -- phread_mutex_t mutex =
PTHREAD_MUTEX_INIT (something I use a lot) probably doesn't work
very well with the Microsoft tool chain, either. (Interestingly
enough, no one seems to mind that I call my code C++, either.)
> For example, only the very naive would read a column entitled
> "Pure C++" that contains code that is obviously not pure C++
> and not wonder why a large, influential company insists on
> calling the column Pure C++.
> 2. Several experts seem to be unabashedly supporting this process.
Which process? Improving the development environment, or making
possibly unjustified claims in marketing?
> 3. Junior C++ coders often look to these same experts for
> advice on C++.
And...
> 4. If there is potential for subversion of C++ as we now know
> it due to C++/CLI, it might be a good idea for the experts to
> clearly state their positions now. Why? See #3.
Once again, subversion is a loaded word. Why? And what
positions do you want to be stated? I've not seen anything that
I would consider subversion (but I've not paid much attention to
CLI), and the only positions I've seen from the experts that
you've named have been clear enough, and very supportive with
regards to standard C++.
> > The entire tone of the posting in question was one of anger
> > and "ennervement" -- an emotional context where people do
> > make statements which they don't really mean. And the
> > poster has since posted an appology for any personal
> > intuendo; I presume that while he still doesn't like
> > C++/CLI, he accepts that the technical experts behind it
> > have a different technical opinion, and have not just been
> > "bought off".
> Actually, I do not really know the technical opinions of the
> experts.
And yet you criticize them? They're not a secret; it's not as
if Herb Sutter has never publicly expressed his opinion, or
written anything that you could read.
> In fact, that is what I was complaining about originally. Did
> I think that Microsoft pulled [insert name of expert] aside
> and said, "Hey, here's $350,000.00US help you be more
> open-minded about the interpretation of the phrase 'Pure C++'"
> No. But let's face it. We are all human. Perhaps there was
> resistance early on that waned after time and familiarity.
I still haven't understood what "positions" you're objecting to.
>From what I've seen, Herb has been pulling Microsoft in the
direction of standard C++, and not the reverse.
> So my statements are more like a stick to say, "Hey, is is
> this what you really want? Because if it's what you want, by
> default, it's what 5000 other programmers want."
> But, if those experts say, "Yes, I see what you mean about the
> suggestive marketing, and yes, I see what you are saying about
> calling it Pure C++ when there is a foreign syntax all over
> the page that many skilled C++ programmers have never seen,
> and yes, I see that they are trying to standardize their
> add-on through a somewhat serendipitous path, and yes, I am
> aware of what will probably happen to "pure" (take note of the
> lower-case) C++ if Microsoft gets its way, but in spite of
> all this, I still support what they are doing."
How about if you tried to express just the technical issues,
without all of the loaded words. The standardization path isn't
"serendipitous", it's a fully standard path, which Sun
abandonned for Java because it meant loosing too much control
over the language, and actually having to listen to what others
are saying about it. The fact that Microsoft has stuck to this
process represents a very favorable evolution; to be truthful, I
didn't expect it from them. As for what will happen with pure
C++, it depends on what the ISO committee decides -- Microsoft
has exactly one vote (out of thirty or fourty, I think) in the
American national body, which in turn has only one vote (out of
around 10?) in ISO.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
P.J. Plauger
> In article <VrGdnWQ_Cvx_t3fe...@giganews.com>, P.J. Plauger
> <p...@dinkumware.com> writes
>>Sorry, but I've yet to see the bright line that puts purported
>>Standard C++ implementations on one side and C++/CLI on the
>>other. Unless, of course, you're willing to admit that C++
>>should no longer corrupt the name C and end the long standing
>>C/C++ confusion as well.
>
> There is a very simple one, they are just extensions and while some
> extensions are more acceptable than others
And who gets to choose the acceptable ones? Seems to me that
going through ECMA and ISO, with all the open discussion and
balloting that entails, is one way to determine whether something
is "acceptable".
> (and I seem to recall that
> those responsible for gcc have been pulling back from many of their
> earlier extensions). What places C++/CLI (IMO) into an entirely
> different domain is the attempt to have ISO make it a standard. Change
> the name to one that is not prone to abbreviation to 'C++' and I have no
> problem with it and treating it as a new and distinct member of the C
> family of languages (and I even think a pretty good one).
If C++/CLI can't use C++ as part of it's name, then for exactly
the same reason ISO should take the C out of C++. Maybe just "++"?
> How do you think the world would react if those responsible for Symbian
> C++ went to ECMA and sought a standard for C++/Symbian and then tried to
> fast track it to an ISO C++/Symbian standard?
For my part, I'd see whether ECMA approved the work. If it did,
I'd comment on it as it progressed. And if it made it to ISO
I'd comment some more. But if ISO approved it, I'd accept it.
And along the way I'd humbly assume that my voice was just one
of many, not to be taken as the final arbiter.
I suspect that "the rest of the world" might also object in
sufficient quantities. But if they didn't, I'd consider myself
outvoted.
> Or perhaps that those
> responsible for g++ sought (by the same route) a standard called
> C++/GNU?
Same as above. There is, in fact, a large community that writes
code that only works with C++/GNU, because it relies on the
still numerous nonstandard extensions in that dialect. And
many in that community seem to see some virtue in promoting
that dialect over Standard C++.
> There should be one C++ Standard that is periodically reviewed.
And there is. There are also dialects out there with varying
degrees of overlap. One is ISO C. Another is ECMA C++/CLI,
which may yet become ISO C++/CLI.
> I could
> even, just about, live with a TR to cover extensions to C++ for use with
> a platform (in this case CLI).
How about an ECMA standard? It already exists.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Thant Tessman
> Thant Tessman wrote:
[...]
>>The objection is not with progress. The objection is with the
>>possibility that an industry standard is being hijacked for the benefit
>>of a single corporation (with a history of this kind of thing) and that
>>it's being called "progress."
>
>
> As far as I know, Microsoft gets one vote on the C++ committee,
> the same as any other company.
And apparently the blessing of more than one very well-known C++ expert.
> If they are "hijacking" the
> standard, they are doing it by doing useful work which is being
> appreciated by others.
That is, as long as we assume that these influential C++ celebrities are
completely objective and disinterested in their evaluation of the
contribution C++/CLI supposedly makes to the advancement of the craft of
computer programming.
-thant
--
The nationalist not only does not disapprove of atrocities
committed by his own side, but he has a remarkable capacity
for not even hearing about them. -- George Orwell
Hyman Rosen
> If a compiler gives meaning to otherwise undefined behavior,
> it is not obliged to issue a diagnostic.
But if a conforming implementation accepts code that is not
well-formed, it must. See 1.4/8.
Gabriel Thomas Dos Reis
| Bob Hairgrove wrote:
| > ostrstream or ostringstream?
|
| The deprecated one.
So in summary, to write a portable C++ code, one has to avoid the
standard function, deprecated by a corporation, in favor of the
standard-deprecated feature?
--
Gabriel Dos Reis
g...@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
Hyman Rosen
> True. However it is still a process that avoids full confrontation with
> the official body that represents the C++ programming community, namely
> the standardization committee, no matter the amount of communication
> between TC5 and WG21.
C++/CLI is not intended to become the new Standard C++,
so why would the committee want to confront it? The
committee has plenty of work to do without having to
comment on variants and dialects.
Chris Hills
<hyr...@mail.com> writes
>Nicola Musatti wrote:
>> True. However it is still a process that avoids full confrontation with
>> the official body that represents the C++ programming community, namely
>> the standardization committee, no matter the amount of communication
>> between TC5 and WG21.
>
>C++/CLI is not intended to become the new Standard C++,
unless you read the MS manuals and marketing material
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Hyman Rosen
> Hyman Rosen <hyr...@mail.com> writes
>> C++/CLI is not intended to become the new Standard C++,
> unless you read the MS manuals and marketing material
Right now, no one is trying to officially change Standard C++
into C++/CLI, so there is no reason to present C++/CLI to the
full committee. Whichever members feel like getting involved
with C++/CLI can do so, but if their only contribution is to
denigrate those parts which are not C++, they're going to be
ignored.
If it should happen at some future time that C++/CLI is
perceived to be what Standard C++ should become, that will be
the time for the full committee to have at it. If Microsoft
wants to work toward that goal, that's fine. If you want to
try and stop them, that's fine too.
Hyman Rosen
> So in summary, to write a portable C++ code, one has to avoid the
> standard function, deprecated by a corporation, in favor of the
> standard-deprecated feature?
You do understand why sprintf is deprecated? We had a third-party
library which we were using that did 'sprintf(buf, "%f", number)'.
It looks perfectly innocent, but a problem elsewhere occasionally
set number to be in the 1e300 range, and the buffer wasn't large
enough to hold all three hundred digits, so the program crashed.
Like gets() before it, sprintf() is an accident waiting to happen.
Anyway, if you don't want to use ostrstream, ostringstream is OK
too. You'll just get your results as a string. It's just that
ostrstream mirrors the effects of snprintf most closely.
Hyman Rosen
> That is, as long as we assume that these influential C++ celebrities are
> completely objective and disinterested in their evaluation of the
> contribution C++/CLI supposedly makes to the advancement of the craft of
> computer programming.
The others I referred to aren't just the celebrities, but also include
regular programmers who had to deal with the ugly Managed C++ or who
had to switch away from C++ altogether in order to program for .NET.
I haven't seen much in the way of technical objections to C++/CLI, or
explanations of why the design is wrong. Mostly there's just whining
about how evil Microsoft is, or how the purity and beauty of C++ is
being ruined by the extensions. (Actually, that last one is hilarious
if you can step back and look at it with objectivity.)
You make sly implications that these "influential C++ celebrities" are
supporting C++/CLI only because they are paid to do so. What evidence
do you have for that? Who are you to impose requirements of objectivity
and disinterest? Why are people who have worked on a project not to be
respected if they show enthusiasm for it?
To me, it seems that C++/CLI has done a yeoman's job in combining
CLI's garbage collected objects with C++'s promiscuous pointers and
in preserving standard C++ while supporting CLI with first-class
syntax. It's good that this will establish existing practice, so that
if the committee decides to address garbage collection within Standard
C++, it will not have blaze a path into unexplored territory.
Chris Hills
<hyr...@mail.com> writes
>Chris Hills wrote:
>> Hyman Rosen <hyr...@mail.com> writes
>>> C++/CLI is not intended to become the new Standard C++,
>> unless you read the MS manuals and marketing material
>
>Right now, no one is trying to officially change Standard C++
>into C++/CLI,
Unless you read the MS material.
>so there is no reason to present C++/CLI to the
>full committee.
You mean the full ECMA committee? If you mean the ISO C++ committee you
are correct until the point where ECMA submits the c++/CLI ECMA standard
to ISO for approval Then the full ISO committee should, and has, got
involved.
>Whichever members feel like getting involved
>with C++/CLI can do so, but if their only contribution is to
>denigrate those parts which are not C++, they're going to be
>ignored.
Ignored by whom? If you mean the ISO C++ panels then ISO will listen to
them. I don't mind this new C++/CLI language being a Microsoft/ECM
standard I just don't want it as an ISO language.
>If it should happen at some future time that C++/CLI is
>perceived to be what Standard C++ should become, that will be
>the time for the full committee to have at it.
It is being presented as that in some areas. Therefore the ISO committee
has got involved.
> If Microsoft
>wants to work toward that goal, that's fine. If you want to
>try and stop them, that's fine too.
OK.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris Hills
<hyr...@mail.com> writes
>Gabriel Thomas Dos Reis wrote:
>> So in summary, to write a portable C++ code, one has to avoid the
>> standard function, deprecated by a corporation, in favor of the
>> standard-deprecated feature?
>
>You do understand why sprintf is deprecated?
By whom? If you mean Microsoft then it is not deprecated unless MS is
now dictating the standards without going through the ISO process... or
is that what we are all complaining about?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Le Chaud Lapin
> If it should happen at some future time that C++/CLI is
> perceived to be what Standard C++ should become, that will be
> the time for the full committee to have at it. If Microsoft
> wants to work toward that goal, that's fine. If you want to
> try and stop them, that's fine too.
I'd be curious to know if there are any legal means of blocking what
Microsoft is doing. There are stringent laws against false
advertising in Germany and several other European countries. A lawsuit
would at least bring more public attention to the matter.
Some of you may think this is extreme, but the spirit of regulation has
always been promote fair competition.
I read recently in the Windows Kernel newsgroup that Microsoft had
intended to let all device drivers be written in C#. I asked one of
the regulards if it was true and he said that the program had been
postponed:
It should be patently evident that Microsoft is attempting to steer the
minds of the best developers in the industry toward a proprietary
platform. But what makes C++/CLI different is that, instead of trying
to lure them away with cool tools (that often get rejected), they are
attempting to subvert a common, public utility (C++) so that,
eventually, we will have no choice.
I think software introduces many, unanswered legal and ethical
questions about proprietorship and free-enterprise. In fact, I imagine
if we were in court trying to describe what C++ is and why it is
important to maintain its integrity, most of us (I certainly would)
have a hard time doing so.
-Le Chaud Lapin-
Bo Persson
"Hyman Rosen" <hyr...@mail.com> skrev i meddelandet
news:200602101443....@cliffclavin.cs.rpi.edu...
> Thant Tessman wrote:
>> That is, as long as we assume that these influential C++
>> celebrities are
>> completely objective and disinterested in their evaluation of the
>> contribution C++/CLI supposedly makes to the advancement of the
>> craft of
>> computer programming.
>
> The others I referred to aren't just the celebrities, but also
> include
> regular programmers who had to deal with the ugly Managed C++ or who
> had to switch away from C++ altogether in order to program for .NET.
>
> I haven't seen much in the way of technical objections to C++/CLI,
> or
> explanations of why the design is wrong.
There probably isn't anything wrong with it for those who want to
program for CLI exclusively. What's in it for the rest of us?
> Mostly there's just whining
> about how evil Microsoft is, or how the purity and beauty of C++ is
> being ruined by the extensions. (Actually, that last one is
> hilarious
> if you can step back and look at it with objectivity.)
What is hilarious is the insistance that it still is the same
language, while also a great improvement.
The sponsors of the "ECMA C++/CLI"-language also calls their language
"C++", "New C++", and "a natural evolution of the C++ language".
Why?!
>
> You make sly implications that these "influential C++ celebrities"
> are
> supporting C++/CLI only because they are paid to do so. What
> evidence
> do you have for that? Who are you to impose requirements of
> objectivity
> and disinterest? Why are people who have worked on a project not to
> be
> respected if they show enthusiasm for it?
>
> To me, it seems that C++/CLI has done a yeoman's job in combining
> CLI's garbage collected objects with C++'s promiscuous pointers and
> in preserving standard C++ while supporting CLI with first-class
> syntax. It's good that this will establish existing practice, so
> that
> if the committee decides to address garbage collection within
> Standard
> C++, it will not have blaze a path into unexplored territory.
And still there is already garbage collecting implementations
available, that does not extend the ISO C++. And that does not limit
the code to a single platform.
Bo Persson
Hyman Rosen
> By whom?
The seething mass of humanity. It's deprecated by common
consensus, because it is dangerous to use and there are
safer alternatives available.
If you are offended by the warning, you can always request
not to see it. Unlike many other compilers, Microsoft's
provides very fine-grained means for controlling which
warnings are emitted.
![Nevin ":-]" Liber's profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXJKiSJZv_QOQCq7aPQlA0Cd-oFI6nJwhwPcaf5KSPL4CqbzPw-Lw=s40-c)
Nevin ":-]" Liber
"Le Chaud Lapin" <unorigina...@yahoo.com> wrote:
> I'd be curious to know if there are any legal means of blocking what
> Microsoft is doing. There are stringent laws against false
> advertising in Germany and several other European countries. A lawsuit
> would at least bring more public attention to the matter.
And such a lawsuit could pretty much kill C++.
1. Microsoft could drop support for it.
2. Someone else could sue most other vendors for the same thing: not
implementing the entire standard and having non-standard extensions.
3. Developers would stay away from a language which is both unsupported
by a major OS vendor and has legal entanglements.
> I read recently in the Windows Kernel newsgroup that Microsoft had
> intended to let all device drivers be written in C#.
So? Windows is their platform. Except for technical concerns, why
shouldn't it be possible to write device drivers in all the languages
they support?
> It should be patently evident that Microsoft is attempting to steer the
> minds of the best developers in the industry toward a proprietary
> platform.
Apparently you don't think much of "the minds of the best developers in
the industry" if you feel they can be steered easily.
Then again, given that your only complaint about C++/CLI is its name,
one could conclude that (given your lack of any technical issues) you
believe that C++/CLI is, in all other respects, a wonderful language.
Heck, the sheer number of posts on C++/CLI in what you believe is this
"pure" C++ newsgroup, adds credence to C++/CLI being a legitimate
extension of C++.
> But what makes C++/CLI different is that, instead of trying
> to lure them away with cool tools (that often get rejected), they are
> attempting to subvert a common, public utility (C++) so that,
> eventually, we will have no choice.
Are you saying that, unlike all other vendors, Microsoft should not be
allowed to extend C++? Do you honestly think it is better if they
follow Sun's model for Java, where they have to own and control it
instead of going through the process of making a standard (and a
standard which is distinct from C++)? Really? If they just changed the
name, but still advertised that they can compile most existing C++ code
with it just fine, would you be any happier about it?
--
Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (773) 961-1620
Hyman Rosen
>> into C++/CLI,
> Unless you read the MS material.
I wasn't aware that one could change an ISO language standard
by publishing promotional literature. In fact, you can't, so
Microsoft's material is not an attempt to change Standard C++
into C++/CLI.
> You mean the full ECMA committee? If you mean the ISO C++ committee you
> are correct until the point where ECMA submits the c++/CLI ECMA standard
> to ISO for approval Then the full ISO committee should, and has, got
> involved.
Why would the full C++ committee get involved in the C++/CLI
standard? It's a separate, albeit related, language.
> Ignored by whom? If you mean the ISO C++ panels then ISO will listen to
> them. I don't mind this new C++/CLI language being a Microsoft/ECM
> standard I just don't want it as an ISO language.
It's certainly possible for people to join ISO committees solely
for the purpose of blocking standards. There was a case a few years
ago when Germany (represented by one person) voted against the
Fortran/2000 standard for crackpot reasons not dissimilar to the
C++/CLI objections. ISO committees like to achieve unanimous votes,
but they can just go with counted votes if unanimity is unreachable
because of pigheadedness.
Standardization committees hold their meetings all over the world,
and attendance at some number of consecutive meetings is required
before a member is allowed to vote. That means that the crazies
have to be truly dedicated, and rich, to be able to block a standard.
> It is being presented as that in some areas. Therefore the ISO committee
> has got involved.
I understand that some people have glorious visions of committee
members in shining armor racing to intercept a raging C++/CLI and
slaying it before it can corrupt the minds of defenseless programmers
but I can assure you that's not going to happen. The committee is in
charge of Standard C++. They accept or reject proposals for change as
it suits them to do so. Standard C++ will forever be what they choose
it to be, and if it becomes C++/CLI it will be because that's what
they wanted. But some other committee will be in charge of ISO C++/CLI,
and that will become a standard on its own merits.
Francis Glassborow
>It should be patently evident that Microsoft is attempting to steer the
>minds of the best developers in the industry toward a proprietary
>platform. But what makes C++/CLI different is that, instead of trying
>to lure them away with cool tools (that often get rejected), they are
>attempting to subvert a common, public utility (C++) so that,
>eventually, we will have no choice.
You need to be very careful to distinguish between Microsoft as a
corporation and the employees of Microsoft. They have a number of
dedicated C++ supporters who have clearly been fighting against the
concept that C# should effectively replace C++ in the Microsoft World. I
think we should acknowledge this and be supportive of their efforts to
keep C++ as a major player in the Microsoft World.
Note that I have not been objecting to the content of C++/CLI only to
its name and the view that it is no more than a binding (+ a few
extensions) to C++. What happens when WG21 want to make changes and/or
additions to C++ that conflict with C++/CLI? This is not mere
speculation, WG21 intends adding delegating ctors in the next release,
and C++/CLI intended doing the same thing. Unfortunately what is the
correct thing to do when an exception is thrown within a delegating
ctor's body is different (or at least the Microsoft experts argue
strongly for a different answer, saying that the WG21 does not work for
them, yet WG21 has strong examples of why their answer is 'correct' for
C++). AIUI the current release of C++/CLI is agnostic on the subject
(I.e. did not add delegating ctors) but will not remain so.
The principle underlying Standard portable languages (as opposed to
single platform languages such as Java) is that the language specifies
behaviour that is implementable (and consistent) on all platforms.
Effectively C++/CLI is a derivative language of C++ designed for a
single platform and as such uses a different object model. However it is
also has devices to allow it to use unmodified C++ (just as C++ is
designed so that it can largely use unmodified C90). The reason that I
(and the BSI C++ Panel) want a name change is that we believe that this
new member of the C family of languages should be clearly and
unambiguously distinct from ISO C++. We accept that the changes made by
C++/CLI are well thought out by a team of very competent language
designers and have no argument with the result as long as it is kept
clearly distinct from C++.
We also have a very strong objection to the process of developing a
language standard in ECMA (where National Bodies have no official
existence) and then endeavouring to get it converted into an ISO
Standard via the Fast Track process. But that is another issue though
one that is highlighted by the current one.
To the best of my knowledge, BSI has never been negative on the subject
of C++ though over recent years there have been some problems with C. We
have the second largest group of NB technical experts and even when
finances restrict our attendance at WG21 meetings our representatives
keep in continual touch during meetings with a couple of dozen actively
participating experts in the UK.
We have reason to believe that our views on this issue have considerable
support elsewhere including in ANSI J16, but even were this not the case
we would abide by our stand on the issue that there should be only one
ISO C++ Standard and that having a second called C++/CLI is in conflict
and likely to cause ongoing confusion to those not directly involved.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Bo Persson
> Chris Hills wrote:
>> Hyman Rosen <hyr...@mail.com> writes
>>> Right now, no one is trying to officially change Standard C++
>>> into C++/CLI,
>> Unless you read the MS material.
>
> I wasn't aware that one could change an ISO language standard
> by publishing promotional literature. In fact, you can't, so
> Microsoft's material is not an attempt to change Standard C++
> into C++/CLI.
No, it's an attempt to make C++/CLI an ISO standard. :-)
>
>
> I understand that some people have glorious visions of committee
> members in shining armor racing to intercept a raging C++/CLI and
> slaying it before it can corrupt the minds of defenseless
> programmers
> but I can assure you that's not going to happen. The committee is in
> charge of Standard C++. They accept or reject proposals for change
> as
> it suits them to do so. Standard C++ will forever be what they
> choose
> it to be, and if it becomes C++/CLI it will be because that's what
> they wanted. But some other committee will be in charge of ISO
> C++/CLI,
> and that will become a standard on its own merits.
Exactly how many ISO C++ programming language standards do you belive
is the proper number?
Bo Persson
"The good thing about standards is that there are so many to choose
from."
Francis Glassborow
Rosen <hyr...@mail.com> writes
>Standardization committees hold their meetings all over the world,
>and attendance at some number of consecutive meetings is required
>before a member is allowed to vote. That means that the crazies
>have to be truly dedicated, and rich, to be able to block a standard.
Absolutely wrong. ISO ballots are for NBs not for individuals or
companies. It is not a requirement that any representative of a NB has
attended even a single meeting for an NB to vote. Indeed NBs are
actually required to vote (though some, sometimes, miss their
obligation)
It has become conventional that an NB with no interest in a Standard
will vote yes though abstaining might sometimes be more appropriate.
I have snipped all the rest of your post because it generally contained
a great deal of heat and rather little light. Names matter and ISO has
rules about name conflicts and it was in accordance with those rules
that BSI (the UK NB) objected procedurally to the Fast track of the ECMA
C++/CLI Standard. In addition, note that NBs have no input to the ECMA
process which is entirely based on consortiums of companies. In the case
of C++/CLI Herb Sutter managed to get consent for NB experts to attend
meetings and view documents. However, at the end of the day that
participation was limited and did not allow us to vote on the final
document.
Yes, some of us believe that the ECMA + ISO Fast track process is being
abused. But as I have said elsewhere, that is a different issue and not
one of immediate concern to the C++ community.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
kwikius
Francis Glassborow wrote:
> The principle underlying Standard portable languages (as opposed to
> single platform languages such as Java) is that the language specifies
> behaviour that is implementable (and consistent) on all platforms.
I wonder if this isnt a little unfair to Java. It might be truer to
say that Java carries its own virtual platform with it onto the
particular real platform it runs on. Personally I admire that about
Java. It makes the language much more consistent and easy to use.
Its unclear if you are saying that C++ is a portable language in the
above paragraph. I dont think it is. There are many features that
modify their behaviour across platforms, a notable example being the
number of bits in an int. It is this kind of platform dependent
behaviour that I find exasperating about C++. A truly platform
independent language would have a set of built-in types that are
consistent across platforms, as Java does I believe.
Apologies finally for cutting across your stride so to speak.
regards
Andy Little
Le Chaud Lapin
> And such a lawsuit could pretty much kill C++.
Kill it, no. C++ would not be in jeopardy of disappearing anymore than
French would be in jeorpardy of disappearing (whose erosion in favor of
English has been slowed by French laws).
> 1. Microsoft could drop support for it.
Microsoft would make the financially prudent choice - start calling
C++/CLI what it really is - a new language.
> 2. Someone else could sue most other vendors for the same thing: not
> implementing the entire standard and having non-standard extensions.
There would be no basis for the lawsuits. There would be
truth-in-advertising, as the vendors would call their "non-standard
extensions" "non-standard extensions", and where there are
deficiencies, these deficiciencies would be quite clear from the
purchases of the language.
> 3. Developers would stay away from a language which is both unsupported
> by a major OS vendor and has legal entanglements.
Support for Standard C++ would reamain, and as mentioned, Microsoft
would quickly find a financially prudent way to untangle itself.
> > I read recently in the Windows Kernel newsgroup that Microsoft had
> > intended to let all device drivers be written in C#.
>
> So? Windows is their platform. Except for technical concerns, why
> shouldn't it be possible to write device drivers in all the languages
> they support?
Not all languages, one language. Even so, Microsoft has every right to
force developers to write Microsoft Windows device drivers in C# if
they so choose.
> > It should be patently evident that Microsoft is attempting to steer the
> > minds of the best developers in the industry toward a proprietary
> > platform.
>
> Apparently you don't think much of "the minds of the best developers in
> the industry" if you feel they can be steered easily.
On the contrary. I do not think they can be steered easily at all.
But if the device driver has to be written in C#, then there really
isn't a choice. If the user-mode code has to be written in the
ECMA-standardized-new-and-improved-natural-evolution-of-C++, then there
really isn't a choice.
In fact, this point makes one wonder how many goverment and
para-military organizations have policies that dictate what languages
code can be written in. I would imagine that there are cases where the
prescribed set of program languages is directly linked to the some set
endorsed by a recognized standards body. What happens when these
organizations require that code be written in an ISO/ECMA-approved
language"? What happens when half of the team want to write the code in
"pure C++", and the other half wants to write the code in "Pure C++"?
The "pure C++" folks would lose the argument because the "Pure C++"
team could quickly point out that all the .NET-related syntax in the
formerly "pure C++" code is "{p|P}ure ECMA/ISO-approved C++."
> Then again, given that your only complaint about C++/CLI is its name,
> one could conclude that (given your lack of any technical issues) you
> believe that C++/CLI is, in all other respects, a wonderful language.
Non sequitur.
> Heck, the sheer number of posts on C++/CLI in what you believe is this
> "pure" C++ newsgroup, adds credence to C++/CLI being a legitimate
> extension of C++.
Non sequitur.
> Are you saying that, unlike all other vendors, Microsoft should not be
> allowed to extend C++? Do you honestly think it is better if they
> follow Sun's model for Java, where they have to own and control it
> instead of going through the process of making a standard (and a
> standard which is distinct from C++)? Really? If they just changed the
> name, but still advertised that they can compile most existing C++ code
> with it just fine, would you be any happier about it?
Microsoft has already provided proprietary extensions, as have many
other vendors. Occasionally Microsoft will make it clear that these
extensions are not part of C++, by labeling the extension
"Microsoft-specific." This is truthful and generally acceptable by
everyone.
Yes, if they changed the name to something like,
".NET-Disguised-As-C++", I would have no complaints.
-Le Chaud Lapin-
Bo Persson
"kwikius" <an...@servocomm.freeserve.co.uk> skrev i meddelandet
news:1139682993.5...@g14g2000cwa.googlegroups.com...
>
> Francis Glassborow wrote:
>
>> The principle underlying Standard portable languages (as opposed to
>> single platform languages such as Java) is that the language
>> specifies
>> behaviour that is implementable (and consistent) on all platforms.
>
> I wonder if this isnt a little unfair to Java. It might be truer to
> say that Java carries its own virtual platform with it onto the
> particular real platform it runs on. Personally I admire that about
> Java. It makes the language much more consistent and easy to use.
In practice it limits its usefulness to platforms where it is easy to
port the VM.
The usual counter argument is to ask what languages are use to
implement the low level parts of the VM. Obviously not Java, but some
other language portable to the same platforms.
>
> Its unclear if you are saying that C++ is a portable language in the
> above paragraph. I dont think it is. There are many features that
> modify their behaviour across platforms, a notable example being
> the
> number of bits in an int. It is this kind of platform dependent
> behaviour that I find exasperating about C++. A truly platform
> independent language would have a set of built-in types that are
> consistent across platforms, as Java does I believe.
I believe the contrary, that it is exacly the lack of hardwired rules
that makes C++ *efficiently* portable to a wide range of hardware.
Allowing an int to be 36 bits on a 36-bit machine actually *increases*
portablity, it does not reduce it.
Bo Persson
Chris Hills
<hyr...@mail.com> writes
>Chris Hills wrote:
>> Hyman Rosen <hyr...@mail.com> writes
>>> You do understand why sprintf is deprecated?
>> By whom?
>
>The seething mass of humanity.
Never underestimate the power of human stupidity.
>It's deprecated by common
>consensus, because it is dangerous to use and there are
>safer alternatives available.
That's OK then. You are WRONG.
Common Consensus is either ISO or the industry in general not one
corporation. Especially one which tried to dress up it's proprietary
discussions in ISO terminology and try and pass them off as "the
Standard"
I have not seen any other C++ compiler vendor following Microsfots lead
so far.
>If you are offended by the warning, you can always request
>not to see it. Unlike many other compilers, Microsoft's
>provides very fine-grained means for controlling which
>warnings are emitted.
There are no Microsoft compilers for any of the platforms I target.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/