"Witless" <witless@attbi.com> wrote in message
news:3D0FDC42.22A433CA@attbi.com...
> Allan W wrote:

> > "Markus Mauhart" <markus.mauhart@chello.at> wrote
> > To fold vector<long>::erase in to vector<int>::erase, all they have to
> > do is replace the former with a jump instruction to the latter.

> > Now, instead of consuming 0 extra bytes, it consumes ... well,
> > whatever the size of an assembly-language jump instruction is.
> > Five bytes, I'm guessing. Still, the address of "the function"
> > is the jump instruction -- and therefore it has a distinct address.

> Prepending a NOP to the aliased function would probably take less space
and cost less
> performance (given the effect of additional cache usage for non-local jump
> instructions).


Agreed.

However, if you have twenty identical copies of a function folded together,
there are 19 nops at the beginning, which _will_ cause a performance hit
(albeit small) for function calls that enter at the start of the nop list,
as they have to read, decode and do nothing for each of those nops. How do
you decide which of the folded functions takes the hit?

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer




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

"Stephen Howe" <SPAMstephen.howeGUARD@tnsofres.com> wrote in message news:<3d05f0a1$0$237$ed9e5944@reading.news.pipex.net>...
> > Are you aware that this behaviour does not conform to the C++ standard?
> > The C++ standard requires that distinct functions have distinct addresses.
>
> Does this apply to the standard library? For example, must atoi() be
> distinct from atol() when int and long have the same range?

I think I remember from the 1980's that Microsoft's atoi() and atol()
were in reality the same function. This worked because ints were
16 bits, returned in register AX, and longs wer 32 bits, returned with
the low-order 16 bits in register AX. So long as the value was in-range
for an int, the value was correct.

This was long before Microsoft C++ came out, and it might not be
true anymore. I no longer remember if one of the routines had a jump
to the other one, or one of them might have been a NOP in front of
the other one. Even if it didn't then, it might now.

Would any real-world code break if
   (void*)atoi == (void*)atol
returned true instead of false?

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

"Markus Mauhart" <markus.mauhart@chello.at> wrote
> "Fergus Henderson" <fjh@cs.mu.OZ.AU> wrote ...
> > "Markus Mauhart" <markus.mauhart@chello.at> writes:
> >  >Are you both aware that this type of code-bloat (especially for templates)
> >  >is solved by state-of-the-art dev tools since 1998 ? And hence there is
> >  >probably no need to address this problem in std c++.
> >  >
> >  >E.g. with MS's linkers since 1998 both 'problems' are solved automatically:
> >  >Through an iterative process the linker 'folds' all ("all": actually
> >  >depends on (configurable) iteration max count) binary identical functions
> >  >(and probably data .. vtbls).
> >  >So with int==long and using vector<int> + vector<long> + algorithms using
> >  >them, the map file shows all symbols, but for each symbol<int> there is
> >  >a symbol<long> occupying the same address range in the binary.
> >
> > Are you aware that this behaviour does not conform to the C++ standard?
> > The C++ standard requires that distinct functions have distinct addresses.
>
> I was not aware that there MIGHT be a problem with MS linker's behaviour
> when this optimization is enabled (this is default for optimized builds).
>
> But I would like that you help me to understand that possible problem.
> After your surprising hint I looked up the standard and all I could
> find in the short time was 5.1, par1, ..
>   "Two pointers of the same type compare equal if and only if they are
>   both null, both point to the same object or function, or both point
>   one past the end of the same array."
> But IMHO all functions and (most?) data participating in the here
> discussed possible code-bloat problem have different types through
> their different template arguments, so with respect to this discussion
> I couldnt find arguments for your statement.
> Nevertheless I see now that this linker optimization (when done in a
> simple way) might result in non-conformant pointer equality for
> some different objects, so this has to be checked by current
> implementers of this optimization.

I don't know how Microsoft does it... but it would be simple to get 99%
of the benefit of function folding, and still satisfy the objections
of Fergus Henderson.

To fold vector<long>::erase in to vector<int>::erase, all they have to
do is replace the former with a jump instruction to the latter.

Now, instead of consuming 0 extra bytes, it consumes ... well,
whatever the size of an assembly-language jump instruction is.
Five bytes, I'm guessing. Still, the address of "the function"
is the jump instruction -- and therefore it has a distinct address.

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

"Markus Mauhart" <markus.mauhart@nospamm.chello.at> wrote
> Hence my conclusion of all this might-be-problems is
> that MS linker's optional "COMDAT folding" optimization
> contains the natural and absolutely conformant solution
> of the template code bloat problem, but additionally
> (as Fergus Henderson has pointed out) the current simple
> implementation very very infrequently does a non-conformant
> folding wich ((very infrequently)^3)! might break code, so
> this should be fixed.

I agree, this should be fixed.

If Fergus Henderson is right, then I think the standard should be
fixed to loosen this requirement.

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

Allan W wrote:

> "Markus Mauhart" <markus.mauhart@chello.at> wrote
> > "Fergus Henderson" <fjh@cs.mu.OZ.AU> wrote ...
> > > "Markus Mauhart" <markus.mauhart@chello.at> writes:
> > >  >Are you both aware that this type of code-bloat (especially for templates)
> > >  >is solved by state-of-the-art dev tools since 1998 ? And hence there is
> > >  >probably no need to address this problem in std c++.
> > >  >
> > >  >E.g. with MS's linkers since 1998 both 'problems' are solved automatically:
> > >  >Through an iterative process the linker 'folds' all ("all": actually
> > >  >depends on (configurable) iteration max count) binary identical functions
> > >  >(and probably data .. vtbls).
> > >  >So with int==long and using vector<int> + vector<long> + algorithms using
> > >  >them, the map file shows all symbols, but for each symbol<int> there is
> > >  >a symbol<long> occupying the same address range in the binary.
> > >
> > > Are you aware that this behaviour does not conform to the C++ standard?
> > > The C++ standard requires that distinct functions have distinct addresses.
> >
> > I was not aware that there MIGHT be a problem with MS linker's behaviour
> > when this optimization is enabled (this is default for optimized builds).
> >
> > But I would like that you help me to understand that possible problem.
> > After your surprising hint I looked up the standard and all I could
> > find in the short time was 5.1, par1, ..
> >   "Two pointers of the same type compare equal if and only if they are
> >   both null, both point to the same object or function, or both point
> >   one past the end of the same array."
> > But IMHO all functions and (most?) data participating in the here
> > discussed possible code-bloat problem have different types through
> > their different template arguments, so with respect to this discussion
> > I couldnt find arguments for your statement.
> > Nevertheless I see now that this linker optimization (when done in a
> > simple way) might result in non-conformant pointer equality for
> > some different objects, so this has to be checked by current
> > implementers of this optimization.
>
> I don't know how Microsoft does it... but it would be simple to get 99%
> of the benefit of function folding, and still satisfy the objections
> of Fergus Henderson.
>
> To fold vector<long>::erase in to vector<int>::erase, all they have to
> do is replace the former with a jump instruction to the latter.
>
> Now, instead of consuming 0 extra bytes, it consumes ... well,
> whatever the size of an assembly-language jump instruction is.
> Five bytes, I'm guessing. Still, the address of "the function"
> is the jump instruction -- and therefore it has a distinct address.

Prepending a NOP to the aliased function would probably take less space and cost less
performance (given the effect of additional cache usage for non-local jump
instructions).

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

