ISO/ICE 23271:2005

[Steven T. Hatton]

Dinkumware to Develop STL for C++/CLI

http://www.dinkumware.com/

Microsoft is dramatically overhauling the managed extensions they added to
C++ for the .NET environment. The result is a new dialect that's much more
readable and highly compatible with Standard C++. It's also being
standardized by ECMA committee TC39/TG5. (For the latest public review
draft, click here.) And Dinkumware has been chosen to adapt the Standard
Template Library component of our Standard C++ library to work in the
managed environment.

http://www.dinkumware.com/tc39-tg5-2005-019.pdf

Oh, really!

 

[P.J. Plauger]

Dinkumware to Develop STL for C++/CLI

http://www.dinkumware.com/

Microsoft is dramatically overhauling the managed extensions they added to
C++ for the .NET environment. The result is a new dialect that's much more
readable and highly compatible with Standard C++. It's also being
standardized by ECMA committee TC39/TG5. (For the latest public review
draft, click here.) And Dinkumware has been chosen to adapt the Standard
Template Library component of our Standard C++ library to work in the
managed environment.

http://www.dinkumware.com/tc39-tg5-2005-019.pdf

Oh, really!

Yes, really. We appreciate the free publicity, but I'm not sure
what your point might be.

1) The title of your posting refers to the CLI standard that
was developed under ECMA aegis and adopted by ISO/IEC. That
describes the common language interface used by the various
..NET languages. It's roughly equivalent to the JVM specification
(which Sun couldn't bring itself to let ISO standardize).

2) The link you provide above is to the C++/CLI draft working
its way through ECMA TC39/TG5. That describes the additions
made to Standard C++ to better support operation under .NET.
Note that Microsoft's VC++ has included extensions for .NET
since V7.0 (.NET 2003). C++/CLI is an ambitious attempt to
make a more readable and coherent dialect for coding in the
..NET environment. It also tries to be a good citizen in the
Standard C++ world.

3) The project we've undertaken with Microsoft is to adapt
the Standard Template Library (a significant component of the
Standard C++ library) to be maximally useful in the .NET
environment. It's been a real challenge, but I think it will
prove quite useful to C++ programmers who choose to program
in C++/CLI.

You've cited three different projects, all instigated by
Microsoft as part of their much larger .NET effort.
Dinkumware had nothing to do with the first, and is only
peripherally involved in the second. But we believe all three
represent important new technology in the world of software
development.

Really.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Steven T. Hatton]

Yes, really. We appreciate the free publicity, but I'm not sure
what your point might be.

I just happen to find one of two available links to be from your site.

1) The title of your posting refers to the CLI standard that
was developed under ECMA aegis and adopted by ISO/IEC. That
describes the common language interface used by the various
.NET languages. It's roughly equivalent to the JVM specification
(which Sun couldn't bring itself to let ISO standardize).

That's a business decision that may have merit for them. Considering the
damage that can be done when on company with a virtual monopoly on the
desktop decides to 'almost' conform to a standard, they had good reason to
want to maintain control of the Java trademark.

2) The link you provide above is to the C++/CLI draft working
its way through ECMA TC39/TG5. That describes the additions
made to Standard C++ to better support operation under .NET.
Note that Microsoft's VC++ has included extensions for .NET
since V7.0 (.NET 2003). C++/CLI is an ambitious attempt to
make a more readable and coherent dialect for coding in the
.NET environment.

And it's a crying shame that so many C++ programmers can't grasp the
importance of providing the kids of programming support in question. I'm
not talking about the gc, or the "safe" code. I'm talking about the
modularity, and coherence in managing resources.

../lisp
../lisp/net
../lisp/url
../lisp/calc
../lisp/gnus
../lisp/mail
../lisp/mh-e
../lisp/play
../lisp/term
../lisp/emulation
../lisp/international
../lisp/calendar
../lisp/eshell
../lisp/toolbar
../lisp/emacs-lisp
../lisp/textmodes
../lisp/progmodes
../lisp/language
../lisp/obsolete
../site-lisp

