Valentin Bonnard wrote:
>
> James Kuyper Jr. wrote:
>
> > You're the one who introduced "on top of" into this discussion.
>
> Some people here want a market of portable C++ library implementations
> (and they want the standard to support that). To implement portably the
> C++ library, you have to implement it on top of some existing library.

They are also advocating that the standard establish a strong
distinction between the language and the library. I've assumed that this
meant moving some of the functions that are currently part of the
library to the 'language' part of the dividing line; otherwise such a
split wouldn't be feasible, for precisely the reasons you've given.
Think of sizeof() and return(), which are language features, even though
they look like function calls, and const_cast<> which is a language
feature, even though it looks that a function template call.

You could split off every feature that requires implementation-specific
code to achieve efficiency into the 'language' side of the split. If you
did, the C++ 'library' could be efficiently written entirely in terms of
the C++ 'language', and not on top of some seperate C library. I think
that would be a lousy idea to establish such a distinction as part of
the standard, because it unnecessarily restricts the design freedom
currently available to C++ implementors, and also because it's not
backward compatible with the usual meaning of the term 'library'. That
doesn't mean it couldn't be done.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> James Kuyper Jr. wrote:
>
> > > > your
> > > > claim that it's impossible to implement the C++ library on top of the C
> > > > library.
> > >
> > > It isn't a claim. It's a fact that it isn't implementable
> > > that way with efficiency even close to acceptable.
>
> > am I to assume
> > that you consider your statement to apply equally well to existing
> > implementations of, for example, ARM C++?
>
> I _think_ that the C++ library as specified in the ARM
> can be entirely implemented using the C library. But I
> will check.
>
> Hint: ;-)

I've never seen the ARM, everything I know about it is what I've heard
about it in this group. I do know that a large part of what is now the
C++ standard library used to be a separate library known as STL. Is that
what you're hinting at? If so, amend my above statement to refer to ARM
C++ plus STL; in other words, the closest thing to a previous version of
the C++ standard.

In any event, I think you've finally(!) indirectly clarified that your
statement apparently applies only to standard C++, and not to
pre-standard C++. So can you now clarify what features were added in
standard C++ that have rendered impossible the same kind of efficient
implementations on top of the C library which were possible using ARM
C++ and STL?


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> writes:

 > James Kuyper Jr. wrote:
 >
 > >>> your
 > >>> claim that it's impossible to implement the C++ library on top of the C
 > >>> library.
 > >>
 > >> It isn't a claim. It's a fact that it isn't implementable
 > >> that way with efficiency even close to acceptable.
 >
 > > am I to assume
 > > that you consider your statement to apply equally well to existing
 > > implementations of, for example, ARM C++?
 >
 > I _think_ that the C++ library as specified in the ARM
 > can be entirely implemented using the C library. But I
 > will check.
 >
 > Hint: ;-)

The ARM discussed the language only and did not present a standard library.
At the time, only the C standard library, iostreams, and complex were common
to all C++ implementations.

The C++ standard library can be implemented on top of the C standard library.
The question is whether it can be done well. That again depends on your
definition of "well."

In 1983 or so, I went from a stream I/O implementation built on top of stdio
to one that used the system facilities directly. The reason was that by
implementing streams directly I got more elegant code and better performance.
Today, building iostreams on top of the C facilities is feasible, simplifies
mixed stdio and iostreams usage, and yields sub-optimal code. Whether the
overhead imposed by a "streams on top of stdio" implementation is significant
to you (as it was to me) critically depends on how you use I/O, but it clearly
puts iostreams at a disadvantage when compared to stdio.

C++ strings can be implemented using the C string functions (strcmp, strcpy,
etc.), but IMO not accaptably.

C++ allocators can be implemented using malloc/calloc/realloc/free. Whether
that is acceptable depends on the quality of the C library implementation.

The rest of the C++ is so different from what C offers that the issue is moot.

 - Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"James Kuyper Jr." <kuyper@wizard.net> writes:

>You could split off every feature that requires implementation-specific
>code to achieve efficiency into the 'language' side of the split.

The parts of the C++ standard library which are compiler-specific are
already listed in a separate section the the standard -- they're in
section 18, "Language Support Library".  These are the ones that
must be provided even by "freestanding" implementations.
Note that these parts of the library are entirely self-contained,
they do not contain any dependencies on the other parts of the library.

