template class creation from run-time info
Author
I have a template class that takes a number of bools
e.g.
template <bool AlphaFunc, bool BlendFunc, bool TextureBind, bool CullFace, bool DepthFunc, bool DepthMask, bool ColorMask, bool StencilFunc, bool StencilMask, bool StencilOp>
class material { /* etc */ };
Here is a link to the actual implementation.
I save on space by only creating storage for the options that are used. This has worked great when all of my materials are created at compile-time, but now I'm supporting run-time creation with the materials stored in file.
I can't think of a way to dynamically create the material class when the options are not known until run-time. I'm open to design suggestions as well as solutions to this problem.
The design would (hopefully) eliminate wasted space for unused options and retain type info.
You [afaik] can't. Templates are, by definition, compile time beasts only. No amount of black magic will allow you to specify the parameters at run time, only pick one that's already been created.
Author
Quote:Original post by Telastyn
You [afaik] can't. Templates are, by definition, compile time beasts only. No amount of black magic will allow you to specify the parameters at run time, only pick one that's already been created.
I know that. It's not a problem for classes taking few template arguments, however this one takes 10. If I want to allow the user any combination of arguments, that is a hellof a lot of specializations to do.
For instance, with a much easier class: (this was typed in post, not compiled or tested)
if (token == "true"){ ref.reset(new material<true>); // Load options}but the problem grows HUGE with more template parameters. I don't even want a meta-program to generate it for me because it would explode compile times.
[Edited by - mfawcett on August 31, 2005 5:19:51 PM]
Store a pointer to each one and make it null if that attribute is not required.
We're talking a maximum of 40 unused bytes here.
A single 256*256 RGBA texture = 262144 bytes
So in the space needed to store 1 modest sized texture you could store 6553 materials.
Presumably you'd be attaching a texture to each material. Why are you worried about possibly wasting 40 bytes? Even if all your materials were known at compile time, you're still heavily abusing the type system, which will cause problems later, for non real benefit.
We're talking a maximum of 40 unused bytes here.
A single 256*256 RGBA texture = 262144 bytes
So in the space needed to store 1 modest sized texture you could store 6553 materials.
Presumably you'd be attaching a texture to each material. Why are you worried about possibly wasting 40 bytes? Even if all your materials were known at compile time, you're still heavily abusing the type system, which will cause problems later, for non real benefit.
Quote:Original post by mfawcett
I can't think of a way to dynamically create the material class when the options are not known until run-time. I'm open to design suggestions as well as solutions to this problem.
The design would (hopefully) eliminate wasted space for unused options and retain type info.
One way to do it at run-time might be to have pointers in the material class pointing to the various data allocated elsewhere. Pointers for disabled features would be 0.
The real question is this: How much wasted space do you expect to eliminate? Even with 1000 materials, you are going to save less than 100 Kbytes. Is it even worth all the effort?
Well, with 10 boolean options that gives you 2^10=1024 possible combinations, which not only gives you 1024 different structures it also means all the code that uses them will need to be duplicated 1024 times unless you use virtual functions (which I think would be a very bad idea here). So you can either use pointers to each material type (but remember memory allocation overhead, which is ~8 bytes per alloc for a good allocator), or just stick all the properties into one big class and have a bit mask to indicate valid ones since none of them are that big anyway.
Author
Quote:Original post by Nitage
Presumably you'd be attaching a texture to each material. Why are you worried about possibly wasting 40 bytes? Even if all your materials were known at compile time, you're still heavily abusing the type system, which will cause problems later, for non real benefit.
(The class I linked to has since been changed, but in actuality it ranged from 4 to 74 bytes.)
I've considered not worrying about the space, and will probably go with a run-time version of the class.
Quote:Original post by ZQJ
Well, with 10 boolean options that gives you 2^10=1024 possible combinations, which not only gives you 1024 different structures it also means all the code that uses them will need to be duplicated 1024 times unless you use virtual functions (which I think would be a very bad idea here). So you can either use pointers to each material type (but remember memory allocation overhead, which is ~8 bytes per alloc for a good allocator), or just stick all the properties into one big class and have a bit mask to indicate valid ones since none of them are that big anyway.
I had gotten around that particular problem you mentioned, but yes, it does make working with the material a bit of a pain.
Basically:
template <bool>struct uses_alpha_func{ template <typename T> void apply(const T &) const { }};template <>struct uses_alpha_func<true>{ template <typename T> void apply(const T &a) const { glAlphaFunc(a.af_func, a.af_ref); }};
That's still going to cause code duplication isn't it? Since you'll have to have one set of code that calls the <true> version and one that calls the <false> version. That is, if I understand what you're doing.
Author
Quote:Original post by ZQJ
That's still going to cause code duplication isn't it? Since you'll have to have one set of code that calls the <true> version and one that calls the <false> version. That is, if I understand what you're doing.
Oh yea, definitely. I was just saying the programmer didn't actually have to do the duplication, the compiler could.
I muat be being stupid BUT why are u declaring so many bools in your template when you just have to declare 1?
What are trying to achiveve? The whole point of templates is RUNTIME so you didn't have to do that when you knew how muany you'd ned at comille time. If you have veridiac runtime argumentents with tempaltes then Fruny is THE MAN...or you could just use the standard sytanx.?
What are trying to achiveve? The whole point of templates is RUNTIME so you didn't have to do that when you knew how muany you'd ned at comille time. If you have veridiac runtime argumentents with tempaltes then Fruny is THE MAN...or you could just use the standard sytanx.?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
