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!
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell 25  2000 
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:yp********************@speakeasy.net... 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
P.J. Plauger wrote: "Steven T. Hatton" <ch********@germania.sup> wrote in message
news:yp********************@speakeasy.net...
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.
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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
Steven T. Hatton wrote: [..]
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
Victor Bazarov wrote: Steven T. Hatton wrote: [..]
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.
> The
greatest problem C++ has is its excessive reliance on one proprietary
environment.
Huh? Which environment is that?
Win32.
> 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)
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. > 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.
http://websvn.kde.org/branches/work/...er/?rev=420247
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:sI********************@speakeasy.net... > The
greatest problem C++ has is its excessive reliance on one proprietary
environment.
Huh? Which environment is that?
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
Steven T. Hatton wrote:
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.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
In article <sI********************@speakeasy.net>,
Steven T. Hatton <ch********@germania.sup> wrote: 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.
--
Mark Ping em****@soda.CSUA.Berkeley.EDU
Howard wrote:
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:sI********************@speakeasy.net... > The
greatest problem C++ has is its excessive reliance on one proprietary
environment.
Huh? Which environment is that?
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
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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
E. Mark Ping wrote: In article <sI********************@speakeasy.net>,
Steven T. Hatton <ch********@germania.sup> wrote: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?
There are certain clearly stated principles which have been used as
guidelines for two decades.
It violates the zero-overhead rule.
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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
Pete Becker wrote: Steven T. Hatton wrote:
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.
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/~ha...dard/doc/html/
It still needs a lot of cleanup due to transcription errors. But the
Doxygen turned out really nicely.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:Zc********************@speakeasy.net... Pete Becker wrote:
Steven T. Hatton wrote:
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.
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/~ha...dard/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
P.J. Plauger wrote: "Steven T. Hatton" <ch********@germania.sup> wrote in message
news:Zc********************@speakeasy.net...
Pete Becker wrote:
Steven T. Hatton wrote:
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. 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.
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.
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/~ha...dard/doc/html/
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. 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.
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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
Steven T. Hatton wrote: Pete Becker wrote:
Steven T. Hatton wrote:
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.
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.
--
Pete Becker
Dinkumware, Ltd. ( http://www.dinkumware.com)
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:pt********************@speakeasy.net... 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...
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.
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.
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.
And that *still* doesn't explain your opaque editorial remark.
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/~ha...dard/doc/html/
Well, fine, but you didn't say that then, did you?
"How shall I provide the files?"
That doesn't tell me that the files exist.
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.
Uh, that's a pretty tiny part of the project you've outlined.
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.
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
P.J. Plauger wrote: "Steven T. Hatton" <ch********@germania.sup> wrote in message
news:pt********************@speakeasy.net...
[...] 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. 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.
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. http://baldur.globalsymmetry.com/~ha...dard/doc/html/
Well, fine, but you didn't say that then, did you?
"How shall I provide the files?"
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. 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.
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. 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.
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. 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.
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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
In article <Oe********************@speakeasy.net>,
Steven T. Hatton <ch********@germania.sup> wrote: E. Mark Ping wrote:Steven T. Hatton <ch********@germania.sup> wrote:It violates the zero-overhead rule.
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."
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. 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?
This is simply a bizarre statement. Would you like to elaborate? 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.
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++.
--
Mark Ping em****@soda.CSUA.Berkeley.EDU
E. Mark Ping wrote: In article <Oe********************@speakeasy.net>,
Steven T. Hatton <ch********@germania.sup> wrote: 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?
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. 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.
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.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
Steven T. Hatton wrote: Victor Bazarov wrote:
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.
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.
In article <Wv********************@speakeasy.net>,
Steven T. Hatton <ch********@germania.sup> wrote:
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.
--
Mark Ping em****@soda.CSUA.Berkeley.EDU
Old Wolf wrote: Steven T. Hatton wrote: Victor Bazarov wrote:
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.
Have you tried 'grep' ?
That is not systematic. Often it's not even very helpful. The code base
I'm working with is on the order of 200M. There are over 300 library files
in the compiled output. I can use things such as objdump and ld -Map,
etc., but they are time consuming.
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?
I was talking about a development environment, not a compiler. I've been
using GCC to build programs for about a decade. Now I use it daily to
compile my own programs. I'm aware of its portability, and I'm aware of
the existence of an entire POSIX development environment that runs on
Windows, and supports a full X-Windows implementation. This is progress.
I hope it continues.
Please be less vague in your rantings.
hua.
Have you considered Digital Mars D ? It claims to solve most
of the problems you bring up in this NG from time to time.
I've looked at it. Currently D does not have the popularity to make D
programming a marketable skill. But what exactly do you mean by the
problems I bring up in this newsgroup?
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
P.J. Plauger wrote: P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
OK, so I bought a copy of your documentation. This is what happened to the
receipt mail:
Content analysis details: * (5.7 points, 5.0 required)
*pts rule name * * * * * * *description
---- ----------------------
--------------------------------------------------
*0.3 NO_REAL_NAME * * * * * From: does not include a real name
*1.9 ADDRESS_IN_SUBJECT * * To: address appears in Subject
*3.5 BAYES_60 * * * * * * * BODY: Bayesian spam probability is 60 to 80%
* * * * * * * * * * * * * * [score: 0.6312]
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:H-********************@speakeasy.net... P.J. Plauger wrote:
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
OK, so I bought a copy of your documentation. This is what happened to
the
receipt mail:
Content analysis details: (5.7 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
0.3 NO_REAL_NAME From: does not include a real name
1.9 ADDRESS_IN_SUBJECT To: address appears in Subject
3.5 BAYES_60 BODY: Bayesian spam probability is 60 to 80%
[score: 0.6312]
How about taking this issue up with dinkumware directly? There's no reason
to post this here.
-Howard
"Howard" <al*****@hotmail.com> wrote in message
news:tr********************@bgtnsc04-news.ops.worldnet.att.net... "Steven T. Hatton" <ch********@germania.sup> wrote in message
news:H-********************@speakeasy.net... P.J. Plauger wrote:
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
OK, so I bought a copy of your documentation. This is what happened to
the
receipt mail:
Content analysis details: (5.7 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
0.3 NO_REAL_NAME From: does not include a real name
1.9 ADDRESS_IN_SUBJECT To: address appears in Subject
3.5 BAYES_60 BODY: Bayesian spam probability is 60 to 80%
[score: 0.6312]
How about taking this issue up with dinkumware directly? There's no
reason to post this here.
Indeed. Whether or not your spam filter sucks is definitely
off topic for this newsgroup.
P.J. Plauger
Dinkumware, Ltd. http://www.dinkumware.com
P.J. Plauger wrote: "Howard" <al*****@hotmail.com> wrote in message
news:tr********************@bgtnsc04-news.ops.worldnet.att.net...
"Steven T. Hatton" <ch********@germania.sup> wrote in message
news:H-********************@speakeasy.net... P.J. Plauger wrote:
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
OK, so I bought a copy of your documentation. This is what happened to
the
receipt mail:
Content analysis details: (5.7 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
0.3 NO_REAL_NAME From: does not include a real name
1.9 ADDRESS_IN_SUBJECT To: address appears in Subject
3.5 BAYES_60 BODY: Bayesian spam probability is 60 to 80%
[score: 0.6312]
How about taking this issue up with dinkumware directly? There's no
reason to post this here.
Indeed. Whether or not your spam filter sucks is definitely
off topic for this newsgroup.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
I hear you can bit pretty low for a sense of humor on ebay.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell
In article <H-********************@speakeasy.net>,
Steven T. Hatton <ch********@germania.sup> wrote: P.J. Plauger wrote:
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
OK, so I bought a copy of your documentation. This is what happened to the
receipt mail:
Content analysis details: * (5.7 points, 5.0 required)
Stunning. You didn't whitelist the domain of a vendor you were
purchasing from?
--
Mark Ping em****@soda.CSUA.Berkeley.EDU This thread has been closed and replies have been disabled. Please start a new discussion. |
