Thread: Code::blocks 'undefined reference' error

The tutorial is garbage.
Besides, I would recommend you get a C++ GUI framework such as Qt instead of doing pure Win32 programming. It's easier and it's faster.

Some advice:
- Don't use new when you don't need to. If you can away with not doing it, then do that. In this case, it's pointless.
- Stay away from C functions. They are Evil™. wsprintf can cause buffer overflows. Learn to use stringstreams instead. You can get a C-style string from std::string by calling .c_str(). This allows you to pass it to certain APIs that require C-style strings.

Originally Posted by Elysia

Don't use new when you don't need to

Done - New removed.

Originally Posted by Elysia

Stay away from C functions. They are Evil™.

Saying things like that will make me disregard your other good advice :P

Originally Posted by Elysia

Learn to use stringstreams instead

As I said earlier, after I have finished the tutorial I will.

Originally Posted by Elysia

wsprintf can cause buffer overflows.

Can, but not always. Unless %s is used, I'm not going to worry about a buffer overflows -
This appears in the WM_CHAR signal handler, so we know wParam is of a char datatype, so wsprint's output has a predictible length.

This should be fine

Code:

wsprintf(w_str, "ch = %c", wParam);

Originally Posted by whiteflags

The Forger is a better resource for WinAPI stuff at any rate

That is an awesome link, whiteflags - Thanks a lot for that.

Originally Posted by Click_here

Can, but not always.

the fact that it can ever cause a buffer overrun is cause to never ever use it.

Originally Posted by Click_here

Unless %s is used, I'm not going to worry about a buffer overflows

I suspect you simply cannot be convinced. make sure you let us know what publicly released software projects you end up working on some day, so that we can all avoid them.

the simple fact is that if your tutorial is claiming to teach you C++, but it's telling you to use (w)sprintf and other C-style string handling functions, it's an awful tutorial. ditch it immediately. it is just simply wrong to use those functions in C++.

the fact that it can ever cause a buffer overrun is cause to never ever use it.

Look at the example I gave: The char array was declared large enough, so there is no way that that can cause a buffer overflow.

make sure you let us know what publicly released software projects you end up working on some day, so that we can all avoid them.

That's offensive - A clear personal attack that was uncalled for.

Originally Posted by Click_here

Look at the example I gave: The char array was declared large enough, so there is no way that that can cause a buffer overflow.

The fact that it can produce a buffer overflow and that you do no checks to make sure it does not is enough to make it dangerous. Oversizing buffers is not a solution. It's a hack and a workaround.

That's offensive - A clear personal attack that was uncalled for.

I wouldn't take that as an offence. But it does bring a point home. If you continue to rely on unsafe C functions, your program will not be safe. We don't want that. So take it to heart and avoid them. Join the C++ community and transition to safer alternatives.

Originally Posted by Elkvis

the fact that it can ever cause a buffer overrun is cause to never ever use it.

If you follow that logic fully, you will avoid using most of the C and C++ standard libraries.

It is possible, accidentally or deliberately, to overrun a buffer with any function or operation that uses pointers, indices into arrays, indices into containers, or iterators.

Even a simple function that is designed to be safe, like fgets(), can achieve a buffer overrun.

Code:

    char buffer[5];
    fgets(buffer, 10, some_file_pointer)

I think what you intended to say is "You should not use code constructs where the programmer cannot deliberately achieve ANY safe mode of operation".

The wsprintf() %s format can be used safely, since the programmer can control length of both the buffer being written to and the string being written using %s. Admittedly, that means other constraints on those lengths need to be enforced separately. But, once those constraints are enforced, wsprintf() with the %s format is guaranteed safe (unless the implementation of wsprintf() does not conform with behaviour required by the standards).

The (deprecated/removed) gets() function is one where the programmer has no means in code to achieve ANY safe mode of operation. That is, more or less, the reason gets() was deprecated and removed from the latest C standard.