However, compiler dependencies are not the only ones you have to worry
about; there's also OS dependencies and perhaps also hardware dependencies.
Those parts are not so clearly separated.  Obviously I/O is likely to be
OS-dependant, but section 27 "Input/Output Library" also contains
things such as stringstreams which do not need to be OS-dependant, and
there are other aspects such as section 20.5 "Date and Time" and
section 19.3 "Error numbers" (<errno.h>) that are likely to be OS
dependent.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Fergus Henderson wrote:
>
> "James Kuyper Jr." <kuyper@wizard.net> writes:
>
> >You could split off every feature that requires implementation-specific
> >code to achieve efficiency into the 'language' side of the split.
...
> However, compiler dependencies are not the only ones you have to worry
> about; there's also OS dependencies and perhaps also hardware dependencies.

Which is why I said implementation-specific, not compiler-specific.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper Jr. wrote:

> > > your
> > > claim that it's impossible to implement the C++ library on top of the C
> > > library.
> >
> > It isn't a claim. It's a fact that it isn't implementable
> > that way with efficiency even close to acceptable.

> am I to assume
> that you consider your statement to apply equally well to existing
> implementations of, for example, ARM C++?

I _think_ that the C++ library as specified in the ARM
can be entirely implemented using the C library. But I
will check.

Hint: ;-)

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper Jr. wrote:

> You're the one who introduced "on top of" into this discussion.

Some people here want a market of portable C++ library implementations
(and they want the standard to support that). To implement portably the
C++ library, you have to implement it on top of some existing library.

> When I run into something that doesn't make sense to me, I enter
> "debugging" mode, in which I question each of the assumptions that lead
> up to the conflict.

Makes sens.

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:

> Valentin Bonnard wrote:

> > Ken Hagan wrote:

> > > To permit a healthy market in standard library implementations and
> > > compilers, we need to agree on whose job it is to implement functions
> > > like this. Does the "free-standing" versus "hosted" distinction fulfil this
> > > function? (If not, could it be twisted to do so?)
> >
> > There are several questions here:
> >
> > - it is possible to implement the C++ library resonnably
> >   efficiently on top of the C library: no

> > - it is possible to implement the hosted part of the library
> >   inefficiently on top of the C library: probably, but no one
> >   would use such a sluggish implementation
>
> I don't see any connection between those questions and the previous
> messages in this thread.

The C library was implicitly mentionned in previous
messages.

> How did the C library enter into this
> discussion?

What else would you implement the C++ library in top
of ?

> I'm not sure what you mean by "implementing on top of".

Implementing X on top of Y is implementing using X using
(only) Y interface. I am sure you know that, anyway.

> your
> claim that it's impossible to implement the C++ library on top of the C
> library.

It isn't a claim. It's a fact that it isn't implementable
that way with efficiency even close to acceptable.

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> James Kuyper wrote:
....
> The C library was implicitly mentionned in previous
> messages.

Could you cite some examples of such implicit mentions? I didn't notice
any. What was discussed is separation of the C++ language from the C++
library. At no point was any distinction made that I could notice
between the parts of the C++ library that are inherited from C, and the
parts that are new with C++.

> > How did the C library enter into this
> > discussion?
>
> What else would you implement the C++ library in top
> of ?

You're the one who introduced "on top of" into this discussion. The C++
library could be written directly in some combination of C++ and perhaps
assembly language, calling operating system-specific functions where
necessary, rather than calling functions in a separately defined C
library. There are a few cases where the C library and the C++ library
must cooperate on a level that can't be implemented that way, but that
doesn't add up to requiring (in your words below) "using (only) [the C
library] interface".

If you claim both that the C++ library must be implemented on top of the
C library, and that it can't implemented on top of the C library
efficiently, then it follows that the C++ library cannot be implemented
efficiently. There are some people who might agree with you on that, but
was that actually what you intended to say?

> > I'm not sure what you mean by "implementing on top of".
>
> Implementing X on top of Y is implementing using X using
> (only) Y interface. I am sure you know that, anyway.

Yes, but I wondered whether you might have meant some other definition,
because you made a claim that didn't make sense to me with that one.
When I run into something that doesn't make sense to me, I enter
"debugging" mode, in which I question each of the assumptions that lead
up to the conflict.