It also tries to be a good citizen in the
Standard C++ world.
....

3) The project we've undertaken with Microsoft is to adapt
the Standard Template Library (a significant component of the
Standard C++ library) to be maximally useful in the .NET
environment. It's been a real challenge, but I think it will
prove quite useful to C++ programmers who choose to program
in C++/CLI.

Good luck. I hope it pays off. I'm not overly interested in CLI, but I do
keep a recent build of mono around for curiosity's sake. Never tried the
C++ thing. Don't even know if it's supported there.

You've cited three different projects, all instigated by
Microsoft as part of their much larger .NET effort.
Dinkumware had nothing to do with the first, and is only
peripherally involved in the second. But we believe all three
represent important new technology in the world of software
development.

I agree. The pointman on the C# project was one of Borland's key developers
for both Delphi and JBuilder - if I am to believe what I read on the net.

It's a shame to see so much interest and energy diverted away from making
real C++ the programming language that it should and could be. The
greatest problem C++ has is its excessive reliance on one proprietary
environment. I suspect CLI and .NET will satisfice a good number of
programmers, and reduce the resource pool for improving real C++. Then
again, it only takes a few really good people to make a big difference.

 

[Victor Bazarov]

[..]
It's a shame to see so much interest and energy diverted away from making
real C++ the programming language that it should and could be.

Huh? Aw, get off your high horse. I don't suppose you really believe
that C++ _isn't_ what it should or could be at this point.

> The
greatest problem C++ has is its excessive reliance on one proprietary
environment.

Huh? Which environment is that?

> I suspect CLI and .NET will satisfice a good number of
programmers, and reduce the resource pool for improving real C++.

Huh? 8-O

I'd rather see several good languages/environments develop as the result
than somehow artificially (by, say, legally prohibiting Microsoft from
doing what they are doing because of some vague "monopoly" concerns) herd
more programmers to keep "the resource pool" for C++. And I'd rather have
programmers turning to C++ because it's better suited for certain things
than because there is nothing to choose from.

> Then
again, it only takes a few really good people to make a big difference.

This is what in Russia is called "ravings of a grey mare". You need to
find yourself something to do, pal.

V

 

[Steven T. Hatton]

[..]
It's a shame to see so much interest and energy diverted away from making
real C++ the programming language that it should and could be.

Huh? Aw, get off your high horse. I don't suppose you really believe
that C++ _isn't_ what it should or could be at this point.

I believe it could be a lot better, and not all that very different from
what it is now. There are certain fundamental issues that would have been
addressed in a more platform independent and comprehensive way than they
have been. Just today, I got a linking error while compiling code, and
there was no systematic means of identifying the components involved. The
paleolithic technology used to manage C++ source code, compile, and link
it, is woefully inadequate for the complexity of the task it is applied to.
That technology has been neglected, to a large extent, because so many
people rely on one application in one restricted and tightly controlled
environment.

Huh? Which environment is that?
Win32.


Huh? 8-O

I'd rather see several good languages/environments develop as the result
than somehow artificially (by, say, legally prohibiting Microsoft from
doing what they are doing because of some vague "monopoly" concerns)

Oh, I'm not that concerned about what they are doing now with .NET. I'm
more concerned about how they got where they are. I saw what happened with
Netscape up-close and personal.

herd
more programmers to keep "the resource pool" for C++. And I'd rather have
programmers turning to C++ because it's better suited for certain things
than because there is nothing to choose from.

I'm not talking about the C++ user base. I'm talking about the C++ tool
developers, and language designers. CLI is not designed in the true spirit
of C++. It provides functionality at an unnecessary cost. It violates the
zero-overhead rule. Nonetheless, many people will go for it.

This is what in Russia is called "ravings of a grey mare". You need to
find yourself something to do, pal.

http://websvn.kde.org/branches/work/kdevelop4-parser/?rev=420247

 

[Howard]

Win32.

What excessive reliance is that? I don't see anything in my Mac C++
compilers that relies on Win32.

(Perhaps you were referring to that upcoming work which is supposed to
integrate better with .NET, not the current state of the language?)

