Sign in to follow this  
PrincessDaisy

Typecasting Performance Question

Recommended Posts

In my application I currently have seperate functions to create the resources (for example CreateTexture, CreateIndexBuffer, CreateSample etc.), and each of these functions returns a pointer to the resource created. Now this works fine, but internally it is a bit of a mess. The application has to keep track of all the resources, and there are a lot of different types, so there are a lot of different functions, making it difficult to maintain and update. Im thinking of replacing the seperate functions with a single function CreateResource, that returns a pointer to the resource's base class. texture = (CTexture*)CreateResource(EResource_Texture); I am concerned about the use of the typecast, as now there will be a lot of type casts (internally, the game will save a pointer to the resources base class also, so when updating and deleteing etc, it will need to typecast also). Will having a large number of typecasts be a performance issue, or will it not be noticable? Having a cleaner internal structure is important to me, but a faster application is of more importance. Any advice or information would be useful here. Thanks Daisy

Share this post


Link to post
Share on other sites
well at first you won t load tons of resources at runtime right? only in the beginning so typecasts shouldn t hurt


another thing i want to mention, in assembly you don t have any other types than byte, short, word and long and casting your baseclass pointer to another subclass pointer just tells the compiler how to tread the memory your pointer refers to its just plain data

so i dont think that it hurts at all performance wise as long as your compiler uses optimization

i dont know how it virtual functions are implemented in c++ but other than that i see no reason why it should hurt performance

maybe it speeds your code up a little bit because you reduce the amount of instructions stored in the binary, but this should be pretty OS depentant

Share this post


Link to post
Share on other sites
Quote:
Original post by Basiror
well at first you won t load tons of resources at runtime right? only in the beginning so typecasts shouldn t hurt


At the moment yes, all resources are loaded at run time, but as it is a streaming application, it might be, in the future, that resources are loaded as and when, so resources could be loaded during runtime if needed.

But what I am concerned about is the internal updates. For example, animating textures are updated automatically within the application. Now that textures will be stored as CBaseResource's, then each and every frame needs to be type casted, and this is the performace issue I could be concered about.

Thanks
Daisy

Share this post


Link to post
Share on other sites
I'm pretty sure it won't have any effect.

You are typecasting different types of pointers... but a pointer is still just a number. When you cast between fundamentally different types such as ints and floats, a converstion must be done as the same number is stored differently in a float. With pointers, there is no such conversion taking place.

The type of pointer you are dealing with is handled at compile time and is integrated automatically with vptr tables for each derived class. So typecasting is not actually an operation in this case. When you invoke any abstract methods on the class CTexture, a check will be done to determine the correct function to call (in the correct subclass). I think that might add a little overhead but it is probably negligable.

That is a really common thing to do so I wouldn't worry about it even if there were some overhead. If it greatly simplifies the design, then go for it. Also, unless you are doing it thousands of times per second, don't even think about it anymore.

I could be wrong though... anyone else?

Share this post


Link to post
Share on other sites
Quote:
Original post by PrincessDaisy
Im thinking of replacing the seperate functions with a single function CreateResource, that returns a pointer to the resource's base class.

texture = (CTexture*)CreateResource(EResource_Texture);


Don't use C style casts in C++, for one thing C style casts do not work on polymorphic types when casting at runtime, use the C++ family of cast operators, in particular dynamic/static_cast for polymorphic types.

Quote:
Original post by PrincessDaisy
I am concerned about the use of the typecast, as now there will be a lot of type casts (internally, the game will save a pointer to the resources base class also, so when updating and deleteing etc, it will need to typecast also).


I smell a design stench.

Quote:
Original post by PrincessDaisy
Will having a large number of typecasts be a performance issue, or will it not be noticable?


There are different kinds of casts, in C++ there are different cast operators which you should be using, the one that may cost noticeable preformance is dynamic_cast because it can traverse a type hierarchy at runtime, you can think of it as DAG traverser. The efficiency of dynamic_cast depends on the platform on some the cost may be negligible but on others painfully noticeable, in other words you need to profile to find out.

