ravinderthakur@gmail.com writes:

> what i was suggesting was to standardize in some way the runtime
> behavior or c++ exceptions rather than the compile time behavior of
> c++.

a. The runtime behavior of C++ exceptions is already standardized.

b. From reading what you post below, that's not what you're
   suggesting.  What you're suggesting, as a few of us have mentioned
   already, seems to be a standardized C++ ABI.

  VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

> thus if that library is being developed in say , msvc then the
> exceptions thrown by that compiler cannot be catched by the compiler
> from say borland.

  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> eg. given below is the link to some of the issues forbidding the use of
> exception from real world experience:
> http://www.mactech.com/articles/mactech/Vol.15/15.01/C++ExceptionsMacOSCode/

AFAICT, the problems in that article, if they are real problems, need
to be addressed by Apple.  Maybe one way they're addressing the
problem is by waiting for Metrowerks to sell of their x86 support, and
then switching to Intel processors.  If there's only one compiler
supported on a platform, you get a de-facto standard ABI.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:

>      Yes, we hit that because exception specifications aren't taken
> seriously.
>
>      Something similar to that happens when you write
>
> struct A ();
> struct B ();
> struct C: public a, public B();
>
> void f(A&);
> void f(B&);
>
> C cinstance;
>
> f(cinstance); // ambiguous
>
>     Same ambiguity.  But because function definitions are
> taken seriously, that's considered an error.
>
>     Another "too late to fix" problem.
>
>     C++ has too many legacy problems like this.

