Jump to content
  • Advertisement
Sign in to follow this  
e-milio

C++ Casting Overloading problems...

This topic is 4426 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

Hi, i'm working on a dynamic Array for my "little" game engine on C++ & DirectX, my array class uses a template and has an interface similar to this definition: class CArray { private: T *ptrT; public: operator const T *() const { return ptrT; } T &operator[](unsigned i) const { ... return *(ptrT + i); } ... } The first overload, a cast to T* overload, is trying to give a more flexible and "compatible" type. For example, many functions from STL that uses strings as parameters would specified a char pointer, so if T = char, then i can use this explicit cast overloading to call any of this functions with my own CArray variables as parameters. The second overload is the intuitive index call for any vector, where parameter i returns a reference to the element in the i-position of the array. And now, the problem, the compiler throws this error, at the first call of the operator []: "error C2666: '[]' : 2 overloads have similar conversions" I know that the ptrT index to the first element of the array, that is the same as ptrT[0], but this idea seams not to be working for my class in the [] overloading. For example, if i comments the first overload (operator const T *() const...), and try: CArray<char> string; char *ptrChar = string; or CArray<char> to; CArray<char> from; strcpy(to, from); ... Compiler shows this error: "cannot convert from 'class CVector<char>' to 'char *'" (what i was trying to avoid or solve at the beginning with the overloading: "operator T *() const...", so i don't know ¿???). ... finally i can't use my own type directly over any other API function or just give my own library a sort of "independency" or reusability... :( I hope you can help, giving me a clue or any other different way to obtain the same functionality with the array. PD: I'm using this 2 overloads operators with the exactly syntax as Daitel made it in his book, but unfortunaly, he never use both together in any example... e-milio

Share this post


Link to post
Share on other sites
Advertisement
If you define an operator T*, it will be automatically used for array indexing. So you can't define operator[].

Share this post


Link to post
Share on other sites
Hello,

My first advice: since you are creating a dynamic array class in order to use it in a project, I strongly suggest you to use std::vector<> instead.

Second, your [] overload should either return a T (or const T&) or be non-const. The correct solution might be to write two versions of []:

const T& operator[] (int i) { return ptrT; }
T& operator[] (int i) { return ptrT; }


I would also encourage you to limit the use of automatic casts - despite their apparent convenience, they may have side effects that can be very hard to debug. For example, what will happen if you do this:
CArray<char> string;
// ...
if (string == "str") {
// do something
}

Will you compare the strings of will you compare the pointers?

If you want to gain access to a const version of the internal data, I suggest you to add a little functions (similar to the data() method of std::string).

Regards,

Share this post


Link to post
Share on other sites
Why are you not using std::vector/deque?, sorry but there is no excuse here, use it and move on. I can already see a deficiency in your custom dynamic array type compared to std::vector.

You can't have an overload of a conversion operator and an overload of subscript operator together and invoke them implicitly without having disambiguates, the compiler has no idea which one to use without more information. You can invoke them explicitly but then it becomes pointless in having an implicit conversion to begin with.

User-defined implicit conversions are nasty in general anyways, they can lead to subtle bugs.

[Edited by - snk_kid on March 30, 2006 3:29:18 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Barius
If you define an operator T*, it will be automatically used for array indexing. So you can't define operator[].

No, this is just the fault of his compiler. In a compliant compiler, overloading operator[] would be perfectly fine.

I would also avoid overloading casting in that manner anyway though, in favor of being more explicit, but it's up to you.

Share this post


Link to post
Share on other sites
Quote:
Original post by snk_kid
Why are you not using std::vector/deque?, sorry but there is no excuse here, use it and move on. I can already see a deficiency in your custom dynamic array type compared to std::vector.


...std::vector is not what i'm looking for... as some time ago my Computer Graphics Teacher at university told me, not all computer game codes are a magnificent example of software perfection (and i have noticed this based on some experience of reading codes from real engines)... if you say reinventing the wheel?... ok it could be but in some cases software engineering "allow" (in a world full of APIs and fourth generation languages...) to make your specific solution to your own well-known problem.

Quote:
You can't have an overload of a conversion operator and an overload of subscript operator together and invoke them implicitly without having disambiguates, the compiler has no idea which one to use without more information. You can invoke them explicitly but then it becomes pointless in having an implicit conversion to begin with.

User-defined implicit conversions are nasty in general anyways, they can lead to subtle bugs.


I agree about, this vector is not at the top of encapsulation, abstraction, or any of the strength form Object Programming Paradigm you want... danger of returning a pointer to the internal data of a class, as Daitel told, is a tricky way of jumping encapsulation, then you take it, assuming consequences, or you leave it... but that the strength of Cpp, up to be an Object Oriented Programming Language you can continue doing low level operations.

Share this post


Link to post
Share on other sites
Quote:
Original post by Polymorphic OOP
Quote:
Original post by Barius
If you define an operator T*, it will be automatically used for array indexing. So you can't define operator[].

No, this is just the fault of his compiler. In a compliant compiler, overloading operator[] would be perfectly fine.

I would also avoid overloading casting in that manner anyway though, in favor of being more explicit, but it's up to you.


I agree with you, conceptually the overloading of [] operator must work as an essential cast to a pointer to the first element of the vector... i'm going to tray another compiler than MS VS 6.0... two well-known problems with the compiler, the scope of variable from a for definition and some disadvantage in template uses... ¿God bless Microsoft?... mmmm... who knows???

Share this post


Link to post
Share on other sites
A friend, as some of you did, suggested me to use only the definition of: "operator const T *() const...", all works perfectly for the:

CArray<char> string;
char *ptrChar = string;

or

CArray<char> to;
CArray<char> from;
strcpy(to, from);

NOTE: only over Linux running GCC compiler (not win - MS VC... yet again Microsoft compiler get involved...)

but... one problem from this sol, it's based on the fact that you can't control the index call over the array, and that is something i'm looking for my class to check... at least on my code, where i will always use [] operator to access elements instead of a direct pointer manipulation (in others code, just trust, like: strcpy call...).

I think i will use a getPtr function or something like that, despite the fact that isn't a very intuitive way... sorry about the delay on answering your messages to my post, i was extremely busy at university!!!

Thanks to all of you for replaying the post...

bye.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!