• Advertisement
Sign in to follow this  

Couple general C++ questions

This topic is 4227 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I just a have few general questions about c++. 1. Do shorts take up less memory than ints? Are they faster to access? 2. What does the inline keyword actually do? 3. If you never use new, do you have to worry about memory leaks? 4. Can you use delete on something that didn't use new? 5. What does a memory leak actually do? Thanks for your help... I realize that these are things I should already know, but I don't. I've always wondered what memory leaks were, but I've just avoided them like the plague without knowing why.

Share this post


Link to post
Share on other sites
Advertisement
1. Try something like cout << sizeof(int); to find data type sizes
2. The inline keyword copies your code to where it is called rather than referencing to it. This increases file size while generally increasing performance.

Share this post


Link to post
Share on other sites
As far as inline, it is a hint to the compiler to try and take a functions code and basically "cut and paste" it in place of the function call.

As far as new, if you use any kind of dynamic memory allocation (new or malloc), you have to worry about memory leaks. Also if you use Operating System resourses, you might have to also worry about resource leak if you don't release those (like some MS Windows Handles).

If you use new, you use delete. If you use new[], you use delete[]. If you use malloc, you use free. You can't mix and match.

A memory leak is when the resources aren't released to be used again. In most os's, the memory will be freed when the program terminates, but while the prgoram is running, it tends to collect more and more memory.

Share this post


Link to post
Share on other sites
1. shorts will never take up more memory than int, it may take up less or the same amount. On most compilers sizeof(short) is 2 (16bit) and sizeof(int) is 4 (32bit). Int is supposed to be the fastest type, this is not the case in all cases though. For instance many systems where an 8 byte integer would be the fastest the compiler uses an 4 byte integer because previous code is dependent on the size of int to be 4 bytes. Use int by default, you are not likely to see improvements when using short.
2. It tells the compiler that instead of calling the function it would be smarter to just replace the call with the code, so this:
void add_times_5(int a,int b)
{
return (a+b)*5;
}

int main()
{
add_times_5(3,2);
}

Should be interpreted as:
int main()
{
(3+2)*5;
}

This can improve performance for small functions because the overhead of calling the function will be big compared to the overhead of the actual function, it can also increase size since the code will be copied to many places. Remember this is just a hint, and most modern compilers completely ignores it.
3. Not unless other code use new, or you use other functions which dynamically gets memory (like VirtualAlloc on Win32). Also you can still leak resources.
4. I believe the behaviour of this is undefined, so you can, but it could format your harddrive (no it won't do this, but according to the C++ standard it would be allowed to).
5. A memory leak occurs when you request memory and never returns it. Imagine if you have a nice neighbour with 100 dishes, every day you loan one, but you never return (delete) them. So after 50 days half of the dishes is used up and your neighbor may not be able to loan dishes to other people (other processes), after 100 days he won't even have any dishes left, this is because you didn't returned them.

Share this post


Link to post
Share on other sites
Quote:
Original post by CoyCash
1. Try something like cout << sizeof(int); to find data type sizes

This will not help him what if sizeof(short) is 255 and sizeof(int) is also 255, does that mean that sizeof(short) is always sizeof(int)? What if sizeof(short) is 5, but sizeof(int) is 500 does that mean sizeof(int) is always 495 bytes bigger than short? The standard guarentees:
sizeof(char) == 1
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Original post by EmrldDrgn

3. If you never use new, do you have to worry about memory leaks?
quote]

You must be careful here as CTar states. You may use another libraries code or call a function from outside of the immediate source file that news something, and puts the responsibility of delete-ing it with you.

Share this post


Link to post
Share on other sites
Quote:
Original post by EmrldDrgn
I just a have few general questions about c++.

1. Do shorts take up less memory than ints? Are they faster to access?


Maybe, and maybe. If you don't have a specific reason otherwise, use int.

Quote:
2. What does the inline keyword actually do?


It communicates to the compiler "hey, maybe you should inline this". Not all things can be inlined, or are exceedingly difficult to inline.