-Howard

 

[Pete Becker]

I'm talking about the C++ tool
developers, and language designers.

Nope. You're talking about your rather slanted perspective on the C++
tool developers and language designers. Microsoft doesn't have the
disproportionate influence that you seem to think they have.

 

[E. Mark Ping]

CLI is not designed in the true spirit of C++. It provides
functionality at an unnecessary cost.

Who decides what the "true spirit of C++" is?

It violates the zero-overhead rule.

Well, so does exception handling.

Have you followed Herb Sutter's articles on the concept? I was
skeptical until I realized the boon CLI will be to C++. Of particular
interest to me is that it's an extension to C++ which will give us a
way to see how well C++ and GC can work together. The idea of
separating object lifetime management from memory reclamation is
something I'd like to see in practice. It's something the standard
C++ can benefit from tremendously.

Furtheremore, it may help recapture mindshare on C++ from Java/C#
which get a lot of hype but have many drawbacks that C++ doesn't have.

 

[Steven T. Hatton]

What excessive reliance is that? I don't see anything in my Mac C++
compilers that relies on Win32.

(Perhaps you were referring to that upcoming work which is supposed to
integrate better with .NET, not the current state of the language?)

-Howard

1.8% of the global market share? AFAIK, I have a superior compiler to the
one used in VC++, but that is no where near the whole picture. Many of the
tools I have on Linux are preferable to those found natively on Windows.
But there are many features which have not been developed on other
platforms because of a lack of resources. More importantly, there has been
little impetus for C++ to adapt to a broader range of integration
environments. Since it wasn't challenged in these areas, it didn't grow to
address the problems on its own. I don't mean to say C++ /should/ dictate a
lot about linking details, or even source code organization. (I wouldn't
cry if there were some filename extensions specified - as long as they were
generally honored) I do believe, had there been a more even distribution
of operating environments on which C++ was implemented over the years,
there would be clearer and more coherent conventions, and probably some
superior language features that would inherently solve problems which are
currently solved through a tight coupling between the development tool and
the platform.

 

[Steven T. Hatton]

Who decides what the "true spirit of C++" is?

There are certain clearly stated principles which have been used as
guidelines for two decades.

Well, so does exception handling.

If you don't use exception handling, it doesn't cost you anything. "You
don't pay for what you don't use."

"Actually, most "compromises'' can be seen as driven by the "zero-overhead
principle,'' which says that any feature you don't use shouldn't cost you
anything in time or space. That's what keeps C++ a viable systems
programming language, and what has kept it from evolving towards something
more convenient for toy examples, but less useful as a tool for everyday
programming." - BS

Have you followed Herb Sutter's articles on the concept? I was
skeptical until I realized the boon CLI will be to C++. Of particular
interest to me is that it's an extension to C++ which will give us a
way to see how well C++ and GC can work together. The idea of
separating object lifetime management from memory reclamation is
something I'd like to see in practice. It's something the standard
C++ can benefit from tremendously.

Like a drunk can benefit from free liquor?

Furtheremore, it may help recapture mindshare on C++ from Java/C#
which get a lot of hype but have many drawbacks that C++ doesn't have.

Like the fact they run on a virtual machine? Most of the things I find
unappealing about C# are going to be part of CLI/C++. I'd just as soon use
C# if I were going to code on a CLI. The one exception would be if I can
code things similar to Java3D applets. You do /that/ with CLI in a
platform neutral way, and you will have my attention.

 

[Steven T. Hatton]

Nope. You're talking about your rather slanted perspective on the C++
tool developers and language designers. Microsoft doesn't have the
disproportionate influence that you seem to think they have.

Back when Netscape was rolling out their working LDAP and PKI servers, I was
doing proof of concept work for the US DoD. Since I was one of the few
people who understood the technology, one of the people in my organization
asked me to figure out how to set up Microsoft's competing Certificate
server. It was not one of my primary tasks, so I did not, at the time, pay
a lot of attention to the political aspects of what was happening. I just
knew that I was not able to get the Microsoft server running. Nonetheless,
Microsoft was able to retain their standing vis-a-vis Netscape by giving
the appearance of delivering the server. Over a year later learned I
learned that the Microsoft techrep had told the person who asked me to do
the work that they knew their server didn't work at the time. They had
basically lied to retain their advantage, and cheated Netscape out of what
they had rightfully earned.