> > your
> > claim that it's impossible to implement the C++ library on top of the C
> > library.
>
> It isn't a claim. It's a fact that it isn't implementable
> that way with efficiency even close to acceptable.

I left open the possibility that you were referring only to standard C++
(of which there is as yet no fully conforming implementation), rather
than pre-standard C++. You didn't pick up that option - am I to assume
that you consider your statement to apply equally well to existing
implementations of, for example, ARM C++? That you consider the existing
and fairly popular implementations which are built on top of the C
standard library to be unacceptably inefficient? Many people have found
them useful, despite that judgment.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau <comeau@panix.com> wrote in message
news:7vccbd$jgl$1@panix3.panix.com...
> You main beef so far is that you found what seems to be a bug.
> Therefore, the issue should be in getting it solved.
> The organization concerns seem a red herring on this one.

I wish I'd never mentioned the bug! The organisation concerns are
the only reason I responded to the original question (suggesting
that some thread support be added to the library).

Yes, we can make a case for standardising threads, directories and
reference counting and a dozen smart pointers and cloning and a
GUI, just as we have accepted I/O, localisation, containers, some
maths functions (but there are sooo many more numerical routines
we could pick and choose from...)

But at some point we must say no. It would be truly tragic if the
next revision of the standard delayed some popular addition to
the language because of interminable problems with the fine detail
of some library feature that in any case may only be implementable
on  restricted class of machine (such as a desktop platform).

I'm sure we need some basis for deciding when "X" should be part
of the standard library rather than standardised separately. Having
done that, I'm confident that we'd discover the existing library is
full of stuff that "would never get in today".

Others have pointed out that the OS and CPU represent two other
"cores" (apart from the compiler) that a "lib" would have to be
separated from. That makes the problem harder than I suggested.
I'm also aware that some library vendors already offer "portable"
libraries in this regard, (and you take advantage of this) so the
marketplace for the consumer isn't as empty as it might be. As a
final nail in my own coffin, I note that the library motivated several
changes to the language, some rather late, and so I can't argue that
the language standard was delayed by library bloat, or that future
revisions to language and library are likely to be independent.

So I've lost my enthusiasm for the idea. But then someone asks

    "Wouldn't it be nice if the library included..."

