views:

195

answers:

6

I'm just starting to learn programming. And as of now, I know a tad bit of memory management in Objective-C. It wasn't easy learning it.

So, just out of curiosity, is the memory management employed in major languages like C, C++, Java, etc., in any way similar to what I've learned?

+2  A: 

No, it can vary significantly between platforms - and even within the same platform, there can be various different options. (e.g. in C++, you can use auto pointers, a Boehm GC, etc.)

Java and .NET have mostly similar memory management, mind you.

Jon Skeet
+14  A: 

Memory management comes in two distinct flavours: unmanaged and managed.

Unmanaged is C/C++ where the programmer is responsible for memory allocation.

Managed is like Java/.Net, where memory is allocated for you but cleaned up by the virtual machine ("garbage collected").

Within those two flavours you will find many variations.

cletus
Technically in C/C++ memory management is manual. But in C++ with smart pointers the problem is highly diminished (think of it as C++ having a poor man's garbage collector [You may even argue that it is just a highly tunable Garbage collector to a poor man's]).
Martin York
Yes but smart pointers are still manual memory management. You've just drafted in some other code to help do the job.
cletus
A: 

I don't know how memory is managed in objective-c, but C and C++ use a manual memory management and Java has Garbage-collection built-in and doesn't allow manual memory-management. So they are very different.

Mnementh
+3  A: 

No, it is different.

In Java and .NET languages, there is the concept of Automatic Memory Management which involves Garbage Collectors. The implementation of Garbage Collectors again varies from language to language and platform to platform.

C/C++ do not have automatic memory management and it is programmer's responsibility to Manage memory himself.

In short, it is different for different languages.

Aamir
A: 

G'day,

The only thing you could say that is similar about memory management in various languages is the objectives. Namely:

  • provide a fixed chunk of memory for a process to play in,
  • protect memory outside of this chunk from being accessed by the process,
  • provide a dynamic mechanism of allocation for variables/objects/functions/etc. within the process,
  • ensure that the memory allocations for these items is done on sensible boundaries, sensible being from a point of view of the processor,
  • provide a mechanism to free memory as required,
  • clean up (garbage collect) unused objects,
  • coalesce fragmented memory into contiguous pools of occupied memory,
  • etc.

Various languages and runtime environments provide mechanisms to implement at least some of these features.

HTH

cheers,

Rob Wells
A: 

Memory management approaches vary wildly across languages and platforms, not only in the level of programmer visibility and control, but also in implementation.

Even so, the basics of allocating and deallocating memory are roughly the same when you get down to the OS level. There are certainly differences, tweaks, and optimizations, but usually the programmer doesn't have to deal with such details.

Objective-C is an interesting hybrid, since version 2.0 of the language added opt-in garbage collection, but retains the ability to use reference counting (retain/release/autorelease) as well. In fact, the same code can run in either mode depending on compilation flags and the settings of other code loaded in the same process. This is atypical for programming languages — usually you get either managed (automatic) or unmanaged (manual) based on the code you write, and sometimes the language/platform doesn't provide a way for you to choose at all (e.g. Java).

One flavor is not necessarily better than the other, and there are still still occasional religious debates about whether "real programmers [don't] use garbage collection", but don't worry excessively about it. General knowledge of how various memory management approaches never hurt anyone, and it is generally sufficient to understand the approach for the language(s) in which you code.

Quinn Taylor