<AllanW@my-dejanews.com> wrote:
>In article <35B47A6C.D3E168FC@acm.org>,
>> Valentin Bonnard wrote:
>> > Given that it's nearly trivial to implement a better linker,
>> > I think that the embeded world needs a goods linkers, not
>> > subsets.
>
>What makes you say that "it's nearly trivial" to implement a better
>linker?

Because it has been demonstrated, for the g++ linker, and it took
a few days.  Of course that was not a linker written from scratch,
but a modification to an existing linker.

>  * a new linker that completely conforms to the new C++ model, and
>    also solves all of the problems mentioned in this thread, which
>    most of us (I think) agree is a *lot* of work.

For some people and for some problems a few days seems like "a *lot*
of work".  Compared to extracting, standardizing, and maintaining
a separate version of the library, it seems to me "nearly trivial".

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/


[ 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 <6p58r3$4g9$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:

    [...]
> I think we've demonstrated in this thread that you *can* write EC++
> code which is also C++ code.  Doing so means that once the linkers are
> available, you won't need EC++ anymore.  But just because you *can* do
> something, or even if you *should* do something, doesn't mean that you
> *will* do something.  There will be a high percentage of EC++ programs
> that do not attempt compliance with C++.  Still other programs will
> attempt C++ compliance, but since the programs will be tested and
> debugged with EC++ compilers, they may well have C++ errors that won't
> be discovered until they are ported to C++ or even later.  You can tell
> your programmers to test every line of code in two environments,
> including one that won't be used for quite some time, but as the project
> deadline grows near, this will be the first thing that's dropped...

I think that one of the points of EC++ is that any program that is a legal
EC++ program can be turned into a legal C++ program at the drop of a
"using namespace std".  You cannot write EC++ programs that are not
C++ compiant.

> Perhaps there should be two versions of C++: A "normal" one, and an
> "embedded" one.  Not having done any embedded programming work, I can't
> say this would be bad.  After all, C++ is a "general purpose"
> programming language, and embedded programmers certainly have their
> share of "special purpose" problems.
>
> But go in with your eyes open.  Ask yourself if you want C++ and
> Embedded C++ to be two distinct languages 10 years from now.  Because
> like government committees, once you create a standard it is almost
> impossible to get rid of it.

It depends on what you mean by "standard".  I've already stated that
I DON'T want EC++ to become an ISO standard.  But there are many other
levels of standardization -- at the other extreme, CFront was a defacto
standard, but it disappeared completely, and most code written for
later versions of CFront (with templates) would not be considered legal
C++ today.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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              ]

Michael Ball <michael.ball@Eng.Sun.COM> writes:

>Valentin Bonnard wrote:
>
>> Given that it's nearly trivial to implement a better linker,
>> I think that the embeded world needs a goods linkers, not
>> subsets.
>
>Sorry, but in real life, for real systems, implementing a better linker
>is very far from trivial.  It's the one component that everyone has
>to use, and it absolutely must maintain a stable interface.

Yes, the main issue is not so much implementing a better linker;
rather, the difficulty is in making the changes to the object file format,
the shared object file or DLL format, and the object library file format
that would be required to make the linker better -- and then updating all
the tools that parse these files to support the new extensions.
Thus improvements that can be made without changing the object file
formats are much easier than those that do require such changes.
It is therefore unfortunate that eliminating unused virtual functions
apparently can't be done with extensions to the object file format.

--
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<fjh@cs.mu.OZ.AU> wrote:
>Michael Ball <michael.ball@Eng.Sun.COM> writes:
>
>>...  For real systems, implementing a better linker
>>is very far from trivial.  It's the one component that everyone has
>>to use, and it absolutely must maintain a stable interface.
>
>Yes, the main issue is not so much implementing a better linker;
>rather, the difficulty is in making the changes to the object file format,
>the shared object file or DLL format, and the object library file format
>that would be required to make the linker better -- and then updating all
>the tools that parse these files to support the new extensions.
>Thus improvements that can be made without changing the object file
>formats are much easier than those that do require such changes.
>It is therefore unfortunate that eliminating unused virtual functions
>apparently can't be done with extensions to the object file format.