While I certainly agree that there are some `legacy issues' with C++, may I
caution against that choice of wording?  It could be misunderstood to imply
ultimate failure.

I decided to fork this thread to focus on the idea of legacy support in
C++0X, and beyond.  How realistic are the "you're gonna break a zillion
lines of code if you require xyz" arguments?  There are at least two
separate questions here:

1) _Are_ we going to break a zillion loc?

2) So?

Please don't misinterpret my questions as positions, other than in the
rhetorical sense.  There are merits to both the conservative and the
radical approaches to language design.  It may well be that the innovations
that do survive the legacy test are superior to what they would have
otherwise been if not for the scrutiny they are subjected to.  It may also
be that many of the rejected 'innovation' really aren't all that
innovative.

 My concern is that people may be arguing against innovation on the basis of
unfounded premises.  It seems that we often take "intuitive" positions
regarding general consequences of certain proposed actions.  I am a firm
believer in the hidden wisdom of intuition.  OTOH, I know it is fallible.
A difficulty in rationally evaluating propositions formed by the intuition
is that the subject usually requires an extraordinary amount of additional
information and analysis to bring it into the category of careful science.
That's why we use our intuition in the first place.

I'm curious to know what others will offer in response to my two questions
stated above.  Yes, I know they beg the specifics.

--
"Go not to the elves for advice, for they will say both no and yes." -
Tolkien,

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
news:hvSdncsz9YoE9pveRVn-jQ@speakeasy.net...

> 1) _Are_ we going to break a zillion loc?

No.

> 2) So?

If the committee tries to do so, the revised standard will be
ignored by a significant portion of their constituency.

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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

P.J. Plauger wrote:

> ""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
> news:hvSdncsz9YoE9pveRVn-jQ@speakeasy.net...
>
>> 1) _Are_ we going to break a zillion loc?
>
> No.

It may be worth clarifying what it means to "break" existing code. This can
be more subtle than it seems.  For example, the naive understanding would
suggest it simply means that old code will not work with the (hypothetical)
new standard.  That might be dismissed by saying that people who have such
non-conforming code could simply compile it with a compiler that conforms
to the older language specification, and link to the resulting object code
when building newer versions their program.

One problem with that line of reasoning is that it fails to take into
account that object code produced by one version of a compiler may not be
compatable with that produced by another version of the compiler (or a
completely different compiler, for that matter). That means the compiler
implementors would need to provide multiple 'flavors' of C++ compatability.
Though that is already done, to some extent, it is probably not the kind of
burdon that should knowingly be placed on the implementor.  (IIRC this was
Walter Bright's objection.)

OTOH, the current Standard breaks a lot of code when implemented correctly.
I've seen this with GCC.  Often the more correctly conformming compiler
with refuse to compile code that successfully compiled under and older
version.

I've also seen occasions where other languages, or development kits, have
made rather abrupt breaks with the previous versions.  We see evidence of
this when we encounter older Java applets, and try to use them with the
newer Java implementations.  Of course such breaks with the past should
weigh the cost against the returns.  It's easier to do when the product is
new and the user base is limited.

I have the sense that C compatability could become more problematic as C
continues to evolve.  Which C should C++ be a (an approximate) supperset
of?

There is also a possibility of providing configurable behavior.  An example
might be some means of providing multiple definitions of functions of type
unexpected_handler.  There would thus be multiple "standard" ways of
handling unexpected exceptions. One of the definitions might "break"
existing code, whereas another may be compatable with such code.

>> 2) So?
>
> If the committee tries to do so, the revised standard will be
> ignored by a significant portion of their constituency.

The entire standard, or just a particular feature?  Either way, it is
certainly not an ideal situation. Ideally there will be support for both
existing code, and new features, and a reasonable transition path from use
of the existing features to use of the "new and improved" features.

My impression of C++ usage is that some good ideas have not gained
popularity due to the inertia of existing practices.  One example is the
use of error return values as opposed to the use of exceptions.  IMO, there
is rarely a situation in which retruing an error value is superior to the
use of exceptions.  Nonetheless, when existing code uses error return
values (or worse, global error flags), it is difficult to introduce
exception handling in an elegant way.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
news:CI-dnYbCl5arsZTeRVn-sA@speakeasy.net...

> P.J. Plauger wrote:
>
>> ""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
>> news:hvSdncsz9YoE9pveRVn-jQ@speakeasy.net...
>>
>>> 1) _Are_ we going to break a zillion loc?
>>
>> No.
>
> It may be worth clarifying what it means to "break" existing code. This
> can
> be more subtle than it seems.  For example, the naive understanding would
> suggest it simply means that old code will not work with the
> (hypothetical)
> new standard.  That might be dismissed by saying that people who have such
> non-conforming code could simply compile it with a compiler that conforms
> to the older language specification, and link to the resulting object code
> when building newer versions their program.
>
> One problem with that line of reasoning is that it fails to take into
> account that object code produced by one version of a compiler may not be
> compatable with that produced by another version of the compiler (or a
> completely different compiler, for that matter). That means the compiler
> implementors would need to provide multiple 'flavors' of C++
> compatability.
> Though that is already done, to some extent, it is probably not the kind
> of
> burdon that should knowingly be placed on the implementor.  (IIRC this was
> Walter Bright's objection.)

If a compiler cannot both conform to a revised C++ Standard and
support a large base of existing code, the owner of the latter
will disdain the former. Nothing subtle about that. Happens all
the time.

> OTOH, the current Standard breaks a lot of code when implemented
> correctly.
> I've seen this with GCC.  Often the more correctly conformming compiler
> with refuse to compile code that successfully compiled under and older
> version.

There was no prior C++ Standard to "break" in 1998. The C++ committee
deliberately took advantage of this one-time latitude to make any
number of changes to C++ as we knew it circa 1989 (when standardization
began), which was itself pretty much an experiment in progress. You can't
get away with that twice.

> I've also seen occasions where other languages, or development kits, have
> made rather abrupt breaks with the previous versions.  We see evidence of
> this when we encounter older Java applets, and try to use them with the
> newer Java implementations.  Of course such breaks with the past should
> weigh the cost against the returns.  It's easier to do when the product is
> new and the user base is limited.

Right. And it helps when there's no international standard involved.

> I have the sense that C compatability could become more problematic as C
> continues to evolve.  Which C should C++ be a (an approximate) supperset
> of?

That's well specified in the C++ Standard. Both the C and C++ committees
have made progress, in recent years, on reconciling the differences that
arose in the 1990s.

> There is also a possibility of providing configurable behavior.  An
> example
> might be some means of providing multiple definitions of functions of type
> unexpected_handler.  There would thus be multiple "standard" ways of
> handling unexpected exceptions. One of the definitions might "break"
> existing code, whereas another may be compatable with such code.

That, in fact, is what implementers have to do when a market exists
for multiple dialects of a language.

>>> 2) So?
>>
>> If the committee tries to do so, the revised standard will be
>> ignored by a significant portion of their constituency.
>
> The entire standard, or just a particular feature?

Ah, there's the rub. Once the community decides that 100 per cent
conformance is undesirable, then the community splinters into
groups each with its own list of deviations. Thus, the presence of
even one contentious feature dramatically weakens the effect of
the entire standard. Look what's happend because of export --
nobody even discusses all the other ways that compiler and library
vendors choose not to conform.

>                                                    Either way, it is
> certainly not an ideal situation. Ideally there will be support for both
> existing code, and new features, and a reasonable transition path from use
> of the existing features to use of the "new and improved" features.

But now you're talking about multiple dialects, and transition
plans, and other things that are both expensive and outside
the pale of standardization.

> My impression of C++ usage is that some good ideas have not gained
> popularity due to the inertia of existing practices.  One example is the
> use of error return values as opposed to the use of exceptions.  IMO,
> there
> is rarely a situation in which retruing an error value is superior to the
> use of exceptions.  Nonetheless, when existing code uses error return
> values (or worse, global error flags), it is difficult to introduce
> exception handling in an elegant way.

And the C++ Standard has next to nothing to say about this sort of
thing.

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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Steven T. Hatton"" <hattons@globalsymmetry.com> skrev i meddelandet
news:CI-dnYbCl5arsZTeRVn-sA@speakeasy.net...
> P.J. Plauger wrote:
>
>> ""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
>> news:hvSdncsz9YoE9pveRVn-jQ@speakeasy.net...
>>
>>> 1) _Are_ we going to break a zillion loc?
>>
>> No.
>
>>> 2) So?
>>
>> If the committee tries to do so, the revised standard will be
>> ignored by a significant portion of their constituency.
>
> The entire standard, or just a particular feature?

It doesn't matter much.

There are major compiler vendors that also own a gazillion loc.

What are the odds that they would

1) vote for a change that broke their own code base?

2) implement the changes in their compiler?


It belive that is what the answer "No." to the first question really
means.


Bo Persson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

hi all,

first of all a big apology for not being able to keep myself in sync
with my posting. i was a bit involved in fixing some impossible to find
bugs in some software


now back onto my original posting a few clarifications are in order:


what i was suggesting was to standardize in some way the runtime
behavior or c++ exceptions rather than the compile time behavior of
c++. to see the motivation for the same lets see how a large part of
the software development occurs:

most of the applications being developed try to reuse the existing code
and the ways of
reuse is either at the source code level or to use the code at the
binary level (aka the library file approach.).

one the end of the library vendor, he cannot throw exceptions from the
functions exposed in the library files because the runtime model of the
exceptions is not standarized across the compilers/platforms.

eg. given below is the link to some of the issues forbidding the use of
exception from real world experience:
http://www.mactech.com/articles/mactech/Vol.15/15.01/C++ExceptionsMacOSCode/


thus if that library is being developed in say , msvc then the
exceptions thrown by that compiler cannot be catched by the compiler
from say borland.

as a result the library vendor who wants to create a portable cannot
possibly use the
exception mechanism.


now at the client side the application developer just writes the code
and uses this library in his project. so as  a result a portion of his
code handles exception (eg. the one using stl ) and the other portion
of his code works on just the plain c style error handling.

i have the feeling that standardizing the runtime behaviour of
excepition handling will not give the freedom to the compiler vendors
to create the most efficent code for exceptions among other issues with
the purists. but excpetions occours only at exceptional conditions so
even if some inefficient code executes rarely, the overall performance
will not be hit. The reallity of the software development is that the
software development is that most of the projects are off  target and
are of poor quality not due to their runtime performance but due to the
large number of bugs with them.


as mentioned by experts above, i know that this standardization could
break the billions of line of existing code among but other problems
but we can also gain big benefits in the long run.


at the minimum side we can ensure that the runtime model of the
exceptions handling allows
one or many of the following:

a)ensure that the exceptions are compiler independent so that the
library created by one compiler and throwing exceptions can be used by
the applications being developed by other compiler.
 b)create a basic skeleton of the exception object that contains the
basic information that
can convey the problem to the user/developer.
c)provide the portability of exceptions for the runtime code as well
rather than just the compile time code.



thanks
rt


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" wrote:
> P.J. Plauger wrote:
>
> > ""Steven T. Hatton"" <hattons@globalsymmetry.com> wrote in message
> > news:hvSdncsz9YoE9pveRVn-jQ@speakeasy.net...
.
> It may be worth clarifying what it means to "break" existing code. This can
> be more subtle than it seems.  For example, the naive understanding would
> suggest it simply means that old code will not work with the (hypothetical)
> new standard.

If we're trying to clarify the meaning, "will not work" is a little too
vague. I'd say that a change to the standard breaks code if it makes
previously well-formed code ill-formed, makes code that used to have
legal syntax a syntax error, makes code that didn't violate any
contstraint a constraint violation, or changes code with defined
behavior into code with either undefined behavior, or with differently
defined behavior.

A standard change breaks applications (but not necessarily code), if it
requires rebuilding the application; for instance, by implicitly
requiring a change in the function calling conventions (the requirement
must be implicitly, because the standard imposes no explicit
requirements on calling conventions). For my group, this isn't a big
deal; our applications get rebuilt on a regular basis. However, for
other people it can be a prohibitively difficult task, for instance if
they don't have access to the original  source code.

> OTOH, the current Standard breaks a lot of code when implemented correctly.
> I've seen this with GCC.  Often the more correctly conformming compiler
> with refuse to compile code that successfully compiled under and older
> version.

Yes, some previous changes were considered important enough to justify
the cost of breaking some code; this was especially true if the code
that would be broken was widely considered to have been a mistake in
the first place. Keep in mind that before 1998, there wasn't a single
standard C++, just a lot of different variants with varying degrees of
mutual compatibility. In some cases (such as the iostream library), it
wouldn't have been possible to come up with a specification that didn't
break a lot of code.

> I have the sense that C compatability could become more problematic as C
> continues to evolve.  Which C should C++ be a (an approximate) supperset
> of?

The current guideline used by both the C and C++ committees is that
there should be no gratuitous incompatibilities between the two
languages. Every difference should be well-motivated. However, that
leaves room for LOTs of incompatibilities. C++ is already closer to
being a superset of C90 than it is of the current C standard; I expect
the languages to diverge more with each successive update.

> >> 2) So?
> >
> > If the committee tries to do so, the revised standard will be
> > ignored by a significant portion of their constituency.
>
> The entire standard, or just a particular feature?  Either way, it is
> certainly not an ideal situation. Ideally there will be support for both
> existing code, and new features, and a reasonable transition path from use
> of the existing features to use of the "new and improved" features.

Whenever a standard imposes requirements that are unpopular (for
instance, by breaking a lot of existing code), those requirements get
widely ignored. Every such requirement lowers the respect that people
have for the standard, increasing the liklihood that other requirements
will be ignored. If this goes far enough, the standard becomes
meaningless.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ravinderthakur@gmail.com wrote:
> hi all,
>
> first of all a big apology for not being able to keep myself in sync
> with my posting. i was a bit involved in fixing some impossible to find
> bugs in some software
>
>
> now back onto my original posting a few clarifications are in order:
>
>
> what i was suggesting was to standardize in some way the runtime
> behavior or c++ exceptions rather than the compile time behavior of
> c++. to see the motivation for the same lets see how a large part of
> the software development occurs:
>
> most of the applications being developed try to reuse the existing code
> and the ways of
> reuse is either at the source code level or to use the code at the
> binary level (aka the library file approach.).
>
> one the end of the library vendor, he cannot throw exceptions from the
> functions exposed in the library files because the runtime model of the
> exceptions is not standarized across the compilers/platforms.
>
> eg. given below is the link to some of the issues forbidding the use of
> exception from real world experience:
> http://www.mactech.com/articles/mactech/Vol.15/15.01/C++ExceptionsMacOSCode/

There's no gurantee that you can link code compiled with one compiler
to code compiled with another compiler, or even the same compiler if
different command line options are concerned. Exception handling is
just one special case of how this problem can be manifest. Argument
passing conventions, conventions for returning function values,
name-mangling schemes, and just the most basic things that can cause
incompatibilities. There can be differences in the size,
representation, and alignment of fundamental types, differences in the
padding between members of a struct, and differences in how bit fields
are implemented. Even in C, it is possible and commonplace for an
implementation to inline some or all of the implementation of one of
the standard library functions, so different compilers can use
different and imcompatible standard libraries. This is even more true
in C++, where the part of the standard library that wasn't inherited
from C are often implmented entirely in the standard headers.

The solution isn't a change to the C++ standard to specify those
details. Those details are properly platform-specific, and the solution
should be platform specific. It's up the vendors developing for each
platform to agree on and conform to platform specific conventions for
all of these issues. That has, in fact, happened in many cases.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]