template constructor

[Christof Warlich]

Hi,

is there any way to instantiate class A through
this constructor? I'd like to pass the value as
a template parameter instead of a constructor
argument for performance reasons. It will be part
of a very performance-critical library and the
parameter will always be known at compile time.

Thanks for any help,

Christof

#include <iostream>
class A {
public:
template<int x> A(void) {
std::cout << x << std::endl;
}
};
int main(void) {
// A a<27>; // does not work
}

 

[Ondra Holub]

Hi,

is there any way to instantiate class A through
this constructor? I'd like to pass the value as
a template parameter instead of a constructor
argument for performance reasons. It will be part
of a very performance-critical library and the
parameter will always be known at compile time.

Thanks for any help,

Christof

#include <iostream>
class A {
public:
template<int x> A(void) {
std::cout << x << std::endl;
}};

int main(void) {
// A a<27>; // does not work

}

I think it is not possible. However you can define some init function,
which is templetized and set all values in it. Or you can define
derived class, which is template class parametrized with int and do
all init stuff there.

 

[Michael DOUBEZ]

Christof Warlich a écrit :

Hi,

is there any way to instantiate class A through
this constructor? I'd like to pass the value as
a template parameter instead of a constructor
argument for performance reasons. It will be part
of a very performance-critical library and the
parameter will always be known at compile time.

Thanks for any help,

Christof

#include <iostream>
class A {
public:
template<int x> A(void) {
std::cout << x << std::endl;
}
};
int main(void) {
// A a<27>; // does not work
}

You might want something along:
#include <iostream>
class A
{
public:
template<typename INTPARAM>
A(const INTPARAM&)
{
std::cout << INTPARAM::x << std::endl;
}
};

template<int value>
struct param
{
static const int x=value;
};

int main(void)
{
A a(param<27>());
}

The unnamed parameter is likely to be optimized out.

I have my doubts about your performance issue.

Michael

 

[Christof Warlich]

I think it is not possible. However you can define some init function,
which is templetized and set all values in it.

Yes, that will do the job. Thanks.

 

[Victor Bazarov]

is there any way to instantiate class A through
this constructor? I'd like to pass the value as
a template parameter instead of a constructor
argument for performance reasons. It will be part
of a very performance-critical library and the
parameter will always be known at compile time.

Thanks for any help,

Christof

#include <iostream>
class A {
public:
template<int x> A(void) {
std::cout << x << std::endl;
}
};
int main(void) {
// A a<27>; // does not work
}

For a templated constructor, the type (or value) deduction has to
happen from the argument. Since you don't have any arguments for
your constructor, it's impossible to provide the template argument
or make the compiler deduce it.

It sounds like you're trying to optimize your code before you know
it's going to be a performance hindrance. Knuth says, "Premature
optimization is the root of all evil". Take it to heart.

Give your constructor an integer argument. Unless you can prove
that in your final program having a constant in the code is better
than having a single integral value passed to the constructor as
its argument (and it better be _significantly better_) you are
wasting your valuable time.

Oh, BTW, drop the 'void' from the empty argument lists. An empty
list should be _empty_. This C-ism has no place in a C++ program
written from scratch.

V

 

[Christof Warlich]

I have my doubts about your performance issue.

Probably you are right. However, it still somewhat bothers me that the
compiler allows me to define a construct that cannot be accessed without
even issuing a warning. Anyhow, the templated init function suggested by
Ondra will be fine to deal with my performance paranoia.

 

[Victor Bazarov]

[..] Anyhow, the templated init function
suggested by Ondra will be fine to deal with my performance paranoia.

<sigh> Actually, you're going to be treating the symptom, which is
only going to hide the problem. Let the compiler optimize the int
argument for you. Suppress the desire to use templates and make the
constructor inline (define it in the class). That will give the
compiler the opportunity to do exactly what you want when you simply
use a constant to initialise your object.

V

 

[Christof Warlich]

For a templated constructor, the type (or value) deduction has to
happen from the argument. Since you don't have any arguments for
your constructor, it's impossible to provide the template argument
or make the compiler deduce it. Thanks for confirming this.

It sounds like you're trying to optimize your code before you know
it's going to be a performance hindrance. Knuth says, "Premature
optimization is the root of all evil". Take it to heart.

Quoting Knuth is always a good argument. So I certainly will take it
to heart.

Give your constructor an integer argument. Unless you can prove
that in your final program having a constant in the code is better
than having a single integral value passed to the constructor as
its argument (and it better be _significantly better_) you are
wasting your valuable time.