Sorry, I don't agree that changes to the object file format are
necessary.  In particular, the initial Cygnus implementation did
not depend on a change to the object file format.  It relied on
the linker recognizing certain patterns in generated symbol names.
While this is clumsier than using different symbol and reference
types, it does the job.

Furthermore, no changes to shared-object/DLL formats would help,
because the optimization is only usefully performed during static
linking.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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 <35B47A6C.D3E168FC@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
> Valentin Bonnard wrote:
> >
> > Now what is the cost of a dumb linker ? Well, every program
> > using iostream will get all the virtual functions of more
> > than 20 facets, that is about 110 virtual functions.

Let's see:  Each of the facets has 5.492 virtual functions, right?
So 5.492 times 20...  carry the 0...  adjust my decimal point...
no, that can't be right; let's whip out the 'ol calculator...
    insert(new batteries);
Set it for decimal...  5.492 times 20 equals... ah, here it is:
109.84.  Round off, it's just below 110, call it about 110.

Yep, that's what I get!  :^)

> > So my conclusion is:
> > - without uncalled virtual removal, new iostream is unusable
> >   in tiny environements
> > - with such a thing, you get a small time and space hit, but
> >   IMO remain usable
> >
> > Given that it's nearly trivial to implement a better linker,
> > I think that the embeded world needs a goods linkers, not
> > subsets.

What makes you say that "it's nearly trivial" to implement a better
linker?  If it's that easy, I encourage you to do it yourself -- quickly.
Start selling it by the end of August, and you'll make yourself a mint.

> "Aside from that, Mrs. Lincoln, how did you like the play?" You can't
> just assume away the hardest part of the solution.

No, you can't.  But which is the hardest part:

  * a new, and not-quite compatible super-subset of C++, which will NOT
    take 5 years because it can mimic the C++ model, and it's slightly
    simpler, but let's face it this is not an overnight proposition
    either; or

  * a new linker that completely conforms to the new C++ model, and
    also solves all of the problems mentioned in this thread, which
    most of us (I think) agree is a *lot* of work.

It seems to me that these two tasks have a similar order of complexity.
Now, add the fact that the first one is "stopgap."  Not in any sense
that implies unprofessionalism, but simply because the better linkers
realistically must be created anyway, and also because when these
linkers are widely available the reasons for creating EC++ will no
longer be valid.

But if the EC++ standard DOES exist before better linkers are widely
available, then it becomes permenant -- it will NOT go away just because
new linkers solve the C++ problems.  If EC++ exists, then there will be
a body of code that requires it -- and requires "backward compatibility."
Indeed, it is likely that the needs of embedded programmers will evolve,
requiring a second version of the EC++ standard, and a third version, ...

I think we've demonstrated in this thread that you *can* write EC++
code which is also C++ code.  Doing so means that once the linkers are
available, you won't need EC++ anymore.  But just because you *can* do
something, or even if you *should* do something, doesn't mean that you
*will* do something.  There will be a high percentage of EC++ programs
that do not attempt compliance with C++.  Still other programs will
attempt C++ compliance, but since the programs will be tested and
debugged with EC++ compilers, they may well have C++ errors that won't
be discovered until they are ported to C++ or even later.  You can tell
your programmers to test every line of code in two environments,
including one that won't be used for quite some time, but as the project
deadline grows near, this will be the first thing that's dropped...

Perhaps there should be two versions of C++: A "normal" one, and an
"embedded" one.  Not having done any embedded programming work, I can't
say this would be bad.  After all, C++ is a "general purpose"
programming language, and embedded programmers certainly have their
share of "special purpose" problems.

But go in with your eyes open.  Ask yourself if you want C++ and
Embedded C++ to be two distinct languages 10 years from now.  Because
like government committees, once you create a standard it is almost
impossible to get rid of it.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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              ]

Bradd W. Szonye wrote:

> I suspect that the Watcom dead-virtual-stripping would improve the final
> size of programs which use iostreams without using all the facilities of
> iostreams and locales.

Yes

> the compiler might need to detect that the program does not
> change the locale at all in order to link a version of the iostream
> library that has use of the C locale hardwired into the routines.