Remember when you accused me of trying to get others to do my work for me?
Well, here's a good measure of that work, most of which was completed at
the time you made the accusation:

http://baldur.globalsymmetry.com/~hattons/Standard/doc/html/

It still needs a lot of cleanup due to transcription errors. But the
Doxygen turned out really nicely.

 

[P.J. Plauger]

Back when Netscape was rolling out their working LDAP and PKI servers, I
was
doing proof of concept work for the US DoD. Since I was one of the few
people who understood the technology, one of the people in my organization
asked me to figure out how to set up Microsoft's competing Certificate
server. It was not one of my primary tasks, so I did not, at the time,
pay
a lot of attention to the political aspects of what was happening. I just
knew that I was not able to get the Microsoft server running.
Nonetheless,
Microsoft was able to retain their standing vis-a-vis Netscape by giving
the appearance of delivering the server. Over a year later learned I
learned that the Microsoft techrep had told the person who asked me to do
the work that they knew their server didn't work at the time. They had
basically lied to retain their advantage, and cheated Netscape out of what
they had rightfully earned.

What, you mean a vendor signified that it had more than it really
could deliver at the time, in order to stay in a bidding game?
And some Machiavellian schemers in Redmond invented this technique,
thwarting decades of honest and straightforward dealings on the
part of the entire computing industry? How horrible.

No, it's not right when companies do that. Particularly when they
get away with it, and particularly when good technology gets left
in the dust. But it has been going on for a long time, in every
competitive industry. And it doesn't necessarily reflect motivations
that are purely evil.

In particular, this specific anecdote doesn't come close to
demonstrating disproportionate influence on "C++ tool
developers, and language designers." If you think you've
responded to Pete Becker's observation, you're living in
a different universe than many of us.

More to the point, you started this thread by alluding to three
distinct projects more or less related to the C++ realm. Your only
comment was "Oh, really." I asked you what you meant by that
opaque remark and we have all since been treated by a series of
unfocused maunderings. That makes Pete's response all the more
apt.

Remember when you accused me of trying to get others to do my work for me?
Well, here's a good measure of that work, most of which was completed at
the time you made the accusation:

http://baldur.globalsymmetry.com/~hattons/Standard/doc/html/

Well, fine, but you didn't say that then, did you? And you *did*
repeatedly suggest that members of the C++ Committee should do
the work. You also hyperbolically suggested that we committee
members could do this sort of thing in times on the order of
"ten minutes", IIRC.

It still needs a lot of cleanup due to transcription errors. But the
Doxygen turned out really nicely.

More than transcription errors. It still needs *lots* of work to
be a helpful document for understanding the Standard C++ library.
And even then it's not clear that it belongs in the C++ Standard
proper.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Steven T. Hatton]

What, you mean a vendor signified that it had more than it really
could deliver at the time, in order to stay in a bidding game?
And some Machiavellian schemers in Redmond invented this technique,
thwarting decades of honest and straightforward dealings on the
part of the entire computing industry? How horrible.

Speak that you might be seen.

No, it's not right when companies do that. Particularly when they
get away with it, and particularly when good technology gets left
in the dust. But it has been going on for a long time, in every
competitive industry. And it doesn't necessarily reflect motivations
that are purely evil.

I'll leave issues of good and evil for other forums. As for intentionally
and aggressively attempting to starve Netscape of development resources by
dumping IE on the market, Yup, Microsoft did that. One of the primary
business objectives (and also moral objectives) of Netscape was to create a
platform-independent, highly portable, user interface infrastructure based
on their browser technology. They also took the same approach regarding
servers and platform independence. They were succeeding, and they were
good at it.

In particular, this specific anecdote doesn't come close to
demonstrating disproportionate influence on "C++ tool
developers, and language designers." If you think you've
responded to Pete Becker's observation, you're living in
a different universe than many of us.