"Allan W" <Allan_W@my-dejanews.com> wrote in message
news:23b84d65.0206181420.77a33d28@posting.google.com...
> "Markus Mauhart" <markus.mauhart@nospamm.chello.at> wrote
> > Hence my conclusion of all this might-be-problems is
> > that MS linker's optional "COMDAT folding" optimization
> > contains the natural and absolutely conformant solution
> > of the template code bloat problem, but additionally
> > (as Fergus Henderson has pointed out) the current simple
> > implementation very very infrequently does a non-conformant
> > folding wich ((very infrequently)^3)! might break code, so
> > this should be fixed.
>
> I agree, this should be fixed.
>
> If Fergus Henderson is right, then I think the standard should be
> fixed to loosen this requirement.

I'm not sure we need to fix the standard. Microsoft's current folding
behavior isn't a bug unless somebody takes the address of more than one of
the functions that are folded together. In other words, inspecting the
binary produced by the linker doesn't fall under "observable behavior". It's
quite possible that MS prevents folding together of functions whose address
is taken.

-Dave



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

> Are you aware that this behaviour does not conform to the C++ standard?
> The C++ standard requires that distinct functions have distinct addresses.

Does this apply to the standard library? For example, must atoi() be
distinct from atol() when int and long have the same range?

Thanks

Stephen Howe


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

"Robert Klemme" <bob.news@gmx.net> wrote ...
>
> hi markus,
>
> > But for an example of non-conformant implementation of this
> > optimization (i.e. a linker bug) take the following code
> > in VC7 (==VC.NET):
> > (Note: this is IMO not "a realistic example where this
> > really matters", but i'm sure that such real world code
> > exists)
>
> i see and understand your example.  but with your example has no
> problem, because you simply output pointes.  the question i was
> after is, which code will break when the pointers are identical
> in the optimized case?  what kind of code would need this
> comparison?  and in which situations will there be problems when
> the pointers are identical?  i still have no idea of a scenario
> that would break with this optimization.

(sorry for the delay)

I cant give you the concrete and usefull realworld code
that would be broken, but maybe some ideas: think of
code that for whatever reasons makes some decisions
based on the functions on its call stack - clearly
not portable, and maybe inherently false cause 5.1,1
allows folding of functions with different type.
Or think of code that inserts object/function pointers
into containers when either the container or the code
assumes different pointers for different objects
(pair=myset.insert(fint);assert(pair.second);); so
basically when the pointers are stored in arrays or
containers (while my simple sample only did cout<<ptr).
Or when the object addresses are used as template
non-class arguments.

Hence my conclusion of all this might-be-problems is
that MS linker's optional "COMDAT folding" optimization
contains the natural and absolutely conformant solution
of the template code bloat problem, but additionally
(as Fergus Henderson has pointed out) the current simple
implementation very very infrequently does a non-conformant
folding wich ((very infrequently)^3)! might break code, so
this should be fixed.


Regards,
Markus.



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

hi markus,

> But for an example of non-conformant implementation of this
> optimization (i.e. a linker bug) take the following code
> in VC7 (==VC.NET):
> (Note: this is IMO not "a realistic example where this
> really matters", but i'm sure that such real world code
> exists)

i see and understand your example.  but with your example has no
problem, because you simply output pointes.  the question i was
after is, which code will break when the pointers are identical
in the optimized case?  what kind of code would need this
comparison?  and in which situations will there be problems when
the pointers are identical?  i still have no idea of a scenario
that would break with this optimization.

thank you!

 robert

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