and I get all panicky again.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> In article <newscache$phb9kf$mb9$1@firewall.thermoteknix.co.uk> "Ken
Hagan" <K.Hagan@thermoteknix.co.uk> writes:
> >To answer your question, I have indeed considered "writing my own"
> >std::uncaught_exception, but I have yet to pick my way through MS's
> >exception handling mechanism. (It's one of the few parts of their RTL
> >for which they don't provide any source code.) If anyone else has done
> >this, I'd be grateful for the information. If I figure it out myself at
some
> >point, I will probably try to post it here.

Greg Comeau <comeau@panix.com> wrote in message
news:7v7gi0$cqe$1@panix3.panix.com...
>
> It just might be proprietary so consider what you are doing.

I believe I am permitted to reverse engineer for the purposes of
compatibility. If my programs need a std::uncaught_exception
that gives the correct answer, and the vendor produces half a
dozen releases without providing one, then I think I'm entitled
to do as much reverse engineering as I like to solve the problem
myself.

If I'm right, and it is legal for me to acquire the information, then
is it not equally legal to pass it on to others who have the same
need?
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau <comeau@panix.com> wrote in message
news:7v9pr7$qdp$1@panix3.panix.com...
> In article <newscache$k87bkf$h5g$1@firewall.thermoteknix.co.uk> "Ken
Hagan" <K.Hagan@thermoteknix.co.uk> writes:
> >I'm just suggesting that those parts of the library which
> >cannot be written in portable C++ should be declared "part of the
> >language" (intrinsic functions) and everything else should be declared
> >"part of the library".
>
> Nothing practical is gained from this.
>
I disagree. At present it is not possible to produce a portable
implementation of the standard library. You have to restrict
yourself to one or more specific compilers. Equally it is not
possible to produce a C++ compiler without also shipping
the library.

This is a practical benefit if (say) a vendor for an obscure
architecture only has to write the compiler and can legitimately
say "We are too small to take on the burden of maintaining a
library as well -- use someone else's."
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$dp1dkf$gbn$1@firewall.thermoteknix.co.uk> "Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:
>Greg Comeau <comeau@panix.com> wrote in message
>news:7v9pr7$qdp$1@panix3.panix.com...
>> In article <newscache$k87bkf$h5g$1@firewall.thermoteknix.co.uk> "Ken
>Hagan" <K.Hagan@thermoteknix.co.uk> writes:
>> >I'm just suggesting that those parts of the library which
>> >cannot be written in portable C++ should be declared "part of the
>> >language" (intrinsic functions) and everything else should be declared
>> >"part of the library".
>>
>> Nothing practical is gained from this.
>>
>I disagree. At present it is not possible to produce a portable
>implementation of the standard library.

Making the seperation above won't necessarily give it either.
And by doing so, you loose possible optimizations and other things.

>You have to restrict yourself to one or more specific compilers.

But this is not surprising.   !?!?!?

>Equally it is not possible to produce a C++ compiler without
>also shipping the library.

I'm not sure what these words means.

FWIW, Comeau C++ ships w/o a full lib (though we do ship
uncaught_exeption) and anybody who needs alternative permutations
to fit their circumstances should consider a custom port of some
sort with us.  And we've done so.  Why is this "not possible"?

>This is a practical benefit if (say) a vendor for an obscure
>architecture only has to write the compiler and can legitimately
>say "We are too small to take on the burden of maintaining a
>library as well -- use someone else's."

Is this hypothetical or real?  Again, in your reasoning,
Comeau C++ would benefit from this approach accto you as
we currently suggest folks use somebody else's SL,
so why don't I agree with you? :)

You main beef so far is that you found what seems to be a bug.
Therefore, the issue should be in getting it solved.
The organization concerns seem a red herring on this one.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote in message ...

>I disagree. At present it is not possible to produce a portable
>implementation of the standard library. You have to restrict
>yourself to one or more specific compilers. Equally it is not
>possible to produce a C++ compiler without also shipping
>the library.
>
>This is a practical benefit if (say) a vendor for an obscure
>architecture only has to write the compiler and can legitimately
>say "We are too small to take on the burden of maintaining a
>library as well -- use someone else's."

Is <math.h> the responsibility of the compiler vendor or of the library
writer?  It is certainly possible to write a portable <math.h>, but if the
hardware has efficient support for exp(), you would not want to use the
portable version.

What about <stdlib.h>?  I can implement malloc() in terms of a suitably
aligned static array of characters.  For all practical purposes I can do
that portably (with a union that has "universal" alignment).  However on
most systems you'll want a different implementation.

You also have to worry about names.  Right now the standard reservers some
names to the "implementation" and others to the program.  To be safe you'd
need to carefully partition the implementation's name space between compiler
and library vendors.

None of these issues are insurmountable.  However, I expect that we'll
continue to muddle along with compiler vendors developing, selecting, or
recommending a particular library implementation, and library vendor's
selling to the compiler vendor and sometimes directly to the developer.

A portable library implementation is probably an excellent place to start
when porting to a new platform.  In most cases I'd expect to want to do some
tuning to get effective use out of both the platform and the library.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote:
>
> Greg Comeau <comeau@panix.com> wrote in message
> news:7v9pr7$qdp$1@panix3.panix.com...
> > In article <newscache$k87bkf$h5g$1@firewall.thermoteknix.co.uk> "Ken
> Hagan" <K.Hagan@thermoteknix.co.uk> writes:
> > >I'm just suggesting that those parts of the library which
> > >cannot be written in portable C++ should be declared "part of the
> > >language" (intrinsic functions) and everything else should be declared
> > >"part of the library".
> >
> > Nothing practical is gained from this.
> >
> I disagree. At present it is not possible to produce a portable
> implementation of the standard library. You have to restrict
> yourself to one or more specific compilers.

For that matter, you cannot produce a portable C library. The I/O
implementation depends on the OS. It is possible to write the
C I/O library in terms of fundamental functions like open, close,
read, write, and seek -- but those functions are not portable.
In addition, the library headers must provide (for example) typedefs
for size_t and ptrdiff_t that depend on the compiler.
That is, the headers must agree with what the compiler does.

In a previous job, I provided a portable standard C library to
various compiler vendors. A small amount of customization was
required to deal with those points.

You have additional areas in C++ where the compiler and library
must agree. For example, the definition of type_info in header
<typeinfo> must agree with what the compiler generates. The
standard exceptions must also agree with what the compiler
generates.

> Equally it is not
> possible to produce a C++ compiler without also shipping
> the library.

The compiler and library must agree in the areas where they
overlap.

> This is a practical benefit if (say) a vendor for an obscure
> architecture only has to write the compiler and can legitimately
> say "We are too small to take on the burden of maintaining a
> library as well -- use someone else's."

That situation exists today, for non-obscure architectures.
Dinkumware and Rogue Wave supply standard C++ libraries for
major compiler vendors, including Microsoft, Sun, and Borland.
The libraries require some customization for the compiler and
OS. That much is unavoidable.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote:

> I disagree. At present it is not possible to produce a portable
> implementation of the standard library. You have to restrict
> yourself to one or more specific compilers. Equally it is not
> possible to produce a C++ compiler without also shipping
> the library.

Let L1 be the part of the C++ library that can be portably
implemented, and let L2 be the complement. Then:

1) the library is divided
2) L1 can be shiped by vendors