Perhaps it appears that way because you have not followed my reasoning in
the discussion leading up to my reply to Peter. You need to understand two
different concepts. One is my contention that a disproportionate reliance
on Microsoft operating environments has resulted in a failure on the part
of the C++ community to solve problems in a truly protable, efficient, and
effective way. That is one point. The other point had to do with whether
Microsoft has a disproportionate influence as a company. So,

proposition 1)

the disproportionate reliance on one operating system environment, and
indeed, one development tool, had, over the years, a detrimental impact on
the development of C++ and the tools and infrastructure to support it.

proposition 2)

Microsoft, as a company, has the power to control the market in such a way
that no-one can afford to effectively challenge their de facto monopoly,
and they exercise that power.

Now, do you understand how these two arguments converge to make a point
about Microsoft having a disproportionate influence on C++ tool and
language developers? If you understood me to be saying that tool and
language developers are overtly coerced by Microsoft, you understood
incorrectly. Though there are people in this world who have made exactly
that accusation against Microsoft.

More to the point, you started this thread by alluding to three
distinct projects more or less related to the C++ realm. Your only
comment was "Oh, really." I asked you what you meant by that
opaque remark and we have all since been treated by a series of
unfocused maunderings. That makes Pete's response all the more
apt.

As for why I posted the link, and the related text, I have already explained
that your site was one of two that I found on a web search which provided a
link to the C++/CLI working draft. I figured I would provide a bit of
context for the link, by quoting the introductory paragraph from your site.

Well, fine, but you didn't say that then, did you?

"How shall I provide the files?"

And you *did*
repeatedly suggest that members of the C++ Committee should do
the work. You also hyperbolically suggested that we committee
members could do this sort of thing in times on the order of
"ten minutes", IIRC.

If I had the working text (as opposed to PDF) of a section of the C++
Standard which I had intimate knowledge of, it would be a trivial matter to
copy the relevant sections into an edit buffer. Yes, ten minutes was an
honest estimate.

More than transcription errors. It still needs *lots* of work to
be a helpful document for understanding the Standard C++ library.
And even then it's not clear that it belongs in the C++ Standard
proper.

It is not intended to be complete documentation (as I have already stated
more times than is polite.) It is intended to be comperable in function to
the ISO/IEC 9899:1999 (E) Annex B (though I was not aware of that specific
example at the time.) As for usefulness. It's already useful to me. The
results of running doxygen on the files has added considerable value to the
original product. There are a few problems with the Doxygen output, but I
have very little experience with Doxygen, so they may prove trivial to fix.

As for proposing that such an Annex be part of the C++ Standard, I have no
intention of doing so.

 

[Pete Becker]

Pete Becker wrote:



Back when Netscape was rolling out their working LDAP and PKI servers, I was
doing proof of concept work for the US DoD. Since I was one of the few
people who understood the technology, one of the people in my organization
asked me to figure out how to set up Microsoft's competing Certificate
server. It was not one of my primary tasks, so I did not, at the time, pay
a lot of attention to the political aspects of what was happening. I just
knew that I was not able to get the Microsoft server running. Nonetheless,
Microsoft was able to retain their standing vis-a-vis Netscape by giving
the appearance of delivering the server. Over a year later learned I
learned that the Microsoft techrep had told the person who asked me to do
the work that they knew their server didn't work at the time. They had
basically lied to retain their advantage, and cheated Netscape out of what
they had rightfully earned.

I see. Microsoft is controlling the C++ standard by not delivering LDAP
servers that work.

Remember when you accused me of trying to get others to do my work for me?
Well, here's a good measure of that work, most of which was completed at
the time you made the accusation:

I replied to what you said at the time. Replying to that without context
is, at best, misleading.

 

[P.J. Plauger]

I'll leave issues of good and evil for other forums. As for intentionally
and aggressively attempting to starve Netscape of development resources by
dumping IE on the market, Yup, Microsoft did that. One of the primary
business objectives (and also moral objectives) of Netscape was to create
a
platform-independent, highly portable, user interface infrastructure based
on their browser technology. They also took the same approach regarding
servers and platform independence. They were succeeding, and they were
good at it.