dynamic_cast is used when you have no idea what the type is referred to by a pointer/reference to super-type so it will nearly always cost you something, however if your 100% sure what the type is then you can use static_cast which has no cost at run-time but your program will most definitely crash if your wrong about what the type is.

Really though your design smells bad to me.

[Edited by - snk_kid on July 18, 2005 4:51:14 AM]

Share this post


Link to post
Share on other sites
Since your'e doing a "throw the type system out the window" style cast using the C-cast sledgehammer it won't cost you anything but loads of debugging time and potentialy henious type-errors at runtime.

Now some people (like me) would call that quite a high cost to pay for a bad design, but the runtime cost will be zero. If you internaly want to keep track of all reasources that's nice use a common base for that but don't force it down the throat of your clients.

I would strongly advice you to keep your type-safe factory methods that you have or if you somehow do thing that it's a sane idea to have a singe CreateResource function at least then induce typesafety using checked dynamic_cast.

And deletion through base pointer shoulnd't be a problem as long as you remember to declare the destructor virtual (else you'll summon the beast of undefined behaviour).

Generally when working in C++ loosing (too much) type-information can be a really bad thing, or smell.

Share this post


Link to post
Share on other sites
Quote:
Original post by PrincessDaisy
Quote:
Original post by Basiror
well at first you won t load tons of resources at runtime right? only in the beginning so typecasts shouldn t hurt


At the moment yes, all resources are loaded at run time, but as it is a streaming application, it might be, in the future, that resources are loaded as and when, so resources could be loaded during runtime if needed.

But what I am concerned about is the internal updates. For example, animating textures are updated automatically within the application. Now that textures will be stored as CBaseResource's, then each and every frame needs to be type casted, and this is the performace issue I could be concered about.

Thanks
Daisy


as i already said your pointer is just a address to some memory and the type of the pointer tells the compile what operations to perform so there shouldn t be any performance decrease

Share this post


Link to post
Share on other sites
Quote:
Original post by snk_kid
Really though your design smells bad to me.


Ok... What smells so bad?

I'll give you an overview of the design and you can tell me what you suggest.

Each resource is stored within a list, so the application can keep track of all loaded resources. So we have a texture list, index buffer list etc.

Currently, I have a large number of these lists, as the list stores a pointer to all the resources so for example

List<CTexture*>
List<CIndexBuffer*> etc.

Some of these resources need to be updated per frame (anaimating textures is an obvious example), and this shouldnt be up to the front end, so internall, we have a loop calling Update for each texture.

When we call CreateTexture, CreateIndexBuffer etc. the new resource is added to the appropriate list, and the resource is returned.

So far, what is the problem?

With a new structure, I would have a larger array of lists, instead of a long list of seperate lists.

List<CBaseResource*> resources[No_Resources];

When CreateResource is called, then the resource is created and added to te appropriate list (referenced via the enum). And the base resource is called.

Obviously, the Updates and Draws still need to be called and this is where the type case comes in.

Now if this sucks, please explain why. The lists are currently seperated into controlling classes, and handled quite will (though not very elegantly, which is why I am suggesting the new system). If you can justify your response I will be more than willing to listen to any suggestions.



Thank you for the advice on the static/dynamic casting though, as this is something I have not have any experience with.

Thanks
Daisy

Share this post


Link to post
Share on other sites
Quote:
Original post by Basiror
Quote:
Original post by PrincessDaisy
Quote:
Original post by Basiror
well at first you won t load tons of resources at runtime right? only in the beginning so typecasts shouldn t hurt


At the moment yes, all resources are loaded at run time, but as it is a streaming application, it might be, in the future, that resources are loaded as and when, so resources could be loaded during runtime if needed.

But what I am concerned about is the internal updates. For example, animating textures are updated automatically within the application. Now that textures will be stored as CBaseResource's, then each and every frame needs to be type casted, and this is the performace issue I could be concered about.