But
3) L2 cannot be shiped, but, this is no worse than the
   situation we have today.

Happy now ?

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

> I'm not sure what you mean by "implementing on top of". Most of the
> obvious interpretations I can think of seem to be inconsistent with your
> claim that it's impossible to implement the C++ library on top of the C
> library.
>
> At least in the pre-standard days, many versions of C++ were simply
> pre-compilers for C, and STL was written using ordinary C++ code - thus,
> many C++ library functions either were C library functions, or wrappers
> for them, or involved calls to them. That covers pretty much the full
> range of possible interpretations I can think of for "implementing on
> top of". Are you saying that standard C++ is so different from
> pre-standard C++ that such implementations are no longer possible?

You haven't meantioned the iostream/locale part of the library.  It
can be written in C++, but I don't believe it's possible to write an
acceptable implementation using only portable C++ and only the public
interface of the standard C library.  The hard parts are named
locales, std::ios_base::sync_with_stdio(), and iostream initialization.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote:
....
> I believe I am permitted to reverse engineer for the purposes of
> compatibility. If my programs need a std::uncaught_exception
> that gives the correct answer, and the vendor produces half a
> dozen releases without providing one, then I think I'm entitled
> to do as much reverse engineering as I like to solve the problem
> myself.

Whether or not you believe it's right, your software license agreement
may prohibit such activities. If you don't like those conditions you
have three choices: complain to the vendor and try to renegotiate the
license conditions, buy someone else's software with a more lenient
license (make sure your current vendor knows that this is the reason
you're switching), or violate the license and take the risk of being
caught and punished.

Also, you'll need some luck on the reverse engineering. You're going to
have to understand exactly how the compiler implements exceptions. If it
were easy to get std::uncaught_exception() right, your vendor would
probably have done so. If the exception-handling mechanism wasn't
designed with std::uncaught_exception() in mind, there's a good chance
that it's not possible to implement it except by re-designing the
mechanism.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$yo1dkf$abn$1@firewall.thermoteknix.co.uk> "Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:
>Greg Comeau <comeau@panix.com> wrote in message
>news:7v7gi0$cqe$1@panix3.panix.com...
>> It just might be proprietary so consider what you are doing.
>
>I believe I am permitted to reverse engineer for the purposes of
>compatibility. If my programs need a std::uncaught_exception
>that gives the correct answer, and the vendor produces half a
>dozen releases without providing one, then I think I'm entitled
>to do as much reverse engineering as I like to solve the problem
>myself.
>
>If I'm right, and it is legal for me to acquire the information, then
>is it not equally legal to pass it on to others who have the same
>need?

I'm not a lawyer, but suspect 'no' on both counts (being allowed
to reverse it, and being allowed to pass it along).  Anyway, we've
gone off topic I think.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$rdb7kf$yfo$1@firewall.thermoteknix.co.uk> "Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:
>It isn't clear whether something like std::uncaught_exception is
>implemented by the compiler vendor or the library vendor.

Often I would expect it to at least be "talking" with the compiler.
I'm curious as to what is the significance of the difference to you?
Are you writing your own?

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

My interest is as a potential customer of the library separately from the
compiler. As an MSVC user, I'm using the library that Dinkumware gave
to MS, which implements uncaught_exception as "return false". When I
discovered this, I assumed that DW didn't have access to the relevant
info and it was MS's job to implement that function. Whatever the reason,
it got lost between the cracks.

