[RESOLVED] are raw pointers really bad?

[Feoggou]

When I started learning C++ long ago there was no STL (or at least the books I've learnt from) and also new did not throw any exception on failure.

The problem is that I got to love raw pointers, while the smart pointers (like the auto_ptr class) look as if it transforms C++ to C# or something.

Do I really need to stop using them? Or they are usefull sometimes?

[Lindley]

When I started learning C++ long ago there was no STL (or at least the books I've learnt from) and also new did not throw any exception on failure.

The problem is that I got to love raw pointers, while the smart pointers (like the auto_ptr class) look as if it transforms C++ to C# or something.

Do I really need to stop using them? Or they are usefull sometimes?

First, don't use auto_ptr. It's not all that good as smart pointers go because its behavior can be counterintuitive (what looks like a copy is actually move semantics). But if you have access to the newer smart pointer types (either in TR1 or from Boost), then you should absolutely know how they work.

However, smart pointers are not the answer to everything. First of all, you should avoid using pointers more than necessary. Non-owned pointers aren't really a problem, but in many cases a reference will work as well or better because you don't have to check it for NULL.

The majority of your need for dynamic allocation should disappear if you use STL containers to their full potential. The remaining time when dynamic allocation is necessary is primarily when dealing with polymorphic objects of non-scoped lifetimes. For such things, I would definitely recommend smart pointers.

One time when it would be acceptable to use raw pointers would be in the private internals of a class. So long as the outside world doesn't need to know the details, and you can be absolutely certain you've handled the copying and moving semantics of the class properly, you can take advantage of the slight boost in speed that raw pointers give over smart pointers. But that's not a common case.

[Feoggou]

And what do you think about raw string vs STL's string? Though you sometimes write a bit more when using raw strings, I think the speed and flexibility is higher than using the STL's string. So that makes me think that I should better use the raw strings (and allocate the size dinamically), or perhaps, though I didn't become my custom, I can create a class for a 'raw' string with only a constructor and a destructor.

By the way, the constructors and destructors are not inline, right?

And, when creating two objects of a class C, and the class C has the functions doX(), doY() and doZ(), there is only one copy of doX(), doY() and doZ(), right? I just fear that using a class that deals with strings, for instance, may require more memory due to the functions (though many times it requires, due to additional member variables... and it also slows the speed down due to additional checkings and operations).

[JohnW@Wessex]

Use STL's string in preference to raw C strings unless there is a really, really good reason for doing otherwise. They're easier to use and they stop a lot of niggling bugs that crop up when using raw C strings (ie buffer overruns).

[monarch_dodra]

And what do you think about raw string vs STL's string? Though you sometimes write a bit more when using raw strings, I think the speed and flexibility is higher than using the STL's string. So that makes me think that I should better use the raw strings (and allocate the size dinamically), or perhaps, though I didn't become my custom, I can create a class for a 'raw' string with only a constructor and a destructor.

No, STL strings are just as fast as normal manually heap allocate strings. They have a chance of being faster too, as manual string management usually leads to executable bloat. Also, manual management is usually subpar management. The sole fact that a function exists does not slow down a program. There could be 1000 functions inside the string class, it wouldn't slow down your program. If you don't call the function, you don't pay for the function. No point in doing a string class with nothing but constructor/destructor.

And, when creating two objects of a class C, and the class C has the functions doX(), doY() and doZ(), there is only one copy of doX(), doY() and doZ(), right? I just fear that using a class that deals with strings, for instance, may require more memory due to the functions (though many times it requires, due to additional member variables... and it also slows the speed down due to additional checkings and operations).

Again, functions don't take up memory.

The so-called "additional checkings" only occur during debug builds. Once you compile in release mode, nothing is checked.

[Paul McKenzie]

Though you sometimes write a bit more when using raw strings,

You also open your application up to buffer overruns and memory overwrites. The buffer overrun is one of the toughest bugs to detect, because many times, you don't know you've overrun a buffer. Secondly, the buffer overrun error is a security risk. Are you ready to write safe wrappers for everything you do with raw char pointers, because if you don't, your program is opened up for bugs. Then are you ready to maintain such a wrapper? What if the wrapper has bugs?

Handling strings is the bedrock in many programs. Any bugs in this part of a program will render the program highly flawed, and in many cases, unusable and risky to use for sensitive data. Why risk these things when the string class takes care of all of these issues for you?

I think the speed and flexibility is higher than using the STL's string.

Have you written a routine to get the substring of a string using raw pointers? Go ahead and try to do it, and you will see that you have to make all sorts of decisions on how that substring is created. Whatever decision that is, it will have a flaw. The reason you have all of these decisions is because of the inflexibility of a char pointer and what you can do with it.

As far as speed, you will see that std::string is as optimal as it can be, coming up to and sometimes surpassing what you would do with raw pointers. You cannot compare a string class you or most of us would write to one that was written by a top-notch C++ runtime library author. They know all the optimization tricks to use (short string optimization, allocation strategies, etc.). Unless you can come up to the level of these programmers, forget it -- you won't beat their implementation in terms of speed.

So that makes me think that I should better use the raw strings (and allocate the size dinamically),

And more program maintenance. When you get a bug, you now have to look over your pointer handling to see if there is something wrong. While you're doing that, some other programmer is using a string class and is continuing to develop his application, on time and with no such bugs.

Regards,

Paul McKenzie

[Feoggou]

Have you written a routine to get the substring of a string using raw pointers? Go ahead and try to do it, and you will see that you have to make all sorts of decisions on how that substring is created.

well, if you are to display a substring, or need the resulting substring to be used in a Windows function (e.g. SetWindowText) then raw strings are faster, because you don't need to convert them after in a raw string to display them - unless the string actually contains a raw string.

Anyway, some tests:

(the following examples extract from "something" the text "eth" (from position 3, 4 characters).

string class:

string str = "something";
string str2 = str.substr(3, 4);

//displays "ethi"
cout<<str2;

raw strings:

char str[] = "something";
char ch = *(7 + str);//3+4 - after the end of the string, save the character
*(7 + str) = 0;

//displays "ethi"
cout<<str+3;
*(7 + str) = ch;//put the saved character back.

now I'd say that the second one, though you write more, is faster. And you don't need to create a second string.

also let's take the concatanation of two strings:

string class:

LARGE_INTEGER liFreq, liFirst, liLast;
QueryPerformanceFrequency(&liFreq);
QueryPerformanceCounter(&liFirst);

for (int i = 0; i < 500; i++)
{
	string str1 = "one ", str2 = "two", result;
	result = str1 + str2;
}

QueryPerformanceCounter(&liLast);

double seconds = (double)(liLast.QuadPart - liFirst.QuadPart)/liFreq.QuadPart;

//the result is around 0.0125 seconds.
//in release mode 0.00009 seconds
cout<<endl<<seconds;

raw strings:

LARGE_INTEGER liFreq, liFirst, liLast;
QueryPerformanceFrequency(&liFreq);
QueryPerformanceCounter(&liFirst);

for (int i = 0; i < 500; i++)
{
	char str1[] = "one ", str2[] = "two", *result;
	int len = strlen(str1) + strlen(str2) + 1;

	result = new char[len];
	strcpy(result, str1);
	strcat(result, str2);

	delete[] result;
}

QueryPerformanceCounter(&liLast);

double seconds = (double)(liLast.QuadPart - liFirst.QuadPart)/liFreq.QuadPart;

//the result is around 0.0017 seconds
//in release mode 0.00008 seconds
cout<<endl<<seconds;

also: substrings, now with time test:
string:

LARGE_INTEGER liFreq, liFirst, liLast;
QueryPerformanceFrequency(&liFreq);
QueryPerformanceCounter(&liFirst);

for (int i = 0; i < 500; i++)
{
	string str = "something";
	string str2 = str.substr(3, 4);

	//do not display this
	//cout<<str2;
}

QueryPerformanceCounter(&liLast);

double seconds = (double)(liLast.QuadPart - liFirst.QuadPart)/liFreq.QuadPart;

//displays around 0.0051
cout<<endl<<seconds;

using raw pointers:

LARGE_INTEGER liFreq, liFirst, liLast;
QueryPerformanceFrequency(&liFreq);
QueryPerformanceCounter(&liFirst);

for (int i = 0; i < 500; i++)
{
char str[] = "something";
char ch = *(7 + str);//3+4 - after the end of the string, save the character
*(7 + str) = 0;

//do not display this
//cout<<str+3;
*(7 + str) = ch;//put the saved character back.
}

QueryPerformanceCounter(&liLast);

double seconds = (double)(liLast.QuadPart - liFirst.QuadPart)/liFreq.QuadPart;

//displays around 4.70e-006 = 0.0000047
cout<<endl<<seconds;

if in the previous two examples I chose to store the substring in a char[20] (after retrieving the substring), the result is this:
raw strings: around 0.0000089 ("strcpy(aux, str + 3);")
string: around 0.0051 ("strcpy(aux, str2.c_str());")

if in the previous two examples I chose to store the substring in a "string aux;" (initialized before the loop), the result is this:
raw strings: around 0.00027 ("aux = str+3;"). release mode: around 0.00001.
string: around 0.0054 ("aux = str.substr(3, 4);");//here I don't use str2. I use aux declared before the loop, instead. - release mode: around 0.00002

anyway, how do you format a STL string?
with raw string it's simple: you use sprintf.

[Paul McKenzie]

well, if you are to display a substring, or need the resulting substring to be used in a Windows function

Your code is not "substr()". Write a function in 'C' that does the equivalent of substr().

That is what I'm asking you to do or think of doing. Now you will see the decisions you have to make before writing that function. You will have to dynamically allocate memory to create a new string, but that opens up another hole -- who deallocates the memory? Then that is another issue, maintainability and chances of bugs increase.

Second, your code is not reusable because it is not a function that can be called with various parameters alone. As to your concatenation example, can I concatenate 3 or more strings to make a single string?, i.e.

std::string s1;
std::string s2;
//...
s1 = s1 + s2 + s1 + s1 + s2 + s1;

Now what if I want to remove the last s1 in a later update of the program? All I need to do is position my edit cursor after the last '1' and hit backspace 4 times. What would you need to do in your hard-coded 'C' version? Write another set of code, deleting memory again? So then you may decide to write a concat() function, but how would you do it and make the code reusable? And now let's say your program is critical in that it doesn't crash? Can you say your change using raw pointers doesn't have bugs? I am convinced the C++ string version doesn't have any bugs, as any novice can hit a backspace key 4 times.

Anyway, some tests:

The tests you give are not what we would use in most real programming scenarios. Secondly, if you look at the release times, there is hardly any difference.

Last, think of the programmers who have to maintain or even fix your code. They would be very angry if they have to wade through that code to fix a bug, when all you had to do was use a string class to begin with. Look at your examples -- which one is simpler, easier to maintain, and in terms of memory/buffer management, bug free without further inspection by another programmer? Your C++ example or your C "equivalent"?

But my point is this -- buffer overruns, memory overwrites, etc. are some of the toughest bugs to find. Sometimes these bugs exist in programs for years without being discovered, until it's too late and a critical application crashes, or is breached due to a buffer overflow. Handling raw pointers is the main reason for these bugs. Doing raw character handling and char* for strings in C++ is absolutely unnecessary for 99&#37; of C++ applications out there (maybe even higher than 99%). Writing code similar to your 'C' example opens an application up to these sorts of bugs, when in reality, there was no real reason to be exposed to them.

http://www.parashift.com/c++-faq-lite/containers.html
http://www.parashift.com/c++-faq-lit...html#faq-17.11

Regards,

Paul McKenzie

[Feoggou]

ok. thank you for explaining me. I will do my best to give up my habit of using raw strings and raw pointers.

The tests you give are not what we would use in most real programming scenarios.

and... can you please tell me how I can do a proper test? (I understand that it should not be in debug mode)

[GeoRanger]

ok. thank you for explaining me. I will do my best to give up my habit of using raw strings and raw pointers.

Whoa... these are two distinct issues. Don't judge raw pointer usage by string manipulation. That's like saying you'll never use the wheel again because building a car is too complicated.

The avoid-pointers fad is (so it seems) fueled by the lack of skilled labor in C++ development. People are coming out of school or out of the .Net world and are in too much of a hurry to allow themselves to develop the coding and debugging skills which make pointer usage and resource management trivial.

At the risk of climbing onto a soapbox, the underlying principle is widespread in many areas of work and even life in general. -- If you learn to make geologic maps with an initial concentration on speed, years later you'll be rapidly making mediocre maps. Instead, if you pay the price in time up front to concentrate on quality, speed will come with time and practice and you'll end up with the best of both worlds.

The problem with .Net's garbage collection (you did mention C#) and pointer-avoidance is exactly that. It creates a second problem to try to band-aid a first, and you end up with a workforce that wrongly thinks pointers are anathema.

I fully expect to be flamed.

[Paul McKenzie]

The avoid-pointers fad is (so it seems) fueled by the lack of skilled labor in C++ development.

In C++, the avoidance of pointers is usually not because of laziness or not being skilled. Even top-notch professional C++ programmers avoid pointers if possible. The skilled C++ programmer knows the time and place to use pointers, and string manipulation isn't that time. Pointers have been the main bug-central for C and C++ programmers, and if there is a way to avoid these bugs, it should be done.

Also, I have never met a C++ programmer who is skilled in the aspects of C++ such as containers, algorithms, streams, templates, etc. and not know how to do pointer manipulation or "low-level" C++ coding. That creature just doesn't exist, or I have yet to meet that person.

The other languages such as Java have the philosophy that you do not write stuff you saw Feggou write, else you would be drummed out of the community of Java programmers. It isn't laziness in that scenario either, it's just that this is the Java philosophy. I guess the same goes for C#.

Regards,

Paul McKenzie

[nuzzle]

When I started learning C++ long ago there was no STL (or at least the books I've learnt from) and also new did not throw any exception on failure.

The problem is that I got to love raw pointers, while the smart pointers (like the auto_ptr class) look as if it transforms C++ to C# or something.

Do I really need to stop using them? Or they are usefull sometimes?

There are many good uses for raw pointers but in some cases the question of who owns a pointer becomes an issue. Always when it's not 100&#37; clear who's responsible for calling delete on a pointer the best approach is to use a (reference counting) smart pointer because then the smart pointer owns the pointer and will eventually destroy it when it's no longer in use (no longer referenced by anyone).

So one can use smart pointers for convenience anytime, but especially when you find yourself wondering who the heck is going to delete this particular pointer it is strongly recommended you assign that responsibility to a smart pointer.

[monarch_dodra]

Unless you absolutely need hardcore performance, it is usually safer to just adhere to the RAII philosophy and just move on with your life.

The issue is not pointers in and out of themselves, but the management of pointers. There is no problem using pointers when they only reference objects, and neither own nor need to clean up what they are pointing.

Its when you start using pointers that need for the programmer to remember to clean up that the problems arise. The alternatives to the naked pointer, the smart pointers, shared_ptr and unique_ptr, adhere to the RAII idiom.

If you are to use pointers (or iterators for that matter) to just loop over the items in an array, then that is perfectly fine and safe.

If you place raw new'ed object pointers in a vector, you are going to piss off more than one programmer.

[D_Drmmr]

There is no problem using pointers when they only reference objects, and neither own nor need to clean up what they are pointing.

I would add to that "when the object pointed to will not go out of scope during the lifetime of the pointer, or there is a mechanism to reset the pointer when the pointed to object goes out of scope." Otherwise, you can use shared_ptr and weak_ptr to automatically get such a pointer resetting mechanism.
A good design will prevent dangling pointers, but that's not always easy to achieve.

[Feoggou]

I've read that the STL list throws an exception on push_back if an error occurs. Perhaps it sounds silly, but do I really have to make sure I catch every exception?

the same question applies to using statements as char str[20]; or int x; - if it cannot allocate the memory the program would crash and I suppose that after the program is ended there might be memory leaks. So what do I do in this situation?