IIRC, Netscape began by doing much the same thing to another
company. Of course, that's legal if you're not using your
monopoly power in one arena to take unfair advantage in
another. But you, of course are talking about moral objectives,
albeit divorced from good and evil...

Perhaps it appears that way because you have not followed my reasoning in
the discussion leading up to my reply to Peter. You need to understand
two
different concepts. One is my contention that a disproportionate reliance
on Microsoft operating environments has resulted in a failure on the part
of the C++ community to solve problems in a truly protable, efficient, and
effective way. That is one point. The other point had to do with whether
Microsoft has a disproportionate influence as a company.

Oh, I think I followed your reasoning. I just agree with Pete
that you have a slanted perspective that leads you to attribute
a disproportionate influence by Microsoft. IMO, to the extent
that the problem you see is real, it's caused mostly by the
dominance of a single architecture. Over the past 40+ years,
I've seen IBM and Digital dominate important parts of the
computer business for years at a time. And both companies
were subject to much the same vilification that Microsoft now
enjoys. Doubtless some of it was earned, by all three companies,
but much of it stems from techies who are frustrated that their
"obvious" development agendas are being ignored. Get over it.

As for why I posted the link, and the related text, I have already
explained
that your site was one of two that I found on a web search which provided
a
link to the C++/CLI working draft. I figured I would provide a bit of
context for the link, by quoting the introductory paragraph from your
site.

And that *still* doesn't explain your opaque editorial remark.

"How shall I provide the files?"

That doesn't tell me that the files exist.

If I had the working text (as opposed to PDF) of a section of the C++
Standard which I had intimate knowledge of, it would be a trivial matter
to
copy the relevant sections into an edit buffer. Yes, ten minutes was an
honest estimate.

Uh, that's a pretty tiny part of the project you've outlined.

It is not intended to be complete documentation (as I have already stated
more times than is polite.) It is intended to be comperable in function
to
the ISO/IEC 9899:1999 (E) Annex B (though I was not aware of that specific
example at the time.)

Got that. And you still don't understand how far you have to go
to produce a document that's not dangerously misleading.

As for usefulness. It's already useful to me. The
results of running doxygen on the files has added considerable value to
the
original product. There are a few problems with the Doxygen output, but I
have very little experience with Doxygen, so they may prove trivial to
fix.

Good luck.

As for proposing that such an Annex be part of the C++ Standard, I have no
intention of doing so.

Sigh. You began your very first posting on that thread with the words:

: I find the Standard document difficult to use as a reference.
: I understand that is not the primary goal of the document,
: but I see no reason that it could not serve that purpose better
: than it does.

And you ended it with:

: It seems reasonable to me that the Standard Committee would make
: the standard header declarations available in the form that they
: are presented in the Standard, but as separate files holding
: nothing but the header declarations, and references back to the
: relevant text in the Standard.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Steven T. Hatton]

news[email protected]... [...]
IIRC, Netscape began by doing much the same thing to another
company.

Hu? Netscape was created by members of the team who created NCSA Mosaic.
If you are talking about the lawsuit filed by the University of Illinois,
that was over use of the name Mosaic, and hardly constitutes a concerted
effort on the part of a few former students and researchers to put UIUC out
of business. Ironically, UIUC eventually sold Mosaic to a company called
Spyglass who in turn licensed its technology to Microsoft where it became
known as IE.

Of course, that's legal if you're not using your
monopoly power in one arena to take unfair advantage in
another. But you, of course are talking about moral objectives,
albeit divorced from good and evil...

I was speaking of the motive of the founders of Netscape Communications as
they perceived them.

[...]

Oh, I think I followed your reasoning. I just agree with Pete
that you have a slanted perspective that leads you to attribute
a disproportionate influence by Microsoft. IMO, to the extent
that the problem you see is real, it's caused mostly by the
dominance of a single architecture. Over the past 40+ years,
I've seen IBM and Digital dominate important parts of the
computer business for years at a time. And both companies
were subject to much the same vilification that Microsoft now
enjoys. Doubtless some of it was earned, by all three companies,
but much of it stems from techies who are frustrated that their
"obvious" development agendas are being ignored. Get over it.