To permit a healthy market in standard library implementations and
compilers, we need to agree on whose job it is to implement functions
like this. Does the "free-standing" versus "hosted" distinction fulfil this
function? (If not, could it be twisted to do so?)

To answer your question, I have indeed considered "writing my own"
std::uncaught_exception, but I have yet to pick my way through MS's
exception handling mechanism. (It's one of the few parts of their RTL
for which they don't provide any source code.) If anyone else has done
this, I'd be grateful for the information. If I figure it out myself at some
point, I will probably try to post it here.

Greg Comeau wrote in message <7v4lcb$im6$1@panix3.panix.com>...
>In article <newscache$rdb7kf$yfo$1@firewall.thermoteknix.co.uk> "Ken Hagan"
<K.Hagan@thermoteknix.co.uk> writes:
>>It isn't clear whether something like std::uncaught_exception is
>>implemented by the compiler vendor or the library vendor.
>
>Often I would expect it to at least be "talking" with the compiler.
>I'm curious as to what is the significance of the difference to you?
>Are you writing your own?
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote:

> My interest is as a potential customer of the library separately from the
> compiler. As an MSVC user, I'm using the library that Dinkumware gave
> to MS, which implements uncaught_exception as "return false". When I
> discovered this, I assumed that DW didn't have access to the relevant
> info and it was MS's job to implement that function. Whatever the reason,
> it got lost between the cracks.

Anyway, you buy the compiler from MS, so it's MS job to ensure that
there is a working uncaught_exception() function in the library --
and more generally a working library. In order to do that, they may
delegate part of the job, but then it's their responsabillity to
ensure that all parts are well integrated.

Let's say that I am part of a team of three programmers and I write
a program together with two other programmers, and that you find a bug
in the program (highly unlikely, but let's assume so): would you ask
us who wrote the faulty function or would you just send the bug-report
to the team address and let us figure out who is guilty ?

Let's say that we implement a word processor in C++. Do you expect
the C++ standard to define who in the team is responsible for the
file module, and who has to write the GUI stuff ?

> To permit a healthy market in standard library implementations and
> compilers, we need to agree on whose job it is to implement functions
> like this. Does the "free-standing" versus "hosted" distinction fulfil this
> function? (If not, could it be twisted to do so?)

There are several questions here:

- it is possible to implement the C++ library resonnably
  efficiently on top of the C library: no

- it is possible at all: no

- it is possible to implement the hosted part of the library
  inefficiently on top of the C library: probably, but no one
  would use such a sluggish implementation

BTW, I still do understand what you want (except that you want
to make the life of library vendors simplier).

--

Valentin Bonnard
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote in message
news:3816F2C7.32FA@wanadoo.fr...
> Anyway, you buy the compiler from MS, so it's MS job to ensure that
> there is a working uncaught_exception() function in the library --
> and more generally a working library. In order to do that, they may
> delegate part of the job, but then it's their responsabillity to
> ensure that all parts are well integrated.

Agreed. I didn't mean to cast any blame on Dinkumware.

> There are several questions here:
>
> - it is possible to implement the C++ library resonnably
>   efficiently on top of the C library: no
>
> - it is possible at all: no
>
> - it is possible to implement the hosted part of the library
>   inefficiently on top of the C library: probably, but no one
>   would use such a sluggish implementation
>
> BTW, I still do understand what you want (except that you want
> to make the life of library vendors simplier).

I think you've mis-understood me. I'm not concerned with the C
library at all. I'm just suggesting that those parts of the library which
cannot be written in portable C++ should be declared "part of the
language" (intrinsic functions) and everything else should be declared
"part of the library".

Then, we can split the standard into two. A compliant compiler need
not include a library and a compliant library would work on any compiler.
I suggest this partly because I think it would result in better products
and more choice for users, partly because I think it looks pretty, and (in
the context of this thread) because it sets a precedent for standardising
libraries separately from the core language.

That, in turn, means we can handle requests of the form "Please could
the standard library do this." by saying "Standardise it as a separate
library. That avoids upsetting the minimalists, and will probably be less
work that trying to get the support of the entire C++ community."
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> Ken Hagan wrote:
...
> > To permit a healthy market in standard library implementations and
> > compilers, we need to agree on whose job it is to implement functions
> > like this. Does the "free-standing" versus "hosted" distinction fulfil this
> > function? (If not, could it be twisted to do so?)
>
> There are several questions here:
>
> - it is possible to implement the C++ library resonnably
>   efficiently on top of the C library: no
>
> - it is possible at all: no
>
> - it is possible to implement the hosted part of the library
>   inefficiently on top of the C library: probably, but no one
>   would use such a sluggish implementation

I don't see any connection between those questions and the previous
messages in this thread. How did the C library enter into this
discussion? No one else has mentioned it, directly or indirectly.

I'm not sure what you mean by "implementing on top of". Most of the
obvious interpretations I can think of seem to be inconsistent with your
claim that it's impossible to implement the C++ library on top of the C
library.

At least in the pre-standard days, many versions of C++ were simply
pre-compilers for C, and STL was written using ordinary C++ code - thus,
many C++ library functions either were C library functions, or wrappers
for them, or involved calls to them. That covers pretty much the full
range of possible interpretations I can think of for "implementing on
top of". Are you saying that standard C++ is so different from
pre-standard C++ that such implementations are no longer possible?
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$phb9kf$mb9$1@firewall.thermoteknix.co.uk> "Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:
>Greg Comeau wrote in message <7v4lcb$im6$1@panix3.panix.com>...
>>In article <newscache$rdb7kf$yfo$1@firewall.thermoteknix.co.uk> "Ken Hagan"
><K.Hagan@thermoteknix.co.uk> writes:
>>>It isn't clear whether something like std::uncaught_exception is
>>>implemented by the compiler vendor or the library vendor.
>>
>>Often I would expect it to at least be "talking" with the compiler.
>>I'm curious as to what is the significance of the difference to you?
>>Are you writing your own?
>
>My interest is as a potential customer of the library separately from the
>compiler. As an MSVC user, I'm using the library that Dinkumware gave
>to MS, which implements uncaught_exception as "return false". When I
>discovered this, I assumed that DW didn't have access to the relevant
>info and it was MS's job to implement that function. Whatever the reason,
>it got lost between the cracks.

Then that's an issue for MS and DW to figure out.
And that's the way it should be.  Let the marketplace decide.
The Q is not who did what, but is "blah" working ok.

>To permit a healthy market in standard library implementations and
>compilers, we need to agree on whose job it is to implement functions
>like this.

No, the only healthy way is to let the vendors figure it out.
The problem isn't who is doing what, the final issue is a quality of
implementation issue of the combined offering.

For instance, if MS did the lib themselves and still implemented
uncaught_exception that way, what difference would it make in the
grand scheme of things?  I mean, it's still implementated that way
and so still needs to eventually be addressed no matter what.

>Does the "free-standing" versus "hosted" distinction fulfil this
>function? (If not, could it be twisted to do so?)

I don't see how.  Now do I see why one would want to.

>To answer your question, I have indeed considered "writing my own"
>std::uncaught_exception, but I have yet to pick my way through MS's
>exception handling mechanism. (It's one of the few parts of their RTL
>for which they don't provide any source code.) If anyone else has done
>this, I'd be grateful for the information. If I figure it out myself at some
>point, I will probably try to post it here.

It just might be proprietary so consider what you are doing.
Anyway, like I said above, I would expect it to be "talking" with
something else, therefore, communicaiton will need to be established
with something.  Whether a vendor publishes that or not is up to them,
and I think it is as it should be (you may argue I'm biased, but heck,
this is just the marketplace at work, what else is new?).

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$k87bkf$h5g$1@firewall.thermoteknix.co.uk> "Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:
>I'm just suggesting that those parts of the library which
>cannot be written in portable C++ should be declared "part of the
>language" (intrinsic functions) and everything else should be declared
>"part of the library".

Nothing practical is gained from this.

>Then, we can split the standard into two. A compliant compiler need
>not include a library and a compliant library would work on any compiler.
>I suggest this partly because I think it would result in better products
>and more choice for users, partly because I think it looks pretty, and (in
>the context of this thread) because it sets a precedent for standardising
>libraries separately from the core language.

Vendors can already do this (look at the example you already raised,
we do the same too).  Remember too, compliant needs to be in a context.

>That, in turn, means we can handle requests of the form "Please could
>the standard library do this." by saying "Standardise it as a separate
>library. That avoids upsetting the minimalists, and will probably be less
>work that trying to get the support of the entire C++ community."

You can already propose to standardize something independently
through a number of mechanisms. ??????

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]