"Markus Mauhart" <markus.mauhart@chello.at> writes:

 >"Cyril Schmidt" <crschmidt@lucent.com> wrote ...
 >>
 >> Francis Glassborow wrote ...
 >>
 >> > While reading a thread on code-bloat in comp.lang.c++.moderated an
 >> > errant thought marched across the foreground of my consciousness. If we
 >> > had some form of strong typedefs (for now let me invent a syntax:
 >> >
 >> > typename yourtype :  mytype;
 >....
 >> This will instantiate sort<long*, long*>, although it could have used
 >> sort<int*, int*>. That means, however we share the container implementation
 >> for int and long, we cannot share the algorithm implementation, even where
 >> it is appropriate to do so (the sorting of ints does essentially the same as
 >> the sorting of longs).
 >
 >Are you both aware that this type of code-bloat (especially for templates)
 >is solved by state-of-the-art dev tools since 1998 ? And hence there is
 >probably no need to address this problem in std c++.
 >
 >E.g. with MS's linkers since 1998 both 'problems' are solved automatically:
 >Through an iterative process the linker 'folds' all ("all": actually
 >depends on (configurable) iteration max count) binary identical functions
 >(and probably data .. vtbls).
 >So with int==long and using vector<int> + vector<long> + algorithms using
 >them, the map file shows all symbols, but for each symbol<int> there is
 >a symbol<long> occupying the same address range in the binary.

Are you aware that this behaviour does not conform to the C++ standard?
The C++ standard requires that distinct functions have distinct addresses.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Fergus Henderson" <fjh@cs.mu.OZ.AU> wrote ...
>
> "Markus Mauhart" <markus.mauhart@chello.at> writes:
>
>  >"Cyril Schmidt" <crschmidt@lucent.com> wrote ...
>  >>
>  >> Francis Glassborow wrote ...
>  >>
>  >> > While reading a thread on code-bloat in comp.lang.c++.moderated an
>  >> > errant thought marched across the foreground of my consciousness. If we
>  >> > had some form of strong typedefs (for now let me invent a syntax:
>  >> >
>  >> > typename yourtype :  mytype;
>  >....
>  >> This will instantiate sort<long*, long*>, although it could have used
>  >> sort<int*, int*>. That means, however we share the container implementation
>  >> for int and long, we cannot share the algorithm implementation, even where
>  >> it is appropriate to do so (the sorting of ints does essentially the same as
>  >> the sorting of longs).
>  >
>  >Are you both aware that this type of code-bloat (especially for templates)
>  >is solved by state-of-the-art dev tools since 1998 ? And hence there is
>  >probably no need to address this problem in std c++.
>  >
>  >E.g. with MS's linkers since 1998 both 'problems' are solved automatically:
>  >Through an iterative process the linker 'folds' all ("all": actually
>  >depends on (configurable) iteration max count) binary identical functions
>  >(and probably data .. vtbls).
>  >So with int==long and using vector<int> + vector<long> + algorithms using
>  >them, the map file shows all symbols, but for each symbol<int> there is
>  >a symbol<long> occupying the same address range in the binary.
>
> Are you aware that this behaviour does not conform to the C++ standard?
> The C++ standard requires that distinct functions have distinct addresses.

I was not aware that there MIGHT be a problem with MS linker's behaviour
when this optimization is enabled (this is default for optimized builds).

But I would like that you help me to understand that possible problem.
After your surprising hint I looked up the standard and all I could
find in the short time was 5.1, par1, ..
  "Two pointers of the same type compare equal if and only if they are
  both null, both point to the same object or function, or both point
  one past the end of the same array."
But IMHO all functions and (most?) data participating in the here
discussed possible code-bloat problem have different types through
their different template arguments, so with respect to this discussion
I couldnt find arguments for your statement.
Nevertheless I see now that this linker optimization (when done in a
simple way) might result in non-conformant pointer equality for
some different objects, so this has to be checked by current
implementers of this optimization.


Thanks for you help,
Markus.



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

In article <i7NJ8.38368$305.509268@news.chello.at>, Markus Mauhart
<markus.mauhart@chello.at> writes
>Nevertheless I see now that this linker optimization (when done in a
>simple way) might result in non-conformant pointer equality for
>some different objects, so this has to be checked by current
>implementers of this optimization.

There is, however a fix I think. If the address of the function is ever
taken then the linker must generate a forwarding stub function when
conflating the function with one that is otherwise identical.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

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

Markus Mauhart schrieb:
> Nevertheless I see now that this linker optimization (when done in a
> simple way) might result in non-conformant pointer equality for
> some different objects, so this has to be checked by current
> implementers of this optimization.

since i don't see as clear as you, could anybody please come up
with a realistic example where this really matters?  thank you!

regards

 robert

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

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote ...
>
> In article <i7NJ8.38368$305.509268@news.chello.at>, Markus Mauhart
> <markus.mauhart@chello.at> writes
> >Nevertheless I see now that this linker optimization (when done in a
> >simple way) might result in non-conformant pointer equality for
> >some different objects, so this has to be checked by current
> >implementers of this optimization.
>
> There is, however a fix I think. If the address of the function is ever
> taken then the linker must generate a forwarding stub function when
> conflating the function with one that is otherwise identical.

A good solution.

But regardless of this template code-bloat (non-)issue IMHO
future support for some kind of "strong typedef" as you and
Hyman Rosen here recently suggested would be generally usefull.



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

"Robert Klemme" <bob.news@gmx.net> wrote ...
>
> Markus Mauhart schrieb:
> > Nevertheless I see now that this linker optimization (when done in a
> > simple way) might result in non-conformant pointer equality for
> > some different objects, so this has to be checked by current
> > implementers of this optimization.
>
> since i don't see as clear as you, could anybody please come up
> with a realistic example where this really matters?  thank you!

I'm still not sure whether I see this [?no-?]problem clear, cause
with only [5.1,par1] in mind I'd call it "no problem", while
Fergus Henderson might have strong other arguments for his negative
judgment "this behaviour does not conform to the C++ standard?
The C++ standard requires that distinct functions have distinct
addresses."

Now even from my [5.1,par1] based "no problem" point of view
a simple implementation of this optimization COULD violate
conformance with [5.1,par1], allthough this violation would
NOT occur when optimizing away most template code bloat but
only under a view certain circumstances, and even then
non-conformance often would not change a programs intended
semantic.

But for an example of non-conformant implementation of this
optimization (i.e. a linker bug) take the following code
in VC7 (==VC.NET):
(Note: this is IMO not "a realistic example where this
really matters", but i'm sure that such real world code
exists)

    -----------------------------------------------------------
                       void f_int (int) {cout << flush;}
    template <class T> void f_t   (T)   {cout << flush;}
      //5.1,par1: All f_t<T>(T) may have same address (cause different types)
      //5.1,par1: But f_int(int) and f_t<int>(int) must have different address.

    int main (int xargc, char const* const xargv[])
    {
    f_int (0);
    f_t<int> (0);
    f_t<bool> (0);
    f_t<double> (0);

    void (* const fint)    (int)    = f_t<int>;
    void (* const fbool)   (bool)   = f_t<bool>;
    void (* const fdouble) (double) = f_t<double>;

    cout <<"int(&f_int(int)) = "          <<int(&f_int) <<endl;
    cout <<"int(&f_t<int>(int))  = "      <<int(fint) <<endl;
    cout <<"int(&f_t<bool>(bool))  = "    <<int(fbool) <<endl;
    cout <<"int(&f_t<double>(double))  = "<<int(fdouble) <<endl;

    if (&f_int == fint)
         cout <<"5.1,1 violation: (&f_int == &f_t<int>) is true." << endl;

    //if ((fint == fbool) && (fint == fdouble))
    //    cout <<"Conformant optimization: all &f_t<T> compare equal." << endl;

    return 0;
    }
    -----------------------------------------------------------

Output w/o optimization:
 int(&f_int(int)) = 4264021
 int(&f_t<int>(int))  = 4264301
 int(&f_t<bool>(bool))  = 4264046
 int(&f_t<double>(double))  = 4264256

Output with optimization:
 int(&f_int(int)) = 4199856
 int(&f_t<int>(int))  = 4199856
 int(&f_t<bool>(bool))  = 4199856
 int(&f_t<double>(double))  = 4199856
 5.1,1 violation: (&f_int == &f_t<int>) is true.

BTW, probably even VC5's linker from 1997 did this
template code-bloat reducing optimization.



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

"Cyril Schmidt" <crschmidt@lucent.com> wrote ...
>
> Francis Glassborow wrote ...
>
> > While reading a thread on code-bloat in comp.lang.c++.moderated an
> > errant thought marched across the foreground of my consciousness. If we
> > had some form of strong typedefs (for now let me invent a syntax:
> >
> > typename yourtype :  mytype;
....
> This will instantiate sort<long*, long*>, although it could have used
> sort<int*, int*>. That means, however we share the container implementation
> for int and long, we cannot share the algorithm implementation, even where
> it is appropriate to do so (the sorting of ints does essentially the same as
> the sorting of longs).

Are you both aware that this type of code-bloat (especially for templates)
is solved by state-of-the-art dev tools since 1998 ? And hence there is
probably no need to address this problem in std c++.

E.g. with MS's linkers since 1998 both 'problems' are solved automatically:
Through an iterative process the linker 'folds' all ("all": actually
depends on (configurable) iteration max count) binary identical functions
(and probably data .. vtbls).
So with int==long and using vector<int> + vector<long> + algorithms using
them, the map file shows all symbols, but for each symbol<int> there is
a symbol<long> occupying the same address range in the binary.



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

I'm glad that focus is put on this topic. Whether you suggestion is good
or bad, I can't see yet. But focusing on it is good. For good ideas of
what to be able to do with strong types in a way that would fit fine
with C++, see Ada.

/David

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

Francis Glassborow <francis.glassborow@ntlworld.com> wrote in message
news:<CZJxv2BBdi78EwRR@robinton.demon.co.uk>...
> While reading a thread on code-bloat in comp.lang.c++.moderated an
> errant thought marched across the foreground of my consciousness. If we
> had some form of strong typedefs (for now let me invent a syntax:
>
> typename yourtype :  mytype;
>
> means that mytype behaves exactly like yourtype with mytype replacing
> yourtype everywhere. In practice we would want to refine that quite a
> bit.)

I am also looking for something like this. It will certainly help reduce
the overhead of separate instantiation of, say, vector<int> and vector<long>,
but there is more than that.

Suppose I have a declaration
typename vector<int> : vector<long>;
which means that we implement a vector of long in terms of vector of int.

The type of vector<long>::iterator will be, I expect, long*.
If I want to sort a vector of long with std::sort, I will write
something like

vector<long> vl;
// ...
std::sort(vl.begin(), vl.end());

This will instantiate sort<long*, long*>, although it could have used
sort<int*, int*>. That means, however we share the container implementation
for int and long, we cannot share the algorithm implementation, even where
it is appropriate to do so (the sorting of ints does essentially the same as
the sorting of longs).

Anyway, I think the proposal is *very* promising; it only needs to be extended
to cover algorithms as well as types.

 Cyril

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

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:CZJxv2BBdi78EwRR@robinton.demon.co.uk...
>
> While reading a thread on code-bloat in comp.lang.c++.moderated an
> errant thought marched across the foreground of my consciousness. If we
> had some form of strong typedefs (for now let me invent a syntax:
>
> typename yourtype :  mytype;
....
> We could deal with the problem of specialising a template for two
> identical types with:
>
> template<> something<type1> {
> // what ever
> };
>
> typename something<type1> : something<type2>, something<type3>;
>
> to mean just forward something<type2> and something<type2> member
> functions to something<type1>.

This would be very helpful, just in terms of reducing repeated code.  But in
thinking about this, I had a thought:

template<typename T>
struct wrapper {

};

template<typename T>
struct type_of {
    void check() const;
};

template<typename T>
struct type_of<wrapper<T> > {
    void check() const { std::cout << "wrapped\n"; };
};

template<>
struct type_of<int> {
    void check() const { std::cout << "int\n"; };
};

template<>
struct type_of<long> {
    void check() const { std::cout << "long\n"; };
};

int main()
{
    type_of<int>().check();
    type_of<long>().check();
    type_of<wrapper<int> >().check();
    type_of<wrapper<long> >().check();
    return 0;
}

Output when compiled with Comeau is:

int
long
wrapped
wrapped

So it seems a similar effect could be achieved with an additional layer of
indirection.  However I'm all for making the template language a bit more
user-friendly.  Templated typedefs are at the top of my list as well.


Sean

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

While reading a thread on code-bloat in comp.lang.c++.moderated an
errant thought marched across the foreground of my consciousness. If we
had some form of strong typedefs (for now let me invent a syntax:

typename yourtype :  mytype;

means that mytype behaves exactly like yourtype with mytype replacing
yourtype everywhere. In practice we would want to refine that quite a
bit.)

We could deal with the problem of specialising a template for two
identical types with:

template<> something<type1> {
// what ever
};

typename something<type1> : something<type2>, something<type3>;

to mean just forward something<type2> and something<type2> member
functions to something<type1>. Note that as these would be pure
forwarding functions they would be a compile time artefact.


This would also allow us to write:

#if sizeof int == sizeof long
typename somrthing<int> : something<long>;
#endif.

Note that this is a very raw alpha version of an idea so at this time
consider the concept not the detail.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

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

On Fri, 24 May 2002 15:28:12 GMT, Francis Glassborow <francis.glassborow@=
ntlworld.com> wrote:
> =20
>  While reading a thread on code-bloat in comp.lang.c++.moderated an=20
>  errant thought marched across the foreground of my consciousness. If w=
e=20
>  had some form of strong typedefs (for now let me invent a syntax:
> =20
>  typename yourtype :  mytype;
[=B7=B7=B7]
>  This would also allow us to write:
> =20
>  #if sizeof int =3D=3D sizeof long
>  typename somrthing<int> : something<long>;
>  #endif.

You probably mean:

   #if INT_MAX =3D=3D LONG_MAX
   typename something<int> : something<long>;
   #endif

-- Niklas Matthies
--=20
Drive carefully; 90% of the people in the world are caused by accidents.

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

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:CZJxv2BBdi78EwRR@robinton.demon.co.uk...

> #if sizeof int == sizeof long
> typename somrthing<int> : something<long>;
> #endif.

Just remember that 'sizeof int == sizeof long' does not mean that the
two types can hold the same range of numbers. sizeof yields the size of
the object representation of the type, not the value representation (the
bits that is used to store the value).
It's a common misunderstanding that sizeof can be used to determine the
range of values that fit in an integral type (except 'unsigned char').

--
Dag Henriksson


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

In article=20
<slrnaeso1v.1e4.news_comp.std.c++_expires-2002-07-01@nightrunner.nmhq.net
 >, Niklas Matthies <news_comp.std.c++_expires-2002-07-01@nmhq.net>=20
writes
>On Fri, 24 May 2002 15:28:12 GMT, Francis Glassborow <francis.glassborow=
@ntlworld.com> wrote:
>>
>>  While reading a thread on code-bloat in comp.lang.c++.moderated an
>>  errant thought marched across the foreground of my consciousness. If =
we
>>  had some form of strong typedefs (for now let me invent a syntax:
>>
>>  typename yourtype :  mytype;
>[=B7=B7=B7]
>>  This would also allow us to write:
>>
>>  #if sizeof int =3D=3D sizeof long
>>  typename somrthing<int> : something<long>;
>>  #endif.
>
>You probably mean:
>
>   #if INT_MAX =3D=3D LONG_MAX
>   typename something<int> : something<long>;
>   #endif

No, I was writing pseudo-code. Another aspect of generic programming=20
that needs more support is compile time conditions applied to aspects of=20
types. Well I guess, some of Andrei's methods could be used, but I want=20
to see improvements to make such techniques easier to write and easier=20
to understand.



--=20
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

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