Well, since I'm fairly new to C++, and have not had longstanding development
agendas related to C++, your comment seems rather absurd. Additionally, my
objectives and ideas are slowly manifesting themselves in many ways. You
probably have little comprehension of what, exactly, my objectives are.
The following description of an ideal development environment communicates
the kind of vision which leads to the frustration I have with the current
state of C++ development tools:

"Let me outline the program development environment I'd like for C++. First
of all, I want incremental compilation. When I make a minor change, I want
the ``system'' to note that it was minor, and have the new version compiled
and ready to run in a second.[*] Similarly, I want simple requests, such as
``Show me the declaration of this f?'' ``what fs are in scope here?''
``what is the resolution of this use of +?'' ``Which classes are derived
from class Shapen?'' and ``what destructors are called at the end of this
block?'' answered in a second.

"A C++ program contains a wealth of information that in a typlical
environment is available only to a compiler. I want that information at
the programmer's fingertips." - D&E § 9.4.4 /Beyond Files and Syntax/


[*]If things are arranged correctly I have that with GNU autotools. But M4
is an anti-language. I note that both Java and C# usually compile much
faster than a comperable sized C++ program, and usually don't propagate the
effects of a change to nearly the extent C++ programs do.


Mind you, I don't simply wait around for someone to do these things for me.
I am actively involved in efforts to create such tools. I happen to
believe the comments in D&E §9.4.3 describe problems which directly impact
the ability to provide the features outlined in §9.4.4. To a large extent,
that is the area that has been neglected because of the dominance of
Windows as a development environment. I will also observe that in both
Java and C# (as well as in C#'s C++ emulation mode, C++/CLI), the IDE
features described in §9.4.4 are much easier to provide. These *_can_* be
provided for C++, and I have solid ideas of how this can be accomplished.

The problems are not technical, they are political.

And that *still* doesn't explain your opaque editorial remark.

It had to do with the fact that we now see rapid movement toward providing
the kinds of features I am envisioning for C++, proper, using the CLI and
its heavy, built-in, mechanisms, while these same players have resisted the
simple and obvious solutions which would have been available, but for these
parties' refusal to cooperate in their realization.

The recent thread about system(); is very telling.

That doesn't tell me that the files exist.

Followed by the very explicit clarification that I had most of the files on
hand, and was willing to produce the ballance.

Uh, that's a pretty tiny part of the project you've outlined.

WTH are you talking about? As regards the files in question, I rather
clearly described a possible means of producing them by copying the entire
section of the Standard pertaining to a given Header, into a text buffer,
and deleting all portions which did not directly represent the declarations
and definitions specified for the given header. What I actually produced
goes beyond what I had originally suggested.

Got that. And you still don't understand how far you have to go
to produce a document that's not dangerously misleading.

How can this be so dangerously misleading if it basically reproduces the
same material presented in the body of the Standard with a few (clearly
commented) modifications to make it parse correctly. I sense that what you
find dangerous is not that the product might _mis_lead, you fear that it
might lead effectively.

Good luck.


Sigh. You began your very first posting on that thread with the words:

: I find the Standard document difficult to use as a reference.
: I understand that is not the primary goal of the document,
: but I see no reason that it could not serve that purpose better
: than it does.

And you ended it with:

: It seems reasonable to me that the Standard Committee would make
: the standard header declarations available in the form that they
: are presented in the Standard, but as separate files holding
: nothing but the header declarations, and references back to the
: relevant text in the Standard.

And I have since resolved that it would be a waste of my time to persue the
objective. Not because it's not a good idea, I'm more convinced than ever
that it /is/ a good idea. It's just that I see no way of communicating
what to me is obvious to people who just don't get it.

 

[E. Mark Ping]

If you don't use exception handling, it doesn't cost you anything.
"You don't pay for what you don't use."

