Topic: explicit tpl instantition (sic - sigh!)


Author: Marc Girod <girod@stybba.ntc.nokia.com>
Date: 1998/12/17
Raw View
Hello!

I posted already twice and got one partial answer (find below the link
to the thread through DejaNews).

The question at stake, and to which I'd wish an answer is the
following (3rd formulation):

  Since the standard mentions the concept of "explicit" template
  instantiation, how can one argue about a compiler being compliant or
  not in this respect?

Namely, my compiler will by default perform "implicit" template
instantiation, so that in order to discriminate out of those, I need
to either inspect the symbols produced, or use given compiler options.
Both solutions are implementation dependent.

Best Regards!
Marc

http://www.dejanews.com/dnquery.xp?search=thread&recnum=%3c199811292045.WAA17456@dshp01.ntc.nokia.com%3e%231/1&svcclass=dnserver

--
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.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              ]






Author: stephen.clamage@sun.com(Steve Clamage)
Date: 1998/12/17
Raw View
Marc Girod <girod@stybba.ntc.nokia.com> writes:

>The question at stake, and to which I'd wish an answer is the
>following (3rd formulation):

>  Since the standard mentions the concept of "explicit" template
>  instantiation, how can one argue about a compiler being compliant or
>  not in this respect?

>Namely, my compiler will by default perform "implicit" template
>instantiation, so that in order to discriminate out of those, I need
>to either inspect the symbols produced, or use given compiler options.
>Both solutions are implementation dependent.

I'm not sure I understand your question. Are you asking how you
can design a portable test to determine whether an arbitrary
compiler performs explicit template instantiation?

How about this: Define a template class which can be instantiated
on some types but will cause an error if instantiated on type T.
Request but do not use an explicit instantiation on T.
You should get an error on the explicit instantiation on T.

Example:

 template<typename T> class Derived : public T { };

 template class Derived<int>; // explicit instantiation

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






Author: Marc Girod <girod@stybba.ntc.nokia.com>
Date: 1998/12/06
Raw View
Hello!

First, Thanks for your answer!

JK == James Kuyper <kuyper@wizard.net> wrote:

JK> Which two symbols? In general, the standard doesn't say anything
JK> about which symbols are created. You need to convert your problem
JK> into a program that doesn't compile, or which executes
JK> incorrectly; the standard says a great deal about such issues.

In this case at least, it is easy, although longer (see below).
I am not quite convinced that it does change a lot to the situation:
it still depends upon a compiler option...

Well, I'd claim that this case is quite conservative, and that the
standard ought to guarantee the validity of this code.
Otherwise, what does the standard actually require, and how can I
challenge my vendor's statement that he is compliant?

Best Regards!
Marc

--------------------------------
#include <list>

struct AA {};
list<AA*> alist;
void rem() { alist.erase(alist.begin()); }

template list<AA*,allocator>::iterator list<AA*,allocator>::erase(
    list<AA*,allocator>::iterator,list<AA*,allocator>::iterator);

typedef list<AA*,allocator>::iterator LI;
typedef LI (list<AA*,allocator>::*F)(LI, LI);

int main() {
    F f = &list<AA*,allocator>::erase;
    return 0;
}
--------------------------------
% aCC +inst_none -o foo foo.C
/opt/aCC/lbin/ld: Unsatisfied symbols:
   list<AA *,allocator>::erase(list<AA *,allocator>::iterator,list<AA *,allocator>::iterator) (code)
   list<AA *,allocator>::deallocate_buffers() (code)


--
Marc Girod                Hiomo 5/1          Voice:  +358-9-511 23746
Nokia Telecommunications  P.O. Box 320       Mobile: +358-40-569 7954
NWS/NMS/NMS for Data      00045 NOKIA Group  Fax:    +358-9-511 23580
                          Finland            marc.girod@ntc.nokia.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              ]