Ok, let's assume for the moment that no one will ever do that.

So for every 'out << 2.', we have (assuming that no cooperation
between the library implementor and the compiler implementor takes
place):

[ I am not a library implementor, maybe I missed something.
  Please tell me. ]

 bool failed = use_facet< num_put<charT,
      ostreambuf_iterator<charT,traits> > >(getloc()).
   put(*this, *this, fill(), 2). failed();

function    bound        time inside the function

operator<<  statically   zero
getloc()    statically   zero
use_facet   statically   table lookup, fast
put         statically   zero
do_put      dynamically  long, needs to format the number
                         uses the ios_base flags

If you compare to traditionnal iostream, you have:

operator<< statically    long, needs to format the number

What's the difference ?

The new iostream:
- is more flexible
- implementation is more complicated (more layers)
- impose one dynamic dispatch and one table lookup
- do_put instead of operator<<

Is do_put slow and big ? Well, it's defined in term
of printf but a library with user who care about speed
or time won't call printf. Instead, it will do the work
directly (perhaps copy-pasting parts of printf code).

To determine the decimal point, it will use numpunct:

getloc()      statically   zero
use_facet     statically   table lookup, fast
decimal_point statically   zero
do_decimal_point dynamically zero

same for grouping, thousands_sep

Difference in time between new and old iostream for
'out << 2.' :

4 function calls with dynamic dispatch
2 table lookups
formating is a bit more complicated
more flexible

Doesn't look like a terrible cost (but still a cost).

Is the flexibillity usefull ? On most programs running
on a PC, yes, clearly. On an embeded processor ? Some
people answer no, I answer sometimes: I have used a
video camera which supported a UI with more than 10
languages.

Code size cost:

3 trivial virtual functions
2 vtables
use_facet code

Now what is the cost of a dumb linker ? Well, every program
using iostream will get all the virtual functions of more
than 20 facets, that is about 110 virtual functions.

So my conclusion is:
- without uncalled virtual removal, new iostream is unusable
  in tiny environements
- with such a thing, you get a small time and space hit, but
  IMO remain usable

Given that it's nearly trivial to implement a better linker,
I think that the embeded world needs a goods linkers, not
subsets.

> I agree that compiling "slim" iostream libraries is desirable, but the
> cost and politics involved in actually making it *work* are probably
> prohibitive at worst, slow at best. The easiest way to get a minimal IO
> library is to write it as a seperate subset library, linked in by
> explicit user request. Yes, it's an intrusive method (from the user's
> point of view), but probably the most cost-effective one from
> everybody's point of view.

It's acceptable as a short term solution when you don't have
a better solution (better compiler and linker). I don't want
it as a standard.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ 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:
>
> Now what is the cost of a dumb linker ? Well, every program
> using iostream will get all the virtual functions of more
> than 20 facets, that is about 110 virtual functions.
>
> So my conclusion is:
> - without uncalled virtual removal, new iostream is unusable
>   in tiny environements
> - with such a thing, you get a small time and space hit, but
>   IMO remain usable
>
> Given that it's nearly trivial to implement a better linker,
> I think that the embeded world needs a goods linkers, not
> subsets.

"Aside from that, Mrs. Lincoln, how did you like the play?" You can't
just assume away the hardest part of the solution.

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

Valentin Bonnard wrote:

> Given that it's nearly trivial to implement a better linker,
> I think that the embeded world needs a goods linkers, not
> subsets.

Sorry, but in real life, for real systems, implementing a better linker
is very far from trivial.  It's the one component that everyone has
to use, and it absolutely must maintain a stable interface.

The problems aren't technical in the small, they are both technical
and logistical and they are very much in the large.  they occur in
the supported environment, not directly in the linker.
It gets even more complicated when runtime linking is included in
the picture.

Linker changes must be made incrementally and very carefully.  Most
programmers never realize this because there are only a small
number of programmers in the world who ever change linkers.

Now if you are defining a new environment from scratch,
the situation is rather different, but most of us are not doing
that at all.

-Mike Ball-
Sun MicroSystems.
---
[ 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              ]