I was under the impression that it violated the zero-overhead rule,
which caused some degree of upset at standards meetings. I checked in
"Design and Evolution of C++" and it appears that I was wrong. My
apologies for the mistake.

Like a drunk can benefit from free liquor?

This is simply a bizarre statement. Would you like to elaborate?

Like the fact they run on a virtual machine? Most of the things I find
unappealing about C# are going to be part of CLI/C++. I'd just as soon use
C# if I were going to code on a CLI.

I can only conclude that you haven't been reading the literature on
C++/CLI. After using C# professionally for 6 months I never want to
see it again, and after seeing the developments of C++/CLI I can't
imagine a .Net developer choosing C# over C++.

 

[Steven T. Hatton]

This is simply a bizarre statement. Would you like to elaborate?

The first language I used to write any meaningful code beyond what I did in
college was Java. I thought GC was great at the time because my notions of
resource management were mostly based on malloc and free. I really didn't
understand concepts such as RAII. When I learned about RAII, and the other
aspects of C++ resource management, I gained an abiding respect for them.
I believe the availability of GC for C++ will lead to sloppy resource
management, and probably to worse code structure than proper use of RAII.

I can only conclude that you haven't been reading the literature on
C++/CLI. After using C# professionally for 6 months I never want to
see it again, and after seeing the developments of C++/CLI I can't
imagine a .Net developer choosing C# over C++.

I will confess that one of the biggest objections I had to "managed
C++" (which I believe is close to the same thing) is the exclusion of the
STL. I guess if Plauger can make that work, I would not have that
objection. No, I have not been reading the literature on C++/CLI. The
whole notion of using the language extensions not available in C++, proper,
bothers me. I believe many of the objectives of the CLI are worthy, but I
don't like the means to the ends.

 

[Old Wolf]

I believe it could be a lot better, and not all that very different from
what it is now. There are certain fundamental issues that would have been
addressed in a more platform independent and comprehensive way than they
have been. Just today, I got a linking error while compiling code, and
there was no systematic means of identifying the components involved.

Have you tried 'grep' ?

The
paleolithic technology used to manage C++ source code, compile, and link
it, is woefully inadequate for the complexity of the task it is applied to.
That technology has been neglected, to a large extent, because so many
people rely on one application in one restricted and tightly controlled
environment.

Which application is that? gcc? Please be less vague in your rantings.

Have you considered Digital Mars D ? It claims to solve most
of the problems you bring up in this NG from time to time.

 

[E. Mark Ping]

The first language I used to write any meaningful code beyond what I did in
college was Java. I thought GC was great at the time because my notions of
resource management were mostly based on malloc and free. I really didn't
understand concepts such as RAII. When I learned about RAII, and the other
aspects of C++ resource management, I gained an abiding respect for them.

And this is why I think GC on C++/CLI is a good thing. Because RAII
is used to best effect. Specifically, RAII can be used to
deterministically manage lifetime, but GC handles memory management.
Or, for simple value objects which are essentially POD, you don't need
to think about memory management.

A significant portion of my work involves computational geometry in
which proper memory management is very hard (or often kludgey, no
matter what you do). GC for the value types would dramatically
simplify a lot of code.

Furthermore, Andrei Alexandrescu's work on Hazard Pointers points to
GC being a /necessary/ thing for efficient multithreading (either the
framework provides it or you create a kludge to emulate GC).

And even in C++/CLI the zero-overhead rule may be obeyed. That is,
some types can be GC while others aren't. Which raises the
possibility of using a similar method in standard C++. That way I
could allocate my edges, points, and polygons in a GC heap while you
don't have to.

It's really quit impressive. I was dubious at first, but Sutter has
convinced me that it's a good thing.

(At the same time, I have no plans to develop .Net projects either
professionally or as a hobby.)

I believe the availability of GC for C++ will lead to sloppy resource
management, and probably to worse code structure than proper use of
RAII.

This is a terrible argument. Proper use of GC will lead to better
code than traditional RAII approaches in /some/ cases--I'm convinced
of that. Poor use of any C++ feature can lead to bad/buggy code.