unresolved external symbol

[Gernot Frisch]

a.h:
----

template <class X> void fkt(const X& x);

a.cpp
-----
template <class X>void fkt(const X& x)
{
printf("good\n");
}


main.cpp
--------
int main(int, char**)
{
fkt<double>(3.5);
}

gives a unresolved external symbol:
void fkt(const double& x);

I think I have to include the implementation of the function in the
header, but it's really lenghty. Is there any option?




--
-Gernot
int main(int argc, char** argv) {printf
("%silto%c%cf%cgl%ssic%ccom%c", "ma", 58, 'g', 64, "ba", 46, 10);}

________________________________________
Looking for a good game? Do it yourself!
GLBasic - you can do
www.GLBasic.com

 

[Ivan Vecerina]

a.h:
----

template <class X> void fkt(const X& x);

a.cpp
-----
template <class X>void fkt(const X& x)
{
printf("good\n");
}


main.cpp
--------
int main(int, char**)
{
fkt<double>(3.5);
}

gives a unresolved external symbol:
void fkt(const double& x);

I think I have to include the implementation of the function in the
header, but it's really lenghty. Is there any option?

The C++ standard specifies that you could add the "export" keyword
before the function definition. But only a couple of compilers
support this features, and major vendors have announced that they
do not intend to implement it ... ever. (it's a long story...)

As it is today, you need to somehow include the definition of the
template function in the header (or have at least some source
file that will include the template definition and explicitly
instantiate the template).


Regards,
Ivan

 

[John Harrison]

a.h:
----

template <class X> void fkt(const X& x);

a.cpp
-----
template <class X>void fkt(const X& x)
{
printf("good\n");
}


main.cpp
--------
int main(int, char**)
{
fkt<double>(3.5);
}

Not the answer to your question (see Ivan's post for that) but <double> is
unecessary here. C++ is capable of deducing function template parameters
from the type of the arguments supplied. So simply

int main(int, char**)
{
fkt(3.5);
}

john

 

[Gernot Frisch]

The C++ standard specifies that you could add the "export" keyword

before the function definition. But only a couple of compilers
support this features, and major vendors have announced that they
do not intend to implement it ... ever. (it's a long story...)

In the .h file or in the .cpp file or in both?

like this?
export template<class C>fkt(C c);

Does gcc and/or VC7.1 have export?

 

[Ivan Vecerina]

In the .h file or in the .cpp file or in both?

like this?
export template<class C>fkt(C c);

Before the function *definition* -- not the (forward) declaration.
Therefore in the .cpp file:

Does gcc and/or VC7.1 have export?

No.
Microsoft has announced that it does not intend to support export.
The rationale is that, to implement export correctly, you end up
with something excessively complex which in the end is no faster
(at compile time) than putting the implementation in the .cpp file.
AFAIK, gcc did not bother doing it either (yet?).
For an overview of the issue, see:
http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=52

The C++ compiler front end by EDG (www.edg.com) supports export, and
is used by several compiler vendors (including Comeau and Intel C++).
Comeau may still be the only one to make the feature available
(see http://www.comeaucomputing.com/4.0/docs/userman/export.html
for details).

Most people have gotten used to including template function
definitions in their header(.h) files: either in-line (à la Java)
or as an included file (e.g. #include "myfilename.tmpl.h").

When compile-time optimization is critical, some will instead keep
the function implementations separate, and use a separate source
file that explicitly instantiates required template functions...


Cheers
Ivan

 

[Greg Comeau]

The C++ standard specifies that you could add the "export" keyword
before the function definition. But only a couple of compilers
support this features, and major vendors have announced that they
do not intend to implement it ... ever. (it's a long story...)

Which major vendors have announced such a thing?

As it is today, you need to somehow include the definition of the
template function in the header (or have at least some source
file that will include the template definition and explicitly
instantiate the template).

As it is today, one can indeed do that, as well as to
also get a compiler which supports export, say Comeau C++.

 

[Greg Comeau]

Before the function *definition* -- not the (forward) declaration.

Do it in both....

Therefore in the .cpp file:
export template<class C> fkt(C c) { /* ..... */ }

.... better yet, #include the decl in the .cpp file too.

No.
Microsoft has announced that it does not intend to support export.

Where is that announcement?

The rationale is that, to implement export correctly, you end up
with something excessively complex which in the end is no faster
(at compile time) than putting the implementation in the .cpp file.

Maybe. (google many other discussions on this.)

AFAIK, gcc did not bother doing it either (yet?).

Not that I'm aware of.

For an overview of the issue, see:
http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=52

This URL was pointed out to me today, and I could not follow it,
so my $0.02 is for now to not suggest it as an overview.

The C++ compiler front end by EDG (www.edg.com) supports export, and
is used by several compiler vendors (including Comeau and Intel C++).
Comeau may still be the only one to make the feature available
(see http://www.comeaucomputing.com/4.0/docs/userman/export.html
for details).

Most people have gotten used to including template function
definitions in their header(.h) files: either in-line (à la Java)
or as an included file (e.g. #include "myfilename.tmpl.h").

Not only gotten used to, but if using a compiler which does
not support export, have no other choice!

When compile-time optimization is critical, some will instead keep
the function implementations separate, and use a separate source
file that explicitly instantiates required template functions...

That sounds painful in a general case for "non-trivial" code.

 

[Ivan Vecerina]

....
Do it in both.... ....

... better yet, #include the decl in the .cpp file too.

So export is to be used in front of the first declaration of the function
seen by the compiler. Thank you for the correction.

Where is that announcement?

I think that Herb Sutter has many a time voiced his opinion about
export, and also indicated that the feature is far for being a
priority for Microsoft and shouldn't be expected any time soon.

This URL was pointed out to me today, and I could not follow it,
so my $0.02 is for now to not suggest it as an overview.

I'm not sure what you mean by "could not follow it", but the link
seems to be working (though I probably could have picked a better ref).

A much more thorough discussion was once published in CUJ,
and I've now (searched and) found it on Herb's website:
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf

I have not seen a reply refuting/countering Herb and Tom's points,
and I would be interested in any pointers you can provide.

Not only gotten used to, but if using a compiler which does
not support export, have no other choice!

Sad truth. And unfortunately, the excellent web interface you are
making available to your compiler, which I used to test many C++
features before the compilers I had to use implemented them,
doesn't allow us to get a taste of using 'export'.

[from your other post]

As it is today, one can indeed do that, as well as to
also get a compiler which supports export, say Comeau C++.

If I dare ask, could you name other compilers that support export?
Is it trivial for users of the EDG front-end to support this feature?

I would love to see wider support for 'export' so I can use it.


With best regards,
Ivan

 

[Greg Comeau]

So export is to be used in front of the first declaration of the function
seen by the compiler. Thank you for the correction.
Yes.


I think that Herb Sutter has many a time voiced his opinion about
export, and also indicated that the feature is far for being a
priority for Microsoft and shouldn't be expected any time soon.

But saying that doesn't say they don't intent to support it,
nor that MS announced that. That said, IMO, a confusing message
has been sent by MS.

I'm not sure what you mean by "could not follow it", but the link
seems to be working (though I probably could have picked a better ref).

That I didn't find it an overview, and could not follow
the technical discussion on it.

A much more thorough discussion was once published in CUJ,
and I've now (searched and) found it on Herb's website:
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf

I have not seen a reply refuting/countering Herb and Tom's points,
and I would be interested in any pointers you can provide.

This is a partial response: http://www.comeaucomputing.com/iso/promises.html

Sad truth. And unfortunately, the excellent web interface you are
making available to your compiler, which I used to test many C++
features before the compilers I had to use implemented them,
doesn't allow us to get a taste of using 'export'.

Indeed, that has issues of its own.

[from your other post]

As it is today, one can indeed do that, as well as to
also get a compiler which supports export, say Comeau C++.

If I dare ask, could you name other compilers that support export?
Is it trivial for users of the EDG front-end to support this feature?

I would love to see wider support for 'export' so I can use it.

Same here. In the meantime, vendors are still closing in
on compliance in general, so let's see.

 

[Ivan Vecerina]

This is a partial response:
http://www.comeaucomputing.com/iso/promises.html

Thank you for this document, which makes several good points.

There are many warts in C++ that users complain about, but
I don't see template export as one of them. There is demand
for it, as the OP demonstrates. While I have no experience
with it, I do not see how it would be more difficult to use
template export than other C++ features.

It is a bit scary to see how corporate interests seem to be
absorbing much of the momentum for evolving standard C++,
somewhat bending it towards support for a specific platform.
Not that I dislike C++/CLR, but I would prefer to see focus on
improving & supporting portable C++ as a standalone standard first.

It is especially disappointing that Intel seems to have chosen
not to document and provide end-user support for template export,
even though it is actually available in the compiler they ship.

Question:
The document you linked to refers to an "in process" C++03 standard.
I guess this does not refer to "C++0x" as is being discussed
today, but to a minor revision (e.g. std lib issues).
Has this 'increment' been finalized yet, and under what name?


Long Live template export!
Ivan

 

[Greg Comeau]

Thank you for this document, which makes several good points.

There are many warts in C++ that users complain about, but
I don't see template export as one of them. There is demand
for it, as the OP demonstrates. While I have no experience
with it, I do not see how it would be more difficult to use
template export than other C++ features.

I've rarely seen anything w/o a complaint, and rarely
seen things w/o gotchas, so there is an aspect where it's
par for the course.

It is a bit scary to see how corporate interests seem to be
absorbing much of the momentum for evolving standard C++,
somewhat bending it towards support for a specific platform.
Not that I dislike C++/CLR, but I would prefer to see focus on
improving & supporting portable C++ as a standalone standard first.

I tend to agree, but can also understand the interest too.

It is especially disappointing that Intel seems to have chosen
not to document and provide end-user support for template export,
even though it is actually available in the compiler they ship.

My understanding is that they are concerned with providing
compatibility for their customers. Frankly, I think they got
that part right. But they don't seem to want to mention that
they also have others bonuses.

Question:
The document you linked to refers to an "in process" C++03 standard.
I guess this does not refer to "C++0x" as is being discussed
today, but to a minor revision (e.g. std lib issues).
Has this 'increment' been finalized yet, and under what name?

At the time it did refer to that, but since it's passed,
it doesn't That is to say, the original C++ document was
ISO/IEC FDIS 14882:1998 aka C++98. A TC has been applied since
resulting in a revised standard ISO/IEC 14882:2003, aka C++03.
At the time of promises.html that did not exist. So as there
will still be another revision, hopefully before 2010, C++0x
still remains a target.