Jump to content
  • Advertisement
Sign in to follow this  
Telastyn

Templating and functor questions

This topic is 4907 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

As few may know, I've been delving into the stl, templates, and things connected to them as of late. Anyways, I've some questions regarding tought processes I guess regarding them. What should the condition be for different uses? I mean... For normal inheritance the common explination is "Does the seconadary class meet the "Is a" relationship to the first class?". Do template classes and functions follow some similar sort of guidelines? I find far too often when I move from the relatively straightforward things to practical use, I end up designing myself into a corner. Often this shows itself when I want a common object without requiring templating. Something like...
struct foo{
    functor bar;
    foo(functor inbar):bar(inbar){}
}
But then I can't get the functor to take a member function, as the class the member function is a part of requires templating, requiring the parameter to be functor<> bar instead and it's just all a big mess. Anyways, I figure it's just a trick I'm missing, or I'm thinking about the things in the wrong way... I'm not sure. It's just such slow going when all of the online examples I've found deal with definition more than use. And it's just frustrating because I've already done this functionality in other ways. I made assumptions and within those assumptions my previous solution works well. Alas, I know it's not the best solution though, especially seeing how effortlessly some around here use the features. Hrm. And of course after the ranting I think of a possible solution. So, things like this are perhaps solved via something like... erm...
struct functor{
    //virtual stuff
};

template <typename T>
struct functor2: functor{
    // redefine virtual stuff
};
That still seems terribly messy for something which shouldn't be. And then requires pointers rather than just an object... and bleh. Back to fiddling around...

Share this post


Link to post
Share on other sites
Advertisement
Combining inheritance and templates can be a powerful tool if used right. Regarding the need for a generic functor abstraction, you have the right idea there, but someone has already done the dirty work for you: Boost.Function.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
Anyways, I've some questions regarding tought processes I guess regarding them. What should the condition be for different uses? I mean... For normal inheritance the common explination is "Does the seconadary class meet the "Is a" relationship to the first class?". Do template classes and functions follow some similar sort of guidelines?


Well i don't think there is just one guideline, you can do more than one paradigm with templates some of which you can apply both at compile-time and run-time!. This means a change of mindset when using each one.

In generic programming you have the notion of concepts the term is very important that its even a technical term used in the c++ standard and there is even a proposal to make concepts a first-class entity in the language (i think that is the correct terminology).

A concept is a set of requirements imposed by a generic component on one or more of its arguments in some ways its simillar to interfaces but has more to it than a type that implements/supports a set of *known* interfaces for example it can specifiy time complexity guarantees like "this operation must take logarithmic time..".

A type or group of types (be it user-defined or built-in ones) that satisfy a concept's requirements is said to model the concept or to be a model of the concept, for example STL have a set of concepts one of which is the concept of a Sequence, std::list satisfies the requirements of the Sequence concept and is there-for a model of a Sequence.

One concept can be a refinement of another concept there-for its a superset of the other concept, which is simillar to one interface extending another one an example of this is STL's Associative Container concept which is a refinement of the Container concept, std::map is a model of the Associative Container concept and is there-for a model of the Container concept.

for types to be a model or a *manifestation* of a concept there are no requirements that a type or group of types must implement a set of known interfaces or be related to some other type(s) in an inheritance relationship.

To enforce concept requirements that are beyond that of the compiler's comprehension you use generic constraints or concept checking which in C++ at the moment requires library support such as in boost libraries and some implementors of STL use there own concept checking to prevent you from doing something that will make your program go into an undefined state. Note this costs them and you nothing except maybe a little compilation time and its enforced at compile-time by the compiler not a run-time. As i menitioned early there is a proposal to make concepts and concept checking be a feature of the language itself.

I think the notion of concepts is very intuitive, its how i tend to think about things when i'm solving a problem regardless of generic programming or not, i tend to think "What are the fundamental concepts in this problem domain?"

Another paradigm for example is when you work in the land of compile-time meta-template programming which is similar to pure functional programming that requires another slight change in mindset.

Your last question as already mentioned you might wanna look up boost::function its being considered to be part of the standard library and if i remember correctly was entered into the recent technical library review (TR1) i'm guessing its std::tr1::function.

[Edited by - snk_kid on March 15, 2005 7:48:33 PM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!