Printable View
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.Quote:
Originally Posted by Feoggou
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.
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).
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).
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.Quote:
Originally Posted by Feoggou
Again, functions don't take up memory.Quote:
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).
The so-called "additional checkings" only occur during debug builds. Once you compile in release mode, nothing is checked.
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?Quote:
Originally Posted by Feoggou
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?
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.Quote:
I think the speed and flexibility is higher than using the STL's string.
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.
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.Quote:
So that makes me think that I should better use the raw strings (and allocate the size dinamically),
Regards,
Paul McKenzie
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.Quote:
Originally Posted by Paul McKenzie
Anyway, some tests:
(the following examples extract from "something" the text "eth" (from position 3, 4 characters).
string class:
raw strings:Code:string str = "something";
string str2 = str.substr(3, 4);
//displays "ethi"
cout<<str2;
now I'd say that the second one, though you write more, is faster. And you don't need to create a second string.Code: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.
also let's take the concatanation of two strings:
string class:
raw strings:Code: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;
also: substrings, now with time test:Code: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;
string:
using raw pointers:Code: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;
if in the previous two examples I chose to store the substring in a char[20] (after retrieving the substring), the result is this:Quote:
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;
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.
Your code is not "substr()". Write a function in 'C' that does the equivalent of substr().Quote:
Originally Posted by Feoggou
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.
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.Code:std::string s1;
std::string s2;
//...
s1 = s1 + s2 + s1 + s1 + s2 + s1;
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.Quote:
Anyway, some tests:
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% 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
ok. thank you for explaining me. I will do my best to give up my habit of using raw strings and raw pointers.
and... can you please tell me how I can do a proper test? (I understand that it should not be in debug mode)Quote:
Originally Posted by Paul McKenzie
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.Quote:
ok. thank you for explaining me. I will do my best to give up my habit of using raw strings and raw pointers.
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. :D
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.Quote:
Originally Posted by GeoRanger
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
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% 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).Quote:
Originally Posted by Feoggou
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.
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.
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.Quote:
Originally Posted by monarch_dodra
A good design will prevent dangling pointers, but that's not always easy to achieve.
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?
Nope----you only need to catch those exceptions which you have some idea how to recover from. If the exception is insurmountable (such as out of memory), you may as well let it propagate and kill the program.Quote:
Originally Posted by Feoggou
Since those statements use stack memory, they'll never crash the program unless you're running out of stack space which indicates a problem elsewhere in the code; this should not be a normal concern. Stack overflows usually indicate either that you're trying to put enormous arrays on the stack (put the really big ones on the heap), or you have infinite recursion somewhere (fix it).Quote:
the same question applies to using statements as char str[20]; or int x; - if it cannot allocate the memory the program would crash
On modern systems, it's impossible to have memory leaks after the program is ended. When the process terminates, all of the memory it used, leaked or not, goes back to the OS. The concern is how to avoid memory leaks during execution. To that end, RAII is your friend. So long as all resource deallocation is handled by the destructor of some object on the stack (say a smart pointer, STL container, or custom object), memory leaks are almost impossible even in the face of exceptions.Quote:
and I suppose that after the program is ended there might be memory leaks.
In many cases, you don't need to care what exceptions might be thrown, you only need to clean up if an exception whose identity is of no interest has been thrown, then you can pass the exception onward.Quote:
Perhaps it sounds silly, but do I really have to make sure I catch every exception?
The RAII pattern makes the delete [] and the try/catch unnecessary.Code:void MyDataFunction(void) throw (...) // Explicitly state this function can throw anything
{ // For backward compatibility, it's otherwise implicitly so in C++
int const nData = 500;
CMyDataObject * const aMyData = new CMyDataObject [nData];
try
{
int const * const pResults = RiskyDataCollectorWhichCanThrowFiveExceptions(aMyData, nData);
RiskyDataDisplayWithMoreExceptions(pResults, aMyData, nData);
}
catch (...) // catch anything without learning its identity
{
delete [] aMyData; // Don't let exceptions cause a resource leak!
throw; // Propagate the exception. Some caller might be able to
// recover and display an error message to the user, then
// resume normal program operation.
}
delete [] aMyData; // Normal path, all done.
}
An article called "The Trouble with Checked Exceptions", which is an interview with the lead C# designer, gives a good language-neutral perspective on exception handling and the state of current thought (in some circles at least) on the matter.
The article can be found at <http://www.artima.com/intv/handcuffs.html>.
ok, so if I do something like this:
(that is, without a try-catch block) and there isn't sufficient free memory for all. That would cause the program to crash. Would there be memory leaks after the program is ended?Code:int* p = new p[200];
and, on the other hand, if I used:
but there isn't sufficient memory left, the program would crash and you mean that there would be no memory leaks because of RAII, right?Code:int p[200];
The program might not crash. std::bad_alloc might be thrown instead, in which case it is possible to recover, to some extent. There would not be a memory leak in a modern OS since the OS would reclaim the memory used after the process terminates; otherwise it depends on whether the other dynamically allocated objects use RAII (or maybe not, if the crash means that there is no stack unwinding).Quote:
Originally Posted by Feoggou
Considering your proposition that there is no enclosing try/catch in your first example, the essential outcome would be pretty much the same in both cases.Quote:
Originally Posted by Feoggou
Doing a bit of nitpicking, I would say the second one is even worse because running out of stack space is such a fatal condition that there's hardly a chance to recover from it, and AFAIK there's no exception thrown in that case. (Well, in .NET there actually is one, but that's not what we're talking about here.) Also, laserlight pointed out (although in parentheses) that there may be no stack unwinding in the case of running out of stack space. And I estimate the chance for that actually very high so that I think it's unlikely that RAII will really help here. (Of course that does not mean I think that allocating objects on the stack is generally a bad idea. This is only an issue if you are allocating really large objects, mostly arrays, on the stack, maybe even recursively, and that's definitely not recommended anyway.)
And, as already pointed out by laserlight as well, there will be no system-wide memory leaks after an app crash because the OS takes care of that. (And that's why the outcome is pretty much the same in both cases.)
ok, thanks guys for your help. It's clear to me now.
In theory, when a new fails, the *new_handler is called to try to free up memory. The new_handler frees up memory and returns execution to new to try again. The cycle continues add infinitum, until either the new succeeds, or the new_handler tires and returns an std::bad_alloc compatible exception.
You shouldn't care, but from an external view, this means two things:
1- new ALWAYS* returns std::bad_alloc when it fails (not might)
2- In theory, by the time you receive the bad_alloc, the system has already tried to recover from it. It is just politely telling you it is about to fail.
Of course, this is a quality of implementation thing, and results might differ on different platforms.
*If no new handler is present, it just immediately throws bad_alloc.
*Except nothrow new of course, but even nothrow new calls the new_handler.