The compiler is also allowed to inline things that you *didn't* mark as inline. As well, note that putting a member function's definition inside the class body implicitly marks that member function as if there were an 'inline' keyword.

If your question was really "what does inlining actually do", it can have many possible effects, and might not make any significant difference, which is why it's a good thing that the compiler's ultimately in charge: it usually knows better than you do what should or should not be inlined. But basically, it works by cloning the function at the call site, changing the function's parameters to match the variables that were passed in, and then re-optimizing it as if the code had been there the whole time. Note that the behaviour is as if the function were called, which is NOT the same as "as if the code had been written in place" - it is easy to construct examples of inline function that don't behave the same way as a seemingly "equivalent" macro. (Normally, the behaviour of the inline function is considered "correct" in these cases; don't use macros for this sort of thing. Please. Just don't.)

BTW, you might want to just read that whole FAQ section.

Quote:
3. If you never use new, do you have to worry about memory leaks?


If you never use new, or new[], or malloc()/calloc()/etc. (but you shouldn't use those in normal C++ code), and you never use a library that explicitly tells you in its documentation "the return value from function X is dynamically allocated in this way (and therefore should be deallocated accordingly)", then no.

It is not difficult to avoid this explicitly (unless you really need that badly-designed 3rd party library), but pretty much impossible to avoid it implicitly (e.g. by using standard library containers). That's not a problem: if you're making implicit use, then the thing that's wrapping your access to the dynamic memory is what's responsible for cleaning it up. For example, if you make a std::vector<int>, it will in turn allocate memory with new (to be pedantic, it will allocate memory using a provided "allocator", which defaults to std::allocate(), which in turn uses the global operator new), but it will deallocate that memory for you as well. Where? In the destructor of the object, of course.

Correspondingly, you should make your classes clean up after themselves in a similar way.

Quote:
4. Can you use delete on something that didn't use new?


No! Well, you *can* do anything that compiles, but it won't do what you want. In fact, this is one of the many things that falls into the realm of "undefined behaviour", meaning that it actually is technically allowed to do anything that the computer is capable of. (Normally, what will happen is that *most* of the time you will be *lucky*, and it will simply crash right away; sometimes it will mess things up silently and leave a debugging nightmare.)

If you new'd it, delete it.
If you new[]'d it, delete[] it. delete and delete[] are NOT the same, even for an array of one element, even for primitive types, even for anything else you might think of that might make a difference. Just don't freakin' do it.
If you malloc()'d it, free() it.

Quote:
5. What does a memory leak actually do?


It eats up memory that then can't be used for other things. Eventually, if the leak is "progressive" (i.e. each time you call the function, more is leaked), you can run out and crash the whole system.

Modern OSes defend against this in two ways: by using virtual memory to expand the effective memory, and by automatically cleaning up ALL memory used by a process after it terminates.

However, you should still hunt down and eliminate all memory leaks in your program. If the program runs for a long time, you can still eat up lots of memory while the program is still running, and by forcing stuff into virtual memory, the whole system gets seriously slowed down (the hard drive is much slower than RAM).

You should also note that memory is not the only kind of "resource" that a program might "leak". You can get into serious trouble, in C, by opening files with FILE*'s and not fclose()ing them - you eventually run out, and further requests are denied. (The C++ iostream classes guard against this, again by using the destructor to do cleanup.)

To avoid memory leaks:

1) Make use of standard library components where appropriate. Especially containers, but don't neglect things like std::auto_ptr. Also consider the Boost library for more advanced needs, before inventing your own thing.
2) When you do need to invent your own things (which is inevitable - otherwise your entire program already exists somewhere), design them properly, by having resource acquisition happen in the constructor, and deallocation in the destructor. (Be careful if objects need to "share" resources. For these circumstances, you should strongly consider the use of so-called "smart pointers", such as the boost::shared_ptr.)
3) Statically prove the absence of memory leaks, if you can. Try to reason through the flow of your program.
4) Failing that, use memory leak detection libraries to track down the problems.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement