next »

[increpare]

As a hacky but not dissatisfying side-step around template instantiation, I'm putting my function template declarations directly in headers in anonymous namespaces

header.h:

Code:

namespace {
    template<class T>
    T whatever(T t)
    {
        return t;
    }
}

[/s]

Ignore me.

[Average Software]

As a hacky but not dissatisfying side-step around template instantiation, I'm putting my function template declarations directly in headers in anonymous namespaces

header.h:

Code:

namespace {
    template<class T>
    T whatever(T t)
    {
        return t;
    }
}

What exactly are you trying to accomplish with that?  I don't see the point.

[increpare]

What exactly are you trying to accomplish with that?  I don't see the point.

The standard alternative would be

header.h:

Code:

template<class T>
T whatever(T t);

header.cpp

Code:

template<class T>
T whatever(T t)
{
return t;
}

template
int whatever<int>(int t);

template
float whatever<float>(float t);

// et cetera ad nauseam

[ Some websites seem to recommend including the C++ file at the bottom of the .h file, but that doesn't work if you have the same header included in different c++ files - get link problems with duplicate symbols. ]

I guess I could also stick it inside of a class as a static member function.

But your questioning makes me feel very uncertain indeed.

[Average Software]

Is there a reason why you want explicit instantiations rather than the standard implicit ones?  That is, what's wrong with just doing this:

header.h:

Code:

template <typename Type>
Type whatever(Type type)
{
    return type;
}

And simply not having a .cpp file?

I don't think that anonymous namespace is doing what you think it's doing, it may actually be generating several redundant instantiations that the linker can't remove, since they occur in different namespaces and are technically different templates.  You probably don't want that.

[Crimsontide]

Hmm... I'm a bit confused, wouldn't this work?

Code:

template<class T> T whatever (T t);
// later a the bottom of the header file, or perhaps in another header file...
template<class T> T whatever (T t) { return t; }

or just

Code:

template<class T> T whatever (T t) { return t; }

I don't see why adding it to a namespace (anonymous or otherwise) would change anything.

edit: beaten to it ; )

[increpare]

Code:

template <typename Type>
Type whatever(Type type)
{
    return type;
}

If I include the .h file in different .cpp files I get duplicate symbol errors.

[Average Software]

Code:

template <typename Type>
Type whatever(Type type)
{
    return type;
}

If I include the .h file in different .cpp files I get duplicate symbol errors.

You shouldn't, templates (and inline functions) are allowed to exist is multiple translation units.  Are you including the instantiations in the header file too?

Code:

template <typename Type>
Type whatever(Type type)
{
    return type;
}

// Explicit instantiations.
template
Type whatever<int>(int);
template
Type whatever<float>(float);
// These should generate duplicate symbol errors.

The only things you've posted that could lead to duplicate symbol errors are the explicit instantiations.

I guess my real question is why you're using the explicit instantiations in the first place, I believe you're using those incorrectly, and that's the source of your troubles.

[increpare]

You shouldn't, templates (and inline functions) are allowed to exist is multiple translation units.

You're right.  I was getting confused because I had a mixed batch of template and regular functions and wasn't expecting non-uniform behaviour.

Thanks.

[Crimsontide]

If you want to include normal (non-template) functions in a header file, just use inline.

Code:

inline void SomeFunctionICantBeBotheredToPutInCppFile () { /* stuff here */ }

edit: beaten to it again by average ; (

[baconman]

Presently trying to do some scriptable path-editing (in GM at the moment), and was wondering how I'm gonna pull something off...

I've got some intricate webs of paths in mind, and was going to use a trimming system, in conjunction with variables like moving platforms and/or pattern-based critters, by removing certain paths and setting a preferred rotation direction, and then having their movements based on the remaining paths; but I'm a bit stuck on how to pull that off.

For instance:

Code:

+-+-+-+-+
| | | | |
+-+-+-+-+
| | | | |
+-+-+-+-+
| | | | |
+-+-+-+-+
(fig. 1)

+-+ +-+-+
| | | | |
+-+ +-+-+
| |   | |
+-+ +-+-+
| | | | |
+-+ +-+-+
(fig.2)

Figure 1 illustrates the initial path-web; which begins with an object of interest (critter, platform, etc.) in corners, that travel in a primary direction (clockwise or counterclockwise). 5 sub-paths are then removed (randomly) to produce figure 2. The effect I'm hoping to achieve is for the object(s) of interest to then travel around the perimeter - so the things on the left will cycle around in a square kind of pattern, where the things on the right would "trace around the reversed C."

Anybody know how I might implement this kind of effect?

There's a few other kinds of verticies as well, such as 45-degree angles and interconnected circular pathways in more sophisticated patterns as well. (Like, take the "5" pattern on a die, make the circles fuller and evenly spaced, and interconnect the edges vertically and horizontally with each other, as well as diagonally through the central circle.)

[Skomakar'n]

Hm, I think it's more enjoyable when the compression from lots of lines of moderately complex code turns into one line of very complex code rather than turning into one line of easy code. It makes you feel less like an idiot.

Indeed. This still has to be my favourite line of all I've ever written:

Code:

T *tmp = new T[(trueSize / 2 >= -- filledSize && trueSize > 8) ? (trueSize /= 2) : trueSize];

[psy_wombats]

Indeed. This still has to be my favourite line of all I've ever written:

Code:

T *tmp = new T[(trueSize / 2 >= -- filledSize && trueSize > 8) ? (trueSize /= 2) : trueSize];

That's like art right there.

[bateleur]

That's like art right there.

In the same way that Damien Hirst's pickled sheep is art.

[muku]

Hm, I think it's more enjoyable when the compression from lots of lines of moderately complex code turns into one line of very complex code rather than turning into one line of easy code. It makes you feel less like an idiot.

Indeed. This still has to be my favourite line of all I've ever written:

Code:

T *tmp = new T[(trueSize / 2 >= -- filledSize && trueSize > 8) ? (trueSize /= 2) : trueSize];

To be honest, I think that's bad code. It's so obfuscated that you won't know what it's doing in a few months' (weeks'?) time, not to mention what another programmer who reads your code will think of it (hint: hard feelings will be had). This single line manages to mix up a conditional, side effects (--, /=), and an allocation; that's just nasty and a maintenance nightmare. Split it out over a few lines, use well-named temporaries, and maybe comment it. Just stuffing as much stuff as you can into one code line doesn't make for good code.

[Skomakar'n]

I wrote this more than six months ago, and it is commented (but I still understand it even without the comments).