Thanks
Daisy


as i already said your pointer is just a address to some memory and the type of the pointer tells the compile what operations to perform so there shouldn t be any performance decrease


If you do anything like that then your asking for trouble, as i already mentioned C style cast can not do type conversions at run-time, its not for polymorphic types, it does not understand/care what they are. C style casts in C++ typically are (depending on the context) equivalent to static_cast, reinterpret_cast, or const_cast.

dynamic_cast is a type DAG traverser it can traverse a hierarchy of related types at runtime and in some simple cases it will do it at compile-time. It will inform you if a traversal fails by returning 0 for pointers or throws a bad_cast exception for references. The cost of dynamic_cast depends on the platform, it maybe negliable or painfully noticeable you need to profile to find out.

Like said before generally don't use C-style casts in C++

Share this post


Link to post
Share on other sites
Could you please explain the reasoning behind thinking that keeping one gigantic list with all resources and type-switching on each entry would somehow be advantageous to keeping fine grained lists and in a type safe manner processing only exactly thos elements that need to?

The old system from a design point at least is type-safe and efficent whereas the new proposed system throws type information right out the window would require potentially expensive operations later to regain it and doesn't provide any clear benefit that I can see.

What are your problems with the current system? Having to many lists? Duplicating behaviour?

Share this post


Link to post
Share on other sites
Quote:
Original post by DigitalDelusion
Could you please explain the reasoning behind thinking that keeping one gigantic list with all resources and type-switching on each entry would somehow be advantageous to keeping fine grained lists and in a type safe manner processing only exactly thos elements that need to?

The old system from a design point at least is type-safe and efficent whereas the new proposed system throws type information right out the window would require potentially expensive operations later to regain it and doesn't provide any clear benefit that I can see.

What are your problems with the current system? Having to many lists? Duplicating behaviour?


I do like the fine grain lists, and the system I am proposing is not one gigantic lists. The lists would be the same size, but instead of having 10 seperate lists

List<CTexture*>
List<CSample*>

It would be 10 lists, but referenced by an enum

List <CResourceBase*> resources[ENum_Resources];

So i would still be processing only those resources that need it, and not having to switch though _all_ the resources to update the odd few.

Now the reason I am looking into this is because I have approx.30 different resource types (textures and index buffers etc., but also models, instances, and then GUI objects like list boxes, combo boxes, progress bars etc.) All these are currently creates using Create<Insert Name>(...);

Along side the create function, I have a Cycle<Insert Name>(..) which allows you to cycle through all the resources of a give type, and a Delete<Insert Name>(..) which deletes it.

Now with that system I have approx 90 functions for all resources, if I want to change a behaviour, I have to change 90 functions.

No before you probably go crazy, I dont have 90 functions on one class.

All Gui create functions are in the CGuiController class, all texture create functions (there are differen types of textures) are part of the CTextureController class.

By having one function CreateResource(...) (and obviously DeleteResource and CycleResource) i am hoping to cut down greatly on the amount of duplicated code, and make the system (IMO) more elegant and much easier to alter.

This obviously has the draw back of needing a type casting.

That is the reason I posted this idea as a suggestion, and wanted people feedback. Some people will like it, some won't, thats why I asked for suggestions.

Daisy

Share this post


Link to post
Share on other sites
Quote:
Original post by PrincessDaisy
Quote:
Original post by snk_kid
Really though your design smells bad to me.

Ok... What smells so bad?


The fact that you wrote that you will be doing alot of super-sub type casts which will result in mostly using dynamic_cast, worse still you wrote that you need to cast when doing updates and deleteing!?!

Anyways if you have many super-sub type casts this is generally a sign of bad design, a sign of a brittle, rigid system. I'm not saying that super-sub type casting is avoidable in all cases but if you are doing it alot then something not is not quite wright.

Quote:
Original post by PrincessDaisy
With a new structure, I would have a larger array of lists, instead of a long list of seperate lists.

List<CBaseResource*> resources[No_Resources];


Whats with the array of lists for? please don't tell me each list represents a different resource because if thats the case then it appears you do not understand inheritance and/or sub-type polymorphism.

If this truely is the case you are replacing separate lists each of a particular type, rich in type info for array of lists of pointers to a base resource type where each list also represents a different type yet you disregard type by storing pointers to base [looksaround].

Quote:
Original post by PrincessDaisy
When CreateResource is called, then the resource is created and added to te appropriate list (referenced via the enum). And the base resource is called.


I think this statement kind of clarifies what i thought and just wrote. Also the idea of "CreateResource" function might smells, why? that idea entails type switching syndrome within that function. Read up about object factories so you don't end up down that road of pain.

Quote:
Original post by PrincessDaisy
Obviously, the Updates and Draws still need to be called and this is where the type case comes in.


[attention], did you mean type cast? if so, there is one simple solution sub-type polymorphism via virtual member functions, another alternative is visitor design pattern.


Quote:
Original post by PrincessDaisy
If you can justify your response I will be more than willing to listen to any suggestions.


Some suggestions would be read up about design patterns in particular:


  • Proxy

  • Factory Method & Abstract Factory

  • Observer Pattern

  • Template Method

  • Visitor



Actually you may aswell them all, lots of resources about them online (get the GOF book best thing to do).

Further suggestions, read about smart pointers and reference counting, did you know C++ comes with standard library that contains containers & algorithms such as std::list i suggest you read about them and generally use those in production type code check here, check out C++ boost library (link in my signature) believe me do it.

Share this post


Link to post
Share on other sites
Quote:
Original post by snk_kid
The fact that you wrote that you will be doing alot of super-sub type casts which will result in mostly using dynamic_cast, worse still you wrote that you need to cast when doing updates and deleteing!?!


According to what you stated earlier, and from what I have just been reading, I would not need a dynamic cast, as I know what the pointer is, and that using a static_cast would be fine.

Quote:
Original post by snk_kid
Whats with the array of lists for? please don't tell me each list represents a different resource because if thats the case then it appears you do not understand inheritance and/or sub-type polymorphism.


Why do I not understand inheritance or polymorphism? If I have 25 textures loaded and 13 index buffers, of course I want them stored in seperate lists, so that when I search for a texture, or when I wish to update all the textures, I only need to go through a smaller lists.

If they were stored within a larger array, i would have to go through all resources and update only the ones I am interested in.

Quote:
Original post by snk_kid
If this truely is the case you are replacing separate lists each of a particular type, rich in type info for array of lists of pointers to a base resource type where each list also represents a different type yet you disregard type by storing pointers to bass.


Quote:
Original post by snk_kid
I think this statement kind of clarifies what i thought and just wrote. Also the idea of "CreateResource" function might smells, why? that idea entails type switching syndrome within that function. Read up about object factories so you don't end up down that road of pain.


I admit there would be a switch statement here. But FYI, currently my objects are created via object factories. I added simplified code in my examples, whereas in fact the "lists" are extended factory patterns that create, store and check (using reference counting) resources, and return the needed resources.

Quote:
Original post by snk_kid
did you mean type cast?


Yes, sorry for the typo

Quote:
Original post by snk_kid
if so, there is one simple solution sub-type polymorphism via virtual member functions, another alternative is visitor design pattern.


Most of the time this is fine, as Update, for example, only takes _frameDelta as a variable. A few objects OTOH, take more functions. If I did use my idea, I would try to change this as much as possible, so I could use a virtual update function. But on some rare cases, this may not be possible.

Surpisingly I do know how inheritance and polymorphism works, and use it quite extensivly in my application, and would use it here is I possibly could.

Quote:
Original post by snk_kid
Some suggestions would be read up about design patterns in particular:


  • Proxy

  • Factory Method & Abstract Factory

  • Observer Pattern

  • Template Method

  • Visitor