Eliminating the function parameter saved 2 CPU cycles in a 30 CPU
cycles buffer allocation routine. Probably not worth to accept poor
code, but but worth to ask.

 

[Victor Bazarov]

[..]
Eliminating the function parameter saved 2 CPU cycles in a 30 CPU
cycles buffer allocation routine. Probably not worth to accept poor
code, but but worth to ask.

Yes, if all that your program does is initialising of those objects,
then saving 2 of 30 CPU cycles in the constructor means overall 6%
improvement. Now, consider *the entire* program. How much of your
program's *entire* execution is spent in that constructor? 0.1%?
Or even 0.01%? Now, you've managed to improve *that* by another 6%.
Good. What does it mean to the overall program execution? It got
faster by 0.006% (or by 0.0006%)? Optimize what *really matters*.

It takes a certain effort to pull away from those "easy pickins"
and not to waste time on a solution to a non-existing problem. Get
into habit of (a) using the right algorithms, (b) first making
your program work, and only then making it fast, and (c) use the
right tools for every job. Base your decisions on data, not on
guesses.

V

 

[Rolf Magnus]

[..]
Eliminating the function parameter saved 2 CPU cycles in a 30 CPU
cycles buffer allocation routine. Probably not worth to accept poor
code, but but worth to ask.

Yes, if all that your program does is initialising of those objects,
then saving 2 of 30 CPU cycles in the constructor means overall 6%
improvement. Now, consider *the entire* program. How much of your
program's *entire* execution is spent in that constructor? 0.1%?
Or even 0.01%? Now, you've managed to improve *that* by another 6%.
Good. What does it mean to the overall program execution? It got
faster by 0.006% (or by 0.0006%)? Optimize what *really matters*.

If you write a program that does a batch calculation, that argument is
valid. But many programs (like e.g. GUI programs) are event driven. In that
case, you often don't care how much percentage of the whole execution time
some specific function takes, but rather how quickly you react to the
event.

 

[Michael DOUBEZ]

Christof Warlich a écrit :

[snip]
Give your constructor an integer argument. Unless you can prove
that in your final program having a constant in the code is better
than having a single integral value passed to the constructor as
its argument (and it better be _significantly better_) you are
wasting your valuable time.

Eliminating the function parameter saved 2 CPU cycles in a 30 CPU
cycles buffer allocation routine. Probably not worth to accept poor
code, but but worth to ask.

Was your constructor inilined ?
Which flags did you use ?

Before modifying your code, it is worth to have a look into those
issues. I may be wrong but I wouldn't expect much overhaed for an
optimized variable; I suspect that tuning your compiler will save you a
lot of time.

Michael

 

[Victor Bazarov]

[..]
Eliminating the function parameter saved 2 CPU cycles in a 30 CPU
cycles buffer allocation routine. Probably not worth to accept poor
code, but but worth to ask.

Yes, if all that your program does is initialising of those objects,
then saving 2 of 30 CPU cycles in the constructor means overall 6%
improvement. Now, consider *the entire* program. How much of your
program's *entire* execution is spent in that constructor? 0.1%?
Or even 0.01%? Now, you've managed to improve *that* by another 6%.
Good. What does it mean to the overall program execution? It got
faster by 0.006% (or by 0.0006%)? Optimize what *really matters*.

If you write a program that does a batch calculation, that argument is
valid. But many programs (like e.g. GUI programs) are event driven.

So, for an event driven program the argument to optimize what *really
matters* is _invalid_; is that what you're saying?

In that case, you often don't care how much percentage of the whole
execution time some specific function takes, but rather how quickly
you react to the event.

I was talking not about the elapsed time (which is of course huge in
GUI-driven programs), but of the CPU time. And if you want to talk
reacting to an event, then 2 CPU cycles won't make a difference, in
most cases. To understand the need to optimize a certain part of the
application, you still *need to time that part*. It does not matter
whether it's 100%, from process startup to closing, or it's a tiny
fraction taken by responding to an event.

Arguing about it won't change the fundamental problem with the OP's
approach - optimize the constructor without even *knowing* how much
it's contributing to the execution time. I think you would agree
that even reacting to an event cannot be a single call to a class
constructor (or a million of single calls to the class constructor).
It's got to be something more. That something often makes a huge
difference.

And if the OP comes back saying that he wanted to optimize a million
calls to the constructor _in a row_ and thus cared about the 6%, I
would immediately ask for the details because initialising 1M objects
with hard-coded values should most likely not be done one by one, but
in a loop, or with a memset, or some such. So, we're back to a few
objects whose initialisation is scattered across tons of other code.
Need I continue?

V