Rock2000: Actually, it's easier to read, simpler, and faster. It's just a good practice to get into. I don't understand why you would want the function imbedded. The system will create a temporary char* to save the return value of the function, then copy the value of that temporary char* into the local char* of whatever function you are using with it. You don't actually save anything by "chaining" the functions together, except white space in the source code. But white space is a great tool for making code readable. Also, it is not just the elimination of a(n) (unnecessary) 4-byte return value that makes my method slightly better as there are other optimizations that can be done. Keep in mind that there are 6 temporary variables being created by these statements, and only one of them needs to stay around long enough for the if() statement. The others can be optimized, perhaps the compiler could even use the same stack space for some of them (when they go out of scope) rather than reallocating, etc. Whatever!

If you do this with all of your code, it will add up. Besides, you aren't losing anything.


Tim Smith: You didn't read far enough:

quote: CreateThread Documentation

dwStackSize
Specifies the initial commit size of the stack, in bytes. The system rounds this value to the nearest page. If this value is zero, or is smaller than the default commit size, the default is to use the same size as the calling thread.

For more information, see Thread Stack Size.

Here is the Thread Stack Size document:

quote: Thread Stack Size

Each new thread receives its own stack space, consisting of both committed and reserved memory. By default, each thread uses 1 MB of reserved memory, and one page of committed memory. The system will commit one page blocks from the reserved stack memory as needed, until the stack cannot grow any farther.

So, the default is to start at 1 MB and grow in multiples of 4 bytes (page size on a 32-bit OS?).



- null_pointer
Sabre Multimedia


Edited by - null_pointer on 5/5/00 5:00:22 PM

Edited by - null_pointer on 5/5/00 5:04:28 PM

Null pointer... 1 mb of reserved means that the stack has been allocated 1 mb of space in the logical address space that the program sees. The committed pages are what is actually used.(And a page is something like 4KB not 4 B). So the stack starts with a size of one page and will grow to a maximum size of 1 MB which is the amount of space in the logical address space that has been assigned to the stack.

Torval

Well, I don''t want to belabor this issue, becaue it doesn''t really deserve it, but its not as cut and dry as you claim null_pointer. I''m not claiming anything is saved by chaining the functions. I''m saying that the speed really doesn''t matter in this case. My answer is tailered for the question. Someone made a comment about embedding the function, so I answered that in my opinion.

Would I embed the function in this case? Yeah, I probably would. Am I saying people should embed functions? It really doesn''t matter. Its a preference. As a programmer, I do it sometimes, and a flexible API lets me do it. I''m annoyed when I want to do it and can''t. Its just designing a more robust API. I used to cruntch every little cycle out of my code at the cost of robustness, but it just doesn''t work out, even in games.

In this example, I don''t see any speed I''m going to lose by embedding it. There is 1 move instruction to pass back the pointer. That''s all I see. But I''ll admit I''m not putting much thought into it. It''s next to a file read, which will totally overshadow anything the function might do. I wouldn''t say it doesn''t matter in other situations, but its not going to add up except in extreme situations.

Rock

Torval: OK, I understand now. I wish the docs would have said "until it reaches the reserved size" instead of "until it can''t grow any further." It''s really quite irritating. Thanks for clearing that up!

Rock2000: Do what you like, but good coding applies to all code, not just localizing it to one particular instance. It would be useless to optimize that function, except to learn how to naturally write code that can be easily optimized by the compiler. Once you do, it carries over to more important things, and you have to spend less time posting on message boards and using a profiler.


- null_pointer
Sabre Multimedia

Chaining functions together means the compiler will avoid making temporary variables. (Isn''t there a topic on this in the Essential C++ books?) If you keep them separate, then the compiler will have to make those temporaries, and -hopefully- optimise them out later... and not all of us have optimising compilers Of course, you shouldn''t really do it with functions that might return an error value.

To the person that asked if memory leaks close if a program is ended: they don''t. Due to the way the memory is allocated, winblowz still thinks that that memory is being used by an application. to close a leak to have to reboot.

MENTAL

The thing that determines wheter i use stack or heap is this: scope. If i need a variable only temporarily for a function or something, then i just declare it in the stack. However, if im adding a variable to a linked list or i need the variable to last until i decide when i dont need it, i use new and delete .

If anyone cares, a good use for auto_ptr is this (untested code, btw - and exception-free to avoid disputes ):

int function(){    auto_ptr<MyType> array = new char[BUF_SIZE];    DoSomethingWith(array);    if (FAILED(Function1()))        return -1;    DoSomethingElseWith(array);    if (FAILED(Function2()))        return -1;    DoAnotherThingWith(array);    return 0;} 

The auto_ptr, in this case, removes the need for 3 explicit delete operations. This reduces the risk that you will forget to free memory that you allocated, as the auto_ptr will do this for you when it goes out of scope.

Sure, you never need it, but then you never -need- lots of this sort of thing.