Topic: STL Template collections are useless in a large project
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1997/10/01 Raw View
Dominic North <Dominic.North@ping.be> writes:
|> In article <60lu6e$7d6@mulga.cs.mu.OZ.AU>, Fergus Henderson wrote:
|> > No, I mean 2nd Ed. See section 8.3.1, page 261:
|> >
|> > "... the scheme is type safe ...
|> > type safety is achieved without the expenditure of time or space
|> > because the access functions ... are trivial inline functions ...
|> > there is no replication of code ..."
|> >
|> > The basic idea is to define private collection classes using `void *',
|> > and then provide public type-safe inline template interfaces to them.
|> >
|>
|> Well I remembered that bit, but did not see it of particular application
|> to the STL. Of course, you can define vector<void*>, deque<void*> and so
|> on, but that doesn't help you with different types of map key, strings
|> etc. Unfortunately, as far as I can see, the worst bloaters in the STL,
|> at least of those that I have used so far in the GNU implementation, are
|> (in descending order) string and map!
While I've not tried to use this particular technique in the case of
STL, I have used it in earlier container classes. It's not that
difficult (although STL-like iterators might be slightly harder), but in
the end, I found that it wasn't worth it, at least for me. In practice,
it is rare for me to instantiate a given container over more than one or
two distinct types.
If string is the culprit in the GNU implementation, it sounds far more
like a case of too many inline functions, rather than anything directly
related to templates. Of course, maybe they made all of the functions
inline because the template mechanism doesn't handle non-inline
functions very well. This is a particularity of one particular template
implementation, however, and is certainly not the case with the other
compilers (Sun, HP) that I have used.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
I'm looking for a job -- Je recherche du travail
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: ark@research.att.com (Andrew Koenig)
Date: 1997/10/01 Raw View
In article <342EDF1B.1149@pratique.fr> bonnardv@pratique.fr writes:
> Clive Bluston <clive@emultek.co.il> writes:
> > To be more specific, if ten programmers are working on a single
> > project and they want to use collections freely in their code, the
> > executable will end up being FAR bigger than it need be.
> Well, some compiler writer simply don't consider code size
> important, so they won't do anything about it (until you
> complain to them ?).
> The first thing to do is to check if the same template
> instantiate twice (under the inclusion model) is only written
> once in the executable (just as inline functions, redondants
> copies must be suppressed); otherwise, the compiler is certainly
> non-conformant.
And the next thing to check is how much it really costs.
It is hard for me to believe that the amount of code generated
by a well designed container, even if all that code is laid down
for each distinct type with which that container is used, is
a major part of the total amoutn of code in an application.
Containers just aren't that big.
--
--Andrew Koenig
ark@research.att.com
http://www.research.att.com/info/ark
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Marcelo Cantos <marcelo@janus.mds.rmit.edu.au>
Date: 1997/10/02 Raw View
fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
> Valentin Bonnard <bonnardv@pratique.fr> writes:
>
> >void foo () { cout << 1; }
> >void bar () { cout << 1; }
> >
> >Would generates:
> >
> >void foo_bar () { cout << 1; }
> >foo = foo_bar
> >bar = foo_bar
> >
> >However, I don't know if it's conformant (what
> >if &foo == &bar ?).
>
> It's not, but the linker can easily generate
>
> foo: jmp bar
>
> which is almost as good.
Or maybe:
foo: nop
bar: ...
Cheers,
Marcelo
--
______________________________________________________________________
Marcelo Cantos, Research Assistant __/_ marcelo@mds.rmit.edu.au
Multimedia Database Systems Group, RMIT / _ Tel 61-3-9282-2497
L2/723 Swanston St, Carlton VIC 3053, Aus/ralia ><_>Fax 61-3-9282-2490
Acknowledgements: errors - me; wisdom - God; sponsorship - RMIT
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Jean-Louis Leroy <jll@skynet.be>
Date: 1997/10/02 Raw View
In article <EHEAM0.JIq@research.att.com>, Andrew Koenig wrote:
> It is hard for me to believe that the amount of code generated
> by a well designed container, even if all that code is laid down
> for each distinct type with which that container is used, is
> a major part of the total amoutn of code in an application.
> Containers just aren't that big.
There's a twofold effect I think. By having well-designed container,
algorithms and the like, you end up writing less code, and thus the
percentage of template-generated code in the app increases even faster.
One must not forget to consider that some code just has got to be
there. If it doesn't come from a reusable container, it will be written
by coders. And templates allow sharing code even without planning it.
Jean-Louis Leroy
http://ourworld.compuserve.com/homepages/jl_leroy
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1997/10/02 Raw View
"Bradd W. Szonye" <bradds@concentric.net> writes:
|> Why do people in this newsgroup seem stuck on the idea that the
|> "implementation" collection class is a template? Since you're only writing
|> it to implement one kind of collection--a void * collection--it needn't be
|> a template class.
[...]
|> I've done just this to implement set and map for our current project, using
|> a void* splay-tree manager behind the scenes and a "generic-macro" typesafe
|> frontend. I don't see why Standard Library implementations wouldn't use
|> this technique, unless some sort of code-size vs. speed-performance issue
|> is involved. (There's also a potential difficulty of maintanance issue, but
|> it's not a horrible one.)
I've done this in the past. I suspect that it is not done today because
the space issue really isn't one, given the price of memory, and that in
most cases, any given container will only be instantiated over one or
two types anyway.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
I'm looking for a job -- Je recherche du travail
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1997/10/03 Raw View
ark@research.att.com (Andrew Koenig) writes:
|> In article <342EDF1B.1149@pratique.fr> bonnardv@pratique.fr writes:
|> > Clive Bluston <clive@emultek.co.il> writes:
|>
|> > > To be more specific, if ten programmers are working on a single
|> > > project and they want to use collections freely in their code, the
|> > > executable will end up being FAR bigger than it need be.
|>
|> > Well, some compiler writer simply don't consider code size
|> > important, so they won't do anything about it (until you
|> > complain to them ?).
|>
|> > The first thing to do is to check if the same template
|> > instantiate twice (under the inclusion model) is only written
|> > once in the executable (just as inline functions, redondants
|> > copies must be suppressed); otherwise, the compiler is certainly
|> > non-conformant.
|>
|> And the next thing to check is how much it really costs.
|> It is hard for me to believe that the amount of code generated
|> by a well designed container, even if all that code is laid down
|> for each distinct type with which that container is used, is
|> a major part of the total amoutn of code in an application.
|> Containers just aren't that big.
I'll second this, from concrete experience. I used to carefully factor
out all of my type independant code from my templates, but I've stopped
doing it. In practice, the difference just wasn't noticeable, at least
for the containers I was using (various array classes, hash table based
maps and lists).
Of course, the compilers I use (Sun CC and HP CC) support separate
compilation of templates, and I make little use of inline functions.
What I suspect is happening is that the compiler in question has poor
support for separate compilation of templates, so the templated classes
use mainly inline functions, and the code bloat is actually due to the
inlining, and not the templates per se. (Of course, I'm just guessing
about this.)
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
I'm looking for a job -- Je recherche du travail
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson)
Date: 1997/09/27 Raw View
Clive Bluston <clive@emultek.co.il> writes:
>To be more specific, if ten programmers are working on a single
>project and they want to use collections freely in their code, the
>executable will end up being FAR bigger than it need be.
That's not necessarily true. It depends on the implementation.
>It does not mean STL collections are useless. They can be
>used in projects, just not as freely as is usually needed.
>
>This is not simply an academic detail. It is a show stopper for
>real projects!
>
>I do not understand why the standards committee did/does not
>recognize this fact.
The standards committee recognizes that this will be the case
for simple implementations. However, the standards committee
also recognizes that there are well-known techniques for
avoiding this problem. They are described in Bjarne Stroustrup's
book "The C++ programming language" 2nd Ed.
>It is no good blaming compiler writers for
>not coming up with a compiler/linker that solves the problem.
Actually it is more the library writers that are to blame.
You're right that simply blaming vendors for the problem won't
help, though. You need to communicate your problem to the
appropriate vendors, and you need to vote with your feet
(or, perhaps more importantly, with your cheque-books).
--
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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Dominic North <Dominic.North@ping.be>
Date: 1997/09/28 Raw View
I have been working with the GNU STL from g++ 2.5.2 for 9 months now
and we have had and still have problems with the code getting as fat as
I am. Unfortunately the work-around pragmas GNU provide are about as
useful as a chocolate tea pot, since they require modification of the
STL headers themselves to work, which seems contrary to the idea of
using a standard library, even if the GNU license might permit it.
In article <60iuu6$ece@mulga.cs.mu.OZ.AU>, Fergus Henderson wrote:
> However, the standards committee
> also recognizes that there are well-known techniques for
> avoiding this problem. They are described in Bjarne Stroustrup's
> book "The C++ programming language" 2nd Ed.
>
Don't you mean 3rd Edition? I don't recall much on the STL in the
second. I will have to wait for my birthday next month for the new one!
In the mean time, the sort of liposuction technique we have used with
some success is to insulate completely the STL class, by wrapping it in
another class with a pointer to the STL class object, and delegating
everything. We did this with the string class, and saved a significant
amount of space.
One disadvantage is that every function that you want (or every
function, if you wish for perfection) has to be forwarded by hand. This
is not a difficult enterprise, but it is time-consuming. If more than
one type has to be supported, then it is necessary to duplicate the
effort manually, which I find ironic seeing as we are dealing with
templates!
Another disadvantage is that all the forwarding functions have to be
out of line, as the isolation must be complete. Stlcodebloatitis is
very infectious.
My boss was never a great fan of templates, and needless to say, this
has not endeared them to him any further.
> You're right that simply blaming vendors for the problem won't
> help, though. You need to communicate your problem to the
> appropriate vendors, and you need to vote with your feet
> (or, perhaps more importantly, with your cheque-books).
>
Well with GNU my employer's check-book will not help much <g>! And to
which vendor can we safely go, without breaking much code? We've
already had lots of fun porting to MS VC++. This does highlight another
problem with the STL, i.e. that the Standard is in practice anything
but.
I still think that templates are a good idea, and that the STL is a
good idea too. On balance, I still think that we have gained more than
we have lost through using it. However, perhaps the standard should be
made tougher on quality of implementation, if it has not already, and
somehow or other, a good number of vendors must be pushed into
conformance with the standard. How about some sort of ANSI
certification once the standard is in place?
Dominic
Bruxelles, Sun, 28 Sep 1997 10:21 +0200
also cis:106136,2400
using Virtual Access 4.01 build 232 (32-bit)
on WinNT build 1057 (3.51)
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
Date: 1997/09/28 Raw View
Dominic North <Dominic.North@ping.be> writes:
>In article <60iuu6$ece@mulga.cs.mu.OZ.AU>, Fergus Henderson wrote:
>> However, the standards committee
>> also recognizes that there are well-known techniques for
>> avoiding this problem. They are described in Bjarne Stroustrup's
>> book "The C++ programming language" 2nd Ed.
>
>Don't you mean 3rd Edition? I don't recall much on the STL in the
>second. I will have to wait for my birthday next month for the new one!
No, I mean 2nd Ed. See section 8.3.1, page 261:
"... the scheme is type safe ...
type safety is achieved without the expenditure of time or space
because the access functions ... are trivial inline functions ...
there is no replication of code ..."
The basic idea is to define private collection classes using `void *',
and then provide public type-safe inline template interfaces to them.
>> You're right that simply blaming vendors for the problem won't
>> help, though. You need to communicate your problem to the
>> appropriate vendors, and you need to vote with your feet
>> (or, perhaps more importantly, with your cheque-books).
>
>Well with GNU my employer's check-book will not help much <g>!
Actually paying Cygnus will likely help just as much (or just as little)
as paying other software companies. But that is really a topic for
another newsgroup.
>This does highlight another problem with the STL, i.e. that
>the Standard is in practice anything but.
As yet there is no standard. There is only a _draft_ standard.
>I still think that templates are a good idea, and that the STL is a
>good idea too. On balance, I still think that we have gained more than
>we have lost through using it. However, perhaps the standard should be
>made tougher on quality of implementation, if it has not already, and
>somehow or other, a good number of vendors must be pushed into
>conformance with the standard. How about some sort of ANSI
>certification once the standard is in place?
There are a few third-party companies that offer various conformance
testing services for C, and these companies will probably start
offering similar services for C++ once the standard is out.
--
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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1997/09/29 Raw View
Clive Bluston <clive@emultek.co.il> writes:
> To be more specific, if ten programmers are working on a single
> project and they want to use collections freely in their code, the
> executable will end up being FAR bigger than it need be.
Well, some compiler writer simply don't consider code size
important, so they won't do anything about it (until you
complain to them ?).
The first thing to do is to check if the same template
instantiate twice (under the inclusion model) is only written
once in the executable (just as inline functions, redondants
copies must be suppressed); otherwise, the compiler is certainly
non-conformant.
_You'll need to check that._
Newer compiler will get it right.
The linker could also suppress functions which have the excatly
same code, with different names (there are plenty of them).
Example:
void foo () { cout << 1; }
void bar () { cout << 1; }
Would generates:
void foo_bar () { cout << 1; }
foo = foo_bar
bar = foo_bar
However, I don't know if it's conformant (what
if &foo == &bar ?). But the compiler can have an option
to do it, as it won't break many programs.
It seems prety simple to implement using multi_set or map
or hash_multi_set or hash_map ;-)
Lastly, library writers could take care of that (again, if
there was some pression, and as far as it doesn't alter time
performances).
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
Date: 1997/09/29 Raw View
Valentin Bonnard <bonnardv@pratique.fr> writes:
>The linker could also suppress functions which have the excatly
>same code, with different names (there are plenty of them).
>
>Example:
>
>void foo () { cout << 1; }
>void bar () { cout << 1; }
>
>Would generates:
>
>void foo_bar () { cout << 1; }
>foo = foo_bar
>bar = foo_bar
>
>However, I don't know if it's conformant (what
>if &foo == &bar ?).
It's not, but the linker can easily generate
foo: jmp bar
which is almost as good.
--
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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: steagall@deltalogic.com (Bob Steagall)
Date: 1997/09/30 Raw View
On 25 Sep 1997 17:43:18 PDT, Clive Bluston <clive@emultek.co.il> wrote:
> To be more specific, if ten programmers are working on a single
> project and they want to use collections freely in their code, the
> executable will end up being FAR bigger than it need be.
> It does not mean STL collections are useless. They can be
> used in projects, just not as freely as is usually needed.
>
> This is not simply an academic detail. It is a show stopper for
> real projects!
>
> I do not understand why the standards committee did/does not
> recognize this fact. It is no good blaming compiler writers for
> not coming up with a compiler/linker that solves the problem.
>
> It is time to have an additional standard library that does not
> use templates.
You should have a look at the XTL whitepaper, which describes how our
standard library container design pattern eliminates code bloat. It's at
http://www.deltalogic.com/xtlwhite.htm and
http://www.deltalogic.com/xtleii.htm
--Bob
====================================================================
Bob Steagall steagall@deltalogic.com
DeltaLogic, Inc. http://www.deltalogic.com
1537 Kew Road Voice (216) 321-8200
Cleveland Hts, OH 44118-1204 Fax (216) 321-6976
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Jean-Louis Leroy <jll@skynet.be>
Date: 1997/09/30 Raw View
In article <60lu6e$7d6@mulga.cs.mu.OZ.AU>, Fergus Henderson wrote:
> The basic idea is to define private collection classes using `void *',
> and then provide public type-safe inline template interfaces to them.
Yes, but those collection better not be private, full stop. As the C++
expert in a team writing the Belgian Appeal Court Software, I am faced
with that kind of problems. Our target platform allows us to use the
excellent Kai compiler, which supports partial specialization. Fine. In
the final phase of the development effort, I intend to trim code size by
using the kind of technique Stroustrup has in mind. However, once I say:
template<class T /* etc*/ >
class vector<T*>
{
// ...
};
I loose vector<void*>. AFAIK, I can't use it to implement vector<T*>. If
vector is implemented by means of 'private' classes:
template<class T /* etc */>
class internal_vector
{
// ...
// behave just like vector<T>
};
..I can say:
template<class T /* etc */>
class vector<T*>
{
private:
internal_vector<void*> content;
// ...
};
// OpalPtr<T> is a smart, reference-counted pointer that is part of a
// persistence package
template<class T /* etc*/ >
class vector<OpalPtr<T> >
{
public:
void push_back(const OpalPtr<T>& p)
{ content.push_back(p); p->addRef(); }
// ...
private:
internal_vector<void*> content;
};
However, I have yet to see an implementation of the STL structured in
this fashion.
Jean-Louis Leroy
http://ourworld.compuserve.com/homepages/jl_leroy
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Jason Merrill <jason@cygnus.com>
Date: 1997/09/30 Raw View
>>>>> Dominic North <Dominic.North@ping.be> writes:
> Unfortunately, as far as I can see, the worst bloaters in the STL,
> at least of those that I have used so far in the GNU implementation, are
> (in descending order) string and map!
string? How many different character types are you using?
Jason
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Dominic North <Dominic.North@ping.be>
Date: 1997/09/30 Raw View
In article <60lu6e$7d6@mulga.cs.mu.OZ.AU>, Fergus Henderson wrote:
> No, I mean 2nd Ed. See section 8.3.1, page 261:
>
> "... the scheme is type safe ...
> type safety is achieved without the expenditure of time or space
> because the access functions ... are trivial inline functions ...
> there is no replication of code ..."
>
> The basic idea is to define private collection classes using `void *',
> and then provide public type-safe inline template interfaces to them.
>
Well I remembered that bit, but did not see it of particular application
to the STL. Of course, you can define vector<void*>, deque<void*> and so
on, but that doesn't help you with different types of map key, strings
etc. Unfortunately, as far as I can see, the worst bloaters in the STL,
at least of those that I have used so far in the GNU implementation, are
(in descending order) string and map!
> As yet there is no standard. There is only a _draft_ standard.
Quite.
> There are a few third-party companies that offer various conformance
> testing services for C, and these companies will probably start
> offering similar services for C++ once the standard is out.
Interesting. Is there/would there be some ANSI approval mechanism for
these companies as ISO has for ISO200x (not that ISO200x isn't often a
sham, but that's also for another news-group)?
Dominic
Bruxelles, Mon, 29 Sep 1997 08:19 +0200
also cis:106136,2400
using Virtual Access 4.01 build 232 (32-bit)
on WinNT build 1057 (3.51)
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: lijewski@shell.UCSD.EDU (Mike Lijewski)
Date: 1997/10/01 Raw View
In article <VA.0000030d.0c83fe26@viglen>,
Dominic North <Dominic.North@ping.be> wrote:
>In article <60lu6e$7d6@mulga.cs.mu.OZ.AU>, Fergus Henderson wrote:
>> The basic idea is to define private collection classes using `void *',
>> and then provide public type-safe inline template interfaces to them.
>
>Well I remembered that bit, but did not see it of particular application
>to the STL. Of course, you can define vector<void*>, deque<void*> and so
>on, but that doesn't help you with different types of map key, strings
>etc. Unfortunately, as far as I can see, the worst bloaters in the STL,
>at least of those that I have used so far in the GNU implementation, are
>(in descending order) string and map!
The same thing can more or less be done with map, multimap, set, and
multiset: the underlying balanced tree can be written in terms of void*.
The Standard Library distributed with KCC does this, as does the STL sold
by ObjectSpace, among possibly others.
--
Mike Lijewski lijewski@wco.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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Dominic North <Dominic.North@ping.be>
Date: 1997/10/01 Raw View
In article <u9oh5a3hvr.fsf@yorick.cygnus.com>, Jason Merrill wrote:
> string? How many different character types are you using?
>
Just the one. However, by isolating the string class, we chopped a
significant amount of space off our executables. The problem was
bastring.cc file that had to be included all over the place. This was
version 2.7.2. (not 2.5.2 - that was a typo), so maybe things are
better now.
Dominic
Bruxelles, Tue, 30 Sep 1997 23:11 +0200
also cis:106136,2400
using Virtual Access 4.01 build 232 (32-bit)
on WinNT build 1057 (3.51)
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: "Bradd W. Szonye" <bradds@concentric.net>
Date: 1997/10/01 Raw View
Jean-Louis Leroy <jll@skynet.be> wrote in article
<VA.00000017.2a413e57@jll_p133.INFOCAHB>...
[Regarding using an underlying 'void*' collection to implement template
collections]
> However, I have yet to see an implementation of the STL structured in
> this fashion.
Why do people in this newsgroup seem stuck on the idea that the
"implementation" collection class is a template? Since you're only writing
it to implement one kind of collection--a void * collection--it needn't be
a template class.
class tree_impl { /* managages a tree of void * objects /* };
template<...> class map { ... private: tree_impl map_tree; };
Or, possibly better yet, using an opaque implementation:
class tree_impl;
template<...> class map { ... private: tree_impl * map_tree; };
The tree_impl class takes some traits of the collected objects (like an
allocator, deallocator, copier and comparator) with 'void *' interfaces and
internal casting from void* to the real type.
I've done just this to implement set and map for our current project, using
a void* splay-tree manager behind the scenes and a "generic-macro" typesafe
frontend. I don't see why Standard Library implementations wouldn't use
this technique, unless some sort of code-size vs. speed-performance issue
is involved. (There's also a potential difficulty of maintanance issue, but
it's not a horrible one.)
--
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Jean-Louis Leroy <jll@skynet.be>
Date: 1997/10/01 Raw View
In article <01bccdf6$8117c9c0$a672adce@azguard>, Bradd W. Szonye wrote:
> Why do people in this newsgroup seem stuck on the idea that the
> "implementation" collection class is a template? Since you're only writing
> it to implement one kind of collection--a void * collection--it needn't be
> a template class.
Well, actually, vector<void*> is not a template, it's a class.
More to the point, why should we need to write a vector_of_pvoid by hand to
get the exact same result as instantiating vector<> on void*?
Jean-Louis Leroy
http://ourworld.compuserve.com/homepages/jl_leroy
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Clive Bluston <clive@emultek.co.il>
Date: 1997/09/25 Raw View
To be more specific, if ten programmers are working on a single
project and they want to use collections freely in their code, the
executable will end up being FAR bigger than it need be.
It does not mean STL collections are useless. They can be
used in projects, just not as freely as is usually needed.
This is not simply an academic detail. It is a show stopper for
real projects!
I do not understand why the standards committee did/does not
recognize this fact. It is no good blaming compiler writers for
not coming up with a compiler/linker that solves the problem.
It is time to have an additional standard library that does not
use templates.
My experience shows that few, if any bugs are caused by
casting to a non-typesafe collection.
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: Hyman Rosen <uunet!jyacc!hymie@ncar.UCAR.EDU>
Date: 1997/09/27 Raw View
Clive Bluston <clive@emultek.co.il> writes:
> It is time to have an additional standard library that does not
> use templates.
>
> My experience shows that few, if any bugs are caused by
> casting to a non-typesafe collection.
Well, then, why don't you just have everyone use container<void *>
where they're now using typesafe containers? Presto, no more code
bloat.
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Author: Herb Sutter <HerbS@cntc.com>
Date: 1997/09/27 Raw View
Clive Bluston <clive@emultek.co.il> wrote:
>To be more specific, if ten programmers are working on a single
>project and they want to use collections freely in their code, the
>executable will end up being FAR bigger than it need be.
>It does not mean STL collections are useless. They can be
>used in projects, just not as freely as is usually needed.
>
>This is not simply an academic detail. It is a show stopper for
>real projects!
I didn't see the beginning of this thread, but... we have programmers
working on over a dozen major modules within our 150KLOC project. Nearly
all source files use STL lists, vectors and maps extensively, and most
headers mention some STL container or sequence.
What system are you running under, and what compilers?
>My experience shows that few, if any bugs are caused by
>casting to a non-typesafe collection.
Here again, your mileage does vary from mine! :-)
---
Herb Sutter (mailto:herbs@cntc.com)
Current Network Technologies Corp. (http://www.cntc.com)
2695 North Sheridan Way, Suite 150, Mississauga ON Canada L5K 2N6
Tel 416-805-9088 Fax 905-822-3824
---
[ 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 ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]