Of the above design patterns, the only one I do not know off is the visitor pattern (and I'm not to hot on the Proxy one either), and will look into them. But having my code critiqued for being rigid and brittle, then reeling of some rigid (and at times) unsuitable (not just here) design patterns doesnt strengthen your argument.

Quote:
Original post by snk_kid
Further suggestions, read about smart pointers and reference counting, did you know C++ comes with standard library that contains containers & algorithms such as std::list i suggest you read about them and generally use those in production code check here, check out C++ boost library (link in my signature) believe me do it.



I do use and understand referencing counting, and smart pointers. This question was not inregards to the storage of duplicated resources, as that is handled already within the factort classes.

I am also aware of the std::list (all all other features of the std library), but as I mentioned above, I dont actually use List, it was just to simplify the question.
I have looked into boost, and decided against using it (I do use a lot of external libraries in my application and try to keep it to a minumum, and so far, nothing in Boost is vitally important within my app.)

Daisy

Share this post


Link to post
Share on other sites
Just throwing out an idea, to reduce all that typing getting rid of the list (or whatever) declarations and keep things tidy have you considred an approach like this:

#include <iostream>
#include <list>

class Daisy{};
class Dandelion{};

class FlowerFactory
{
//VC6 is crap, this can probably be made with a function if the compiler conforms a bit better
template <typename T>
struct list
{
static std::list<T*>& get(void)
{
static struct holder: std::list<T*>
{
~holder(void)//do some cleanup
{
if( !empty())
std::cerr << "leak detected:" << size() << " objects not deleted\n";
}
}l;
return l;
}
};
template <typename T>
static T* add(T* p)
{
list<T>::get().push_back( p);
return p;
}
public:
Daisy* createDaisy(void){ return add( new Daisy());;}
Dandelion* createDandelion(void){ return add( new Dandelion());}
};

int main(void)
{
FlowerFactory ff;
ff.createDaisy();
ff.createDandelion();
ff.createDaisy();
//hopefully two leaks will be detected with correct counts..
return 0;
}



this has the added benefit of lists not being created unless they're actually used, delete and cycle would be simple variations of the add method.

Could be worth considering.

Share this post


Link to post
Share on other sites
I'm sorry if that sounded offensive or something i'm not trying to be. The thing is i don't know what you know, your level of knowledge is etc so i can only infer and make assumptions from what you've written that time.

Share this post


Link to post
Share on other sites
To answer the original question: I don't know if your casting system is a good idea design-wise, but either way, isn't worrying about the performance of casting at this stage a little premature?
Anyway, since you know the type of an object (from the enum), you can use static cast, which should have almost no overhead, as it just lets the compiler know there is a different type of object at that offset.

Share this post


Link to post
Share on other sites
Quote:
Original post by snk_kid
Quote:
Original post by Basiror
Quote:
Original post by PrincessDaisy
Quote:
Original post by Basiror
well at first you won t load tons of resources at runtime right? only in the beginning so typecasts shouldn t hurt


At the moment yes, all resources are loaded at run time, but as it is a streaming application, it might be, in the future, that resources are loaded as and when, so resources could be loaded during runtime if needed.

But what I am concerned about is the internal updates. For example, animating textures are updated automatically within the application. Now that textures will be stored as CBaseResource's, then each and every frame needs to be type casted, and this is the performace issue I could be concered about.

Thanks
Daisy


as i already said your pointer is just a address to some memory and the type of the pointer tells the compile what operations to perform so there shouldn t be any performance decrease


If you do anything like that then your asking for trouble, as i already mentioned C style cast can not do type conversions at run-time, its not for polymorphic types, it does not understand/care what they are. C style casts in C++ typically are (depending on the context) equivalent to static_cast, reinterpret_cast, or const_cast.

dynamic_cast is a type DAG traverser it can traverse a hierarchy of related types at runtime and in some simple cases it will do it at compile-time. It will inform you if a traversal fails by returning 0 for pointers or throws a bad_cast exception for references. The cost of dynamic_cast depends on the platform, it maybe negliable or painfully noticeable you need to profile to find out.

Like said before generally don't use C-style casts in C++


I assumed he knows the objecttype his pointer refers to so a c style cast doesn t matter

in general i am of the opinion that a experienced programme doesn t need this extra casting operators introduced into c++ as long as his design is decent enough to determine which object type his pointers refer to


if you have a look at the 3dsmax source code they have a memberfunction inherited in all objects derived from the base node class ("don t know its name anymore") which returns a unique class id and in the examples i have seen they use pure C style casts

not to mention that the original C++ didn t have these casting operators, they were introduced somewhen later

also in which case do i really need a dynamic cast?

i hope you don t write code where you use dynamic cast to check for types, for this case i d prefer the approach with the unique class id as a virtual memberfunction inherited from the base class on


or can you tell me any reason to use dynamic_cast at all if you can solve this issue with the approached mentioned above?

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
To answer the original question: I don't know if your casting system is a good idea design-wise, but either way, isn't worrying about the performance of casting at this stage a little premature?


The application has been in development for near on 2 years now, and even though this is a fundamental change, the creation process it abstracted enough to make it nto effect the main application code in a serious way.

So no, its not too premature, as it has to be done sometime or another, and I may as well do it now whilst I have the spare time (if i decide to do it anyway)

Quote:
Original post by snk_kid
I'm sorry if that sounded offensive or something i'm not trying to be. The thing is i don't know what you know, your level of knowledge is etc so i can only infer and make assumptions from what you've written that time.


Not offensive at all, and yes I do know a little bit more than I showed at the beginning, but the question was about the use of type casting, so going into great depth on the structure of my internal resource creation wasn't really needed.

But thanks for the information on static/dynamic_casts. I am in the process of changing the casts over now.

Daisy

Share this post


Link to post
Share on other sites
An answer to your question:

static_cast - overhead of running the conversion function (single parameter constructor or conversion operator).

reinterpret_cast - no overhead, just tells the compiler to treat a variable differently,.

const_cast - no overhead, same as reinterpret cast

dynamic_cast - overhead of dynamically checking the actual type of the object pointed to.


Your c style cast on a pointer will have no overhead, but you should be using a reintrepret cast (since you already know that the pointer is of the correct type).


That's the answer to your question, but you should really listen to the people that are saying that this kind of thing is a symptom of bad design.

Share this post


Link to post
Share on other sites
Quote:
Original post by Basiror
I assumed he knows the objecttype his pointer refers to so a c style cast doesn t matter


Well it kinda of does, the cast operators are intentionally explicit and ugly for a very good reason, in this case you would use static_cast even if you did use dynamic_cast it will likely do upcasts at compile-time anyways plus you have the gaureentee of safety.

Quote:
Original post by Basiror
in general i am of the opinion that a experienced programme doesn t need this extra casting operators introduced into c++ as long as his design is decent enough to determine which object type his pointers refer to


Yes you do need them, C style cast not only be ambiguous its not type safe for polymorphic type casts period, this is what dynamic_cast is for.

I think your opinion is poor and i think its time to update you're knowledge with all the articles that tell you not to use C style cast and why not to, for example this article.

Quote:
Original post by Basiror
if you have a look at the 3dsmax source code they have a memberfunction inherited in all objects derived from the base node class ("don t know its name anymore") which returns a unique class id and in the examples i have seen they use pure C style casts


So it sounds like they've just reimplementated a poor mans basic RTTI with no runtime type safety, its sounds like who ever did that lacks knowledge of C++, for example all C++ types (built-in, user-defined etc) have type ID associated called std::type_info with them and a reference to them is obtainable via typeid operator which is an amortized constant time operation and can work at compile-time aswell as run-time and in some cases with out the need of RTTI on.

Besides the point:

would you jump off a cliff/building if 3dsmax did? probably not.
Does 3dsmax define the C++ standard? no.

Quote:
Original post by Basiror
not to mention that the original C++ didn t have these casting operators, they were introduced somewhen later


They where in the standard when C++ was first standardized in 1998.

Quote:
Original post by Basiror
also in which case do i really need a dynamic cast?


Depends on the context, typically if you *needed* to super-sub type cast and you don't know exactly what the type is referred to by a reference/pointer to super-type then that is when to use dyanmic_cast.

Quote:
Original post by Basiror
i hope you don t write code where you use dynamic cast to check for types, for this case i d prefer the approach with the unique class id as a virtual memberfunction inherited from the base class on


[headshake] *sigh*, regarding checking for types read about my comment on std::type_info and operator typeid, dynamic_cast removes the need for type checking before doing casts and will inform you if the cast will fail.

In any case i try to write code where i don't need to do any checking of type or super-sub type casts as much as possible in the first place.

Quote:
Original post by Basiror
or can you tell me any reason to use dynamic_cast at all if you can solve this issue with the approached mentioned above?


I think what i've wrote should answer that one.

[Edited by - snk_kid on July 18, 2005 4:43:43 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Nitage
Your c style cast on a pointer will have no overhead, but you should be using a reintrepret cast (since you already know that the pointer is of the correct type).


I would say prefer static_cast because the compiler will do basic type checking at compile time, reinterpret_cast completely disregards type, in a sense its a blind cast, unsafe. Besides the cost of conversion for static_cast from one pointer/reference to another is insigificant/negligible.

Share this post


Link to post
Share on other sites
so i read the article about the c++ cast operators and it convinced me not a bit
the examples we used to show the advantages of C++ cast operators are just plain stupid, so stupid that no experienced programmer would ever write this in his code

the only difference so far is that you have to write more code in order to do the same


and the C style cast is not deprecated, which is also stated in the article you posted

Quote:
se new cast operators. Originally, the C++ standardization committee wanted to deprecate C-style cast. However, because C-style cast is widely used in legacy code and because many C++ compilers serve as C compilers too, the committee decided not to do so.



i certainly won t blow my code with those ugly looking cast operators for something i don t need because my code is solid enough to get on without them

these operators are a tool for noobie c++ programmers who don t know how to convert a char to an integer

and as already stated in the article, they just move the responsibility back from the compiler to the programmer

unneeded feature, if they insist on it that why don t they implicitly replace C style casts with their c++ casts at compile time, you can determine whether you need a static const reinterpret or dynamic cast at compile time, other than that i see no reason to use it in a solid cost base, automate it or let it be

Share this post


Link to post
Share on other sites
Quote:
Original post by Basiror
so i read the article about the c++ cast operators and it convinced me not a bit


Okay that was a bad article i didn't actually read it myself the point was there are lots of them, so how about from a more reliable source such as GOTW by Herb Sutter.

At the end of the day its your opinion but you are on your own with it.

Share this post


Link to post
Share on other sites
I've been using C-style casts ever since I started with C++ (apart from that bit I'm sure everyone goes through with a massive if statement attempting dynamic casts on a base class object :p). Reading this thread just changed my mind, however. Using C++-style casts is worth it IMO, if only to be standards-compliant.

On topic, if the OP is indexing all his resources with strings, I'd recommend storing a container (suggest hash table/character tree) of base resources, whilst still providing explicit Find(name) functions. Of course, if your resource manager is completely concrete, you could provide templated resource functions and dynamically cast within the manager to check if the named resource is the correct type. These suggestions come from a viewpoint that a resource manager should store/manage resources without caring about their type, however, which may not be your own.

EDIT: The templated version would be fairly similar to your:

texture = (CTexture*)CreateResource(EResource_Texture);

instead being stated as:

texture = CreateResource<CTexture>();

same with finding resources:

texture = FindResource<CTexture>("some_texture_name");

[Edited by - Tim Cowley on July 18, 2005 4:46:48 PM]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this