template metaprogramming

is there a way to make so i dont have to call the following with the
extra ::val portion?

template<int r, int g, int b>
struct RGB {
static const int val = 65536 * r + 256 * g + b;
};

ie RGB<50,100,150> instead of RGB<50,100,150>::val

Mark wrote:[color=blue]
> is there a way to make so i dont have to call the following with the
> extra ::val portion?
>
> template<int r, int g, int b>
> struct RGB {
> static const int val = 65536 * r + 256 * g + b;
> };
>
> ie RGB<50,100,150> instead of RGB<50,100,150>::val[/color]

You don't "call" it. You probably use it in an expression. If it is
an expression that expects an int, you can do

template<int r, int g, int b>
struct RGB {
operator int() const { return 65536 * r + 256 * g + b; }
};

and use it like

int a = RGB<50,100,150>();

V

templates do not have to evaluate expressions until they are actually
instantiated. So just decarling typedef RGB<100,1,1> my_fav_color;
does not assign a value to val. When val is actually referenced, then
it is evaluated.
In any case, how would you use the calculated value without accessing
"val"???

Victor Bazarov,

well. i meant use in an expression... it's similar to a function in
some sense, even if it doesnt operate the same way (ie, it's
precomputed).

anyways RGB<50,100,150>() is no better than RGB<50,100,150>::val ...
i'm just trying to be lazy, and it looks ugly :\

lancedid...@nyc.rr.com,

how would you use the calculated value without accessing
"val"???

well.. i suppose that's what im asking.

RGB<50,100,150> is only supposed to "return" a single value. so there
is no ambiguity between it returning ::val or ::coconut.

i'm wondering if there is another way to write the template so that it
automatically produces this value... without having to assign it to
some dummy variable first such as val.

and what exactly would
typedef RGB<100,1,1> my_fav_color
do??? would you have to use it like my_fav_color::val or what?

On 2005-11-16 02:44, Mark wrote:[color=blue]
> is there a way to make so i dont have to call the following with the
> extra ::val portion?
>
> template<int r, int g, int b>
> struct RGB {
> static const int val = 65536 * r + 256 * g + b;
> };
>
> ie RGB<50,100,150> instead of RGB<50,100,150>::val[/color]

Wouldn't it be better as a function?

inline int RGB(int r, int g, int b)
{
return 65536 * r + 256 * g + b;
}

And then when using it you replace the < and > with ( and ) and it's all
you wanted, ie. RGB(50, 100, 150).

Erik Wikström
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup

Erik Wikström wrote:[color=blue]
> On 2005-11-16 02:44, Mark wrote:
>[color=green]
>> is there a way to make so i dont have to call the following with the
>> extra ::val portion?
>>
>> template<int r, int g, int b>
>> struct RGB {
>> static const int val = 65536 * r + 256 * g + b;
>> };
>>
>> ie RGB<50,100,150> instead of RGB<50,100,150>::val[/color]
>
>
> Wouldn't it be better as a function?
>
> inline int RGB(int r, int g, int b)
> {
> return 65536 * r + 256 * g + b;
> }
>
> And then when using it you replace the < and > with ( and ) and it's all
> you wanted, ie. RGB(50, 100, 150).
>
> Erik Wikström[/color]

As a function it's not a compile time constant. Why the OP would want an
RGB value as a compile time constant I'm not sure but maybe there's a
reason.

Of course the other option is a macro

#define RGB(r, g, b) (65536*(r) + 256*(g) + (b))

Now it's a compile time constant and you have the convenient syntax.

john

Erik,
as John said, it's not compile time constant.

John,
that's not compile time either. that just replaces any occurance of
RGB(r, g, b) with (65536*(r) + 256*(g) + (b)), it still has to do the
calculations in run time.

Why do I want it during compile time? Because I'm never going to use
any variables, only constants...

Oh well. Just wondering if there was a better way. Thanks guys.

On 2005-11-16 19:02, Mark wrote:[color=blue]
> Erik,
> as John said, it's not compile time constant.
>
> John,
> that's not compile time either. that just replaces any occurance of
> RGB(r, g, b) with (65536*(r) + 256*(g) + (b)), it still has to do the
> calculations in run time.
>
> Why do I want it during compile time? Because I'm never going to use
> any variables, only constants...
>
> Oh well. Just wondering if there was a better way. Thanks guys.[/color]

If you are not going to use _any_ variables then you should be able to
hardcode the value directly.

Erik Wikström
--
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure
out how to use my telephone" -- Bjarne Stroustrup

Mark wrote:[color=blue]
> Erik,
> as John said, it's not compile time constant.
>
> John,
> that's not compile time either. that just replaces any occurance of
> RGB(r, g, b) with (65536*(r) + 256*(g) + (b)), it still has to do the
> calculations in run time.[/color]

Not if you are using constants for the values of r, g and b. RGB(0, 0,
0) is a compile time constant.

[color=blue]
>
> Why do I want it during compile time? Because I'm never going to use
> any variables, only constants...[/color]

So RGB will give a compile time constant.
[color=blue]
>
> Oh well. Just wondering if there was a better way. Thanks guys.
>[/color]

Perhaps you need to quote the code you say doesn't compile. You must be
doing something wrong.

john

Erik Wikström wrote:[color=blue]
> If you are not going to use _any_ variables then you should be able to
> hardcode the value directly.[/color]

Well. I could. But I'd have to do it for many values... not a huge
deal, was just curious.

John Harrison wrote:[color=blue]
> Not if you are using constants for the values of r, g and b. RGB(0, 0,
> 0) is a compile time constant.[/color]

Hm.. so it doesn't actually perform any calculations during run
time...?
It won't attempt to do (65536*(0) + 256*(0) + (0)) when the program is
run, but actually pre-determine the answer is 0?

That's interesting. Wish there was a way to test that out...

But yes, I shall use this then.

So, in theory, I could do

#define RGB(r, g, b) (65536*(r) + 256*(g) + (b))

and then do

#define WHITE RGB(255,255,255)

and it will replace all occurences of "WHITE" with 16777215?

[color=blue]
> Perhaps you need to quote the code you say doesn't compile. You must be
> doing something wrong.[/color]

Hm? Did I say something doesn't compile?

Mark wrote:[color=blue]
> Erik Wikström wrote:
>[color=green]
>>If you are not going to use _any_ variables then you should be able to
>>hardcode the value directly.[/color]
>
>
> Well. I could. But I'd have to do it for many values... not a huge
> deal, was just curious.
>
>
> John Harrison wrote:
>[color=green]
>>Not if you are using constants for the values of r, g and b. RGB(0, 0,
>>0) is a compile time constant.[/color]
>
>
> Hm.. so it doesn't actually perform any calculations during run
> time...?
> It won't attempt to do (65536*(0) + 256*(0) + (0)) when the program is
> run, but actually pre-determine the answer is 0?
>
> That's interesting. Wish there was a way to test that out...[/color]

Easy, array bounds in C++ must be compile time constants (at least in a
standard conforming compiler). So try this

char x[RGB(0, 0, 1)];

When that compiles (which it will) it proves that RGB with constant
values produces compile time constants.
[color=blue]
>
> But yes, I shall use this then.
>
>
> So, in theory, I could do
>
> #define RGB(r, g, b) (65536*(r) + 256*(g) + (b))
>
> and then do
>
> #define WHITE RGB(255,255,255)
>
> and it will replace all occurences of "WHITE" with 16777215?[/color]

Correct.
[color=blue]
>
>
>[color=green]
>>Perhaps you need to quote the code you say doesn't compile. You must be
>>doing something wrong.[/color]
>
>
> Hm? Did I say something doesn't compile?
>[/color]

You were so confident that you were right, I thought you must have tried
to compile something.

john

John Harrison skrev:
[color=blue]
> Mark wrote:[color=green]
> > Erik,
> > as John said, it's not compile time constant.
> >
> > John,
> > that's not compile time either. that just replaces any occurance of
> > RGB(r, g, b) with (65536*(r) + 256*(g) + (b)), it still has to do the
> > calculations in run time.[/color]
>
> Not if you are using constants for the values of r, g and b. RGB(0, 0,
> 0) is a compile time constant.[/color]

Just wanted to add that it does not matter if you use an inline
function or a macro here - unless you need a compile time constant. On
all real-world compilers the inline function will be replaced by a
constant value (no run-time overhead).

/Peter[color=blue]
>
>[color=green]
> >
> > Why do I want it during compile time? Because I'm never going to use
> > any variables, only constants...[/color]
>
> So RGB will give a compile time constant.
>[color=green]
> >
> > Oh well. Just wondering if there was a better way. Thanks guys.
> >[/color]
>
> Perhaps you need to quote the code you say doesn't compile. You must be
> doing something wrong.
>
> john[/color]

oh. well then. i guess i learned something about my compiler today :)
very nifty.

thanks guys. so there was a better solution than RGB<1,2,3>::val after
all.
[color=blue]
> You were so confident that you were right, I thought you must have tried
> to compile something.[/color]

oh. i see what you were getting at now. didn't realize i just shot your
point down without looking into it. sorry John :) you were right.