Quote:Original post by Mike.Popoloski
The first is the C++ version, while the second is the old C-style version. You should prefer the first, since it is more explicit in what it is doing. With the C version, you could end up doing reinterpret casts, const casts, and static casts, whereas with the C++ versions you are explicit about what you want it to do, which means it's easier for the compiler to help catch errors for you.

The C-style casts are completely safe for casts between basic types or removing signed-ness, etc. The split functionality for C++ casts is a good idea, except that they intentionally have an annoying syntax because the language creators believed that casts should never be used. A small example of personal style considerations getting in the way of language usefulness.

For casts between integral or floating point types I always use C-style casts or the constructor cast syntax, both of which are deprecated in C++. There's no point in being pedantic about it when it's much cleaner and totally safe if you restrict your usage of C-style casting to simple conversions between builtin types.

For casting pointers, though, you should always use the C++ style casts unless you're absolutely positive that the C-style casts work as expected in your specific case.

Quote:Original post by TheTroll
for (float x = 0.0f; x < Width - 3.0f; x+= 1.0f)
{
for (float z = 0.0f; z < Height - 3.0f; z += 1.0f)

There is no reason you can not use floats for this.

theTroll

Double post, I apologize, but this isn't recommended at all. Floating point comparisons are slow on many processors, so if you feel you *need* to do something like this it's best to get into the habit of doing something a little different:

float f = 0.0f;for (int i = 0; i < Width; i++, f+= 1.0f){   // ...}

Casting the ints to floats to pass to the function is fine, but if you can cleanly do something like the above it's likely to be much much faster than casting on any processor where load-hit-store is an issue... and probably slightly faster everywhere else.

Quote:Original post by Promit
Fix all of them, and then turn on warnings as errors. That's the only way you'll ever learn.

I could not agree more.

Also, if you're using MSVC++, turn off those dumbass warnings about the C library being insecure. It's hilarious that Microsoft tries to cram their "replacement" library down the throats of programmers -- and yet there are still buffer overflow bugs in their new software. Apparently either a) their programmers don't use the "replacement" library, or b) the "replacement" library is no more secure than the C library. Either way, using their "replacement" library immediately renders one's code compatible only with MSVC++, which is just plain bad since it's avoidable in this case.

Quote:Original post by taby
Also, if you're using MSVC++, turn off those dumbass warnings about the C library being insecure. It's hilarious that Microsoft tries to cram their "replacement" library down the throats of programmers -- and yet there are still buffer overflow bugs in their new software. Apparently either a) their programmers don't use the "replacement" library, or b) the "replacement" library is no more secure than the C library. Either way, using their "replacement" library immediately renders one's code compatible only with MSVC++, which is just plain bad since it's avoidable in this case.

Their "replacement library" has been submitted for standardization, and is a decent idea, though I don't like the implementation of the exception handler.

Anyway, might as well learn to live with the *_s functions (or embrace and use them), because they'll probably be standard C at some point in the future. You can macro them to work on other platforms without a whole lot of trouble.

Really, though, unless you absolutely know what you're doing the C string manipulation functions are worth avoiding. Professional programmers often screw up and use them in a way that allows one (or more) byte buffer overflows. Probably because strncpy, strncat, snprintf all work slightly differently and require different precautions to protect from buffer overflow. The _s versions might not be the perfect solution, but at least someone is trying to address the problem.

I know I am not a great programmer, so in general I assume the compiler people know much more about C++ than me. Turning on level 4 warnings is annoying at first, but will save you lots of headache later on.