Originally Posted by
winrawr 
Should I avoid casting between data types?
As a general rule, yes you should.
Originally Posted by
winrawr I haven't really seen much about the use of this, but it seems like one of those last-minute-no-way-around kind of methods... but, for example, how would I use the length of a string in a for loop? The length property of a string is size_t, and if I had an integer i in a loop, how could I do that?
An implicit conversion exists between int and size_t so, in rough terms, you shouldn't need an explicit conversion between them.
Note "explicit conversion" is actually the more correct name for a "cast".
In practice, the conversion can lose information (signed to unsigned, and different variable sizes), so several compilers will emit a warning when doing that conversion. If (and I repeat
if) you know that conversion is valid, you can safely ignore the warning messages. If you can't tolerate warning messages from compilers, then an explicit conversion generally has the side effect of stopping the compiler complaining. That has the disadvantage that it also stops the compiler from emitting complaints that you should really address properly.
However, if you can guarantee the conversion is safe (i.e. you know that the value of the size_t variable can be stored in an int) a technique is;
size_t end = whatever();
for (int i = 0; i < (int)end; ++i)
loop_body();
Originally Posted by
winrawr Where would casting be useful?
Explicit conversions are useful when you
know a conversion is safe and the compiler considers the conversion erroneous (i.e. it emits and error message and refuses to continue) or suspicious (i.e. it emits a warning message, even if continues to compile).
An example is that, in C++, it is necessary to convert the return from malloc() to a pointer of an appropriate type. While it is usually better to employ operator new instead, an explicit conversion can be a simpler way. The flip side of this conversion is that it can also be used to permit an invalid conversion: for example, the return from malloc() shouild
never be converted to a pointer to a non-POD class (in rough terms, a non-POD class is a class that has declared constructors, assignment operators,a destructor, or any virtual function).
An explicit conversion is also useful - rarely - to resolve ambiguity. Such ambiguity can occur with C++ classes that supply multiple conversion operations. [The better strategy is to ensure that no class supports multiple conversions].
Originally Posted by
winrawr Where should I avoid it?
As I said above, you should avoid it whenever possible. Where practical, an alternative should be found. The explicit conversion needs to be viewed as an absolute last resort.
Originally Posted by
winrawr What are other methods of dealing with different data types that are better than cast?
Generally, it comes down to design.
Instead of using the C malloc() function, use C++'s operator new.
Avoid writing classes that support multiple conversion operations (eg operator SomeType() members). Instead, write functions that the programmer must explicitly call to do the required (and intended) conversion. This is the reason, for example, that std::string supports the c_str() member function and does not support a direct conversion to (const char *).
In C++, make use of the _cast<> operators (const_cast, static_cast, dynamic_cast, reinterpret_cast) if you really have to, and avoid the C-style cast. And avoid using the _cast<> operators as well, if at all practical.
As a rough rule, you should never need to perform an explicit conversion from a base class to a derived class (or conversion of such pointers or references). The need to do this can, almost always, be eliminated by careful class design. For example, the base class probably needs to be polymorphic (i.e. provide virtual functions that can be over-ridden by the derived classes).