PDA

View Full Version : Advice on next steps - shifting to OOP



Pages : [1] 2

officedog
11-27-2008, 12:17 PM
So far I have had reasonable success with learning C and openGL. My interest is in graphics mainly. I guess I will have to make the shift to learning an OOP language at some point soon. Although C++ would be an obvious choice, because I have a mac, the dominant language is Objective-C.

There are some clear advantages to going down the objC route (such as it is native language and the mac system is set up for this language), but I also see some problems. e.g. ObjC doesn't seem to have the same (excellent) support from communities such as this, fewer tutorials and the learning curve looks extremely steep from the articles I have seen (I have Aaron Hildegras book).

C++ on the other hand has more support and looks less complex to get started with, but is not the native mac language as far as I can tell.

My options I think are:
a) Stick it out with C because it can ultimately do everything that other languages can do
b) Start learning an OOP language
i) Go for C++ and then (possibly) graduate to ObjC
ii) Go straight for ObjC
c) Have a cup of tea

I'd appreciate any thoughts on this. In meantime, back to C I think...

VirtualAce
11-27-2008, 12:32 PM
Although C++ would be an obvious choice, because I have a mac, the dominant language is Objective-C.

It is?

Object oriented principles are not about this language or that language. That comes down to a matter of semantics on how to implement this or that OOP pattern in the language. The principles remain the same. I would recommend reading up on design patterns in general and would not focus on any certain language. A book on UML would also be a good read.

Then once you understand the concepts you can choose which language you want to employ those concepts in.

CornedBee
11-27-2008, 12:55 PM
It is?
Yeah, the Cacao API is an Objective-C API.


Now, I've never actually used ObjC, not having a mac, so the following opinion is based on just a few tutorials and may be extremely unfairly prejudiced, but I think Objective-C is an absurd language. It's C, with some weakly typed, extremely foreign syntax tacked on to support object-orientation that's somewhere between Smalltalk and stricter OO languages.

officedog
11-27-2008, 04:27 PM
Thanks for suggestions Bubba. Had a look at UML - I'll have to think more on this, I can see it's useful for organising/structuring the overall program. I suppose the basic issue I face at the moment is that with some earlier help here I've started trying to implement an "oop" style using C structs and function pointers. It's great, it works, but what a lot of typing... leading me to this question!

And thanks CornedBee - your comments mirror my thoughts about the learning curve. Makes me think I may be best sticking with C for now and return to this question later.

Elysia
11-28-2008, 04:39 AM
a) Stick it out with C because it can ultimately do everything that other languages can do
No, it cannot. It's very weak in that area.


b) Start learning an OOP language
i) Go for C++ and then (possibly) graduate to ObjC
ii) Go straight for ObjC
Well, this is just me, but I would definitely go straight for C++, and not look back at (Obj)C.


c) Have a cup of tea
That sounds like a wonderful idea too :)

But honestly, if you are going to be writing anything like computer software or games, then you really should use a modern language. C is not a modern language, nor is ObjC.
The preferred language for games is C++ mainly due to its speed and its modern features that can even give modern languages a real challenge.

C is good for embedded projects where requirements aren't high, but for other projects, I would really recommend a moder modern language.

zacs7
11-28-2008, 04:56 AM
> No, it cannot. It's very weak in that area.
Sure it can. Just that more and more 3rd party libraries seem to be moving to OO, and hence C++.

I'd say go for C++, but still keep knowledge and use of C. You never know!

I don't know what a modern language is!? But C is procedural, the idea of OOP is (fairly) modern. C and C++ are (very) roughly from the same era. If you want truly modern, then you should be looking at something a bit more managed. Choose the tool for the job, that doesn't mean the newest tool in the shop either.

I see no problem with maintaining 2 or more types of programming paradigms being procedural and object orientated. It could even make you more employable!

I myself know very little C++ (being syntax and keywords -- but I do have a "good" understanding of OOP), instead I doodle with C and Java. I do plan to make more use of C++ once I have a fairly large C project completed. That way I'll have something to show on my resume :-)

> The preferred language for games is C++
Careful! The big troll is pushing C# something wicked.

PS: UML is wonderful, defiantly worth the effort. Although it does suffer from a few flaws.

Did you end up trying GLFW officedog?

Elysia
11-28-2008, 04:58 AM
> No, it cannot. It's very weak in that area.
Sure it can. Just that more and more 3rd party libraries seem to be moving to OO, and hence C++.

Well, not in terms of libraries - but in terms of paradigms and features.
No classes, hence no RAII, smart pointers, etc.
No template support - so no type-safe or powerful ways of creating generic code, etc.

Libraries can always be found, of course...

psychopath
11-28-2008, 08:25 AM
Personally, I would learn C++, and use Obj-C++ for any Cocoa/GUI stuff (unless you insist on using Carbon). The syntax (among other things) is a little weird at first, but I didn't find it to hard to pick up on. Pretty much like learning any other language.

EDIT: Post #1000! :)

maxorator
11-28-2008, 09:05 AM
Well, not in terms of libraries - but in terms of paradigms and features.
No classes, hence no RAII, smart pointers, etc.
No template support - so no type-safe or powerful ways of creating generic code, etc.

Libraries can always be found, of course...
Those are not things that can be done. Those are the methods how to do things. In C you just do them differently. I don't consider one of them to be better than the other - they're equal and both of them are useful to some people. You are just used to C++ features, C programmers are used to different features. It's like whining that gasoline cars don't run on diesel (but hey, both of them help the car move!).

To OP - you should definitely learn C++ since it's the most widely used portable programming language.

officedog
11-28-2008, 11:47 AM
hi zacs7 - thanks for comments on this. Sadly I was unable to get GLFW working on the system and was too wrapped up with the GUI project to tackle how to get it loaded up. So... GLUT is still the thing I know. I'll have to sort this out soon as it looked very nice. I might just experiment with one of the GUI libraries provided automatically within the apple's developer package and see where that goes.

psychopath - thanks for that reassuring comment. I think the problem I had was that objC is so closely linked up with all the NSObjects and wotnot and also trying to figure out how to work with XCode - I had difficulty breaking the learning into simpler steps. In the end I came back to creating simple command line "standard tool" programs in C and built up openGL on top of that - which has been very successful so far. I guess your solution might be one to keep in mind for later if I want to work off the foundation and appkit libraries, but I'll need a little more learning before I get there.

Thanks Elysia for sharing your thoughts. Just out of curiosity, what counts as a 'modern' language. Are you talking about Ruby or python or.... ? I'm definitely going to get on with C++ now, so it was as I said, just out of curiosity.

Maxorator - thanks for the clear advice.

Well thank you everyone for sharing your thoughts - very helpful in shaping up a plan. I decided in the end to get out my C++ notes from the tutorials here and am currently trying to go quickly through Bruce Eckell's book.

Elysia
11-28-2008, 12:01 PM
Thanks Elysia for sharing your thoughts. Just out of curiosity, what counts as a 'modern' language. Are you talking about Ruby or python or.... ? I'm definitely going to get on with C++ now, so it was as I said, just out of curiosity.

I'm not sure, but I would count C++, Java and C# as modern languages, at least. Perhaps even Visual Basic.
Not very knowledgeable about languages.

laserlight
11-28-2008, 12:06 PM
I'm not sure, but I would count C++, Java and C# as modern languages, at least.
On what basis do you consider them "modern"? It certainly cannot be period of time, since you exclude Objective C but include C++.

Elysia
11-28-2008, 12:08 PM
Features and ease to develop modern applications.
And as far as I'm concerned, Obj-C is just a rip-off of C that we could do well without. If you need object oriented and C, I would choose C++. But I'm known to be biased.

whiteflags
11-28-2008, 12:21 PM
Features and ease to develop modern applications.

Then what is a modern application?

VirtualAce
11-28-2008, 12:23 PM
> The preferred language for games is C++
Careful! The big troll is pushing C# something wicked.


That does not mean it is the best choice for them. I think they are pushing this for small games and apps that can run both on PC and XBox. I seriously doubt any real game dev companies are considering using it. I'm sure that the big retail games are running C++ even on the XBox.
C# is a great language and very useful albeit I feel Microsoft is pushing it for something it really was not designed for just to keep it relevant. I believe it's relevance comes in the fact that it is so simple to create GUI apps and the idea of no headers which I must say I do enjoy.

I could be wrong but with games even pushing the speed envelope using C++ I seriously doubt any company is going to risk using a completely different language. Mainly because I don't see what it brings to the table that C++ does not and most of the game engines at companies are already in C/C++ so migrating to C# would be a pain.

I've also noticed that most of Microsoft's so-called C++ code look strangely like C programs. If you look at the DXUT you will see one file has over 6000 lines in it. Does not look like C++ to me. So we have a company that does not appear to push good object oriented code pushing some new object oriented language? Makes me feel all warm and fuzzy inside. Microsoft is masterful at C but not with C++. Most of their programmers are probably hard-core C programmers and you can tell it when you look at their supposed C++ code.

Elysia
11-28-2008, 12:25 PM
Then what is a modern application?

A modern application is software developed for a platform such as PC in today's times. Typically such applications tend to grow complex.
That is how it's defined by my book anyway.

VirtualAce
11-28-2008, 12:29 PM
I think you are forgetting about embedded systems. A great deal of that code is 'modern' even though the hardware it's on is far less than modern.

Elysia
11-28-2008, 12:34 PM
Perhaps. Not much experience with those things.
But typically any modern hardware, embedded or not, requires complex code.
And then I would say it is good to have a modern language.
It is supposed to make things easier, after all, so it can't hurt.

whiteflags
11-28-2008, 12:39 PM
But your definition of a modern language depends entirely upon the application: how complex it is and when it was shipped (or written). Therefore anything used to write a 'modern' application according to you is a modern language. Including C? Could you maybe be more specific? Or maybe we could drop the subject? ;)

VirtualAce
11-28-2008, 12:41 PM
Dropping the subject sounds good to me. I would not deem a language modern or antiquated based on any of the criteria that have been mentioned.
And my advice to the OP was not a ploy to get them to use C++. I don't care what language they use. Using C++ does not make you an object oriented programmer any more than walking into McDonald's makes you a hamburger.

Elysia
11-28-2008, 12:41 PM
We could drop the subject, if you want ;) It doesn't really matter to me.

officedog
11-28-2008, 01:29 PM
Object oriented principles are not about this language or that language. That comes down to a matter of semantics on how to implement this or that OOP pattern in the language. The principles remain the same. I would recommend reading up on design patterns in general and would not focus on any certain language. A book on UML would also be a good read.


Just going back to your comment here Bubba. I did a short search yesterday and I found things like:

north.londonmet.ac.uk (http://studweb.north.londonmet.ac.uk/~chalkp/proj/ootutor/umlnotation.html)

http://www.codeproject.com/KB/cpp/oopuml.aspx

And this was quite interesting from Bruce Eckells who gives a more critical angle:

http://www.artima.com/weblogs/viewpost.jsp?thread=115101

Do you have any other recommendations about books or websites that give a good introduction to these ideas?

IceDane
11-28-2008, 06:56 PM
That does not mean it is the best choice for them. I think they are pushing this for small games and apps that can run both on PC and XBox. I seriously doubt any real game dev companies are considering using it. I'm sure that the big retail games are running C++ even on the XBox.
C# is a great language and very useful albeit I feel Microsoft is pushing it for something it really was not designed for just to keep it relevant. I believe it's relevance comes in the fact that it is so simple to create GUI apps and the idea of no headers which I must say I do enjoy.

I could be wrong but with games even pushing the speed envelope using C++ I seriously doubt any company is going to risk using a completely different language. Mainly because I don't see what it brings to the table that C++ does not and most of the game engines at companies are already in C/C++ so migrating to C# would be a pain.

I've also noticed that most of Microsoft's so-called C++ code look strangely like C programs. If you look at the DXUT you will see one file has over 6000 lines in it. Does not look like C++ to me. So we have a company that does not appear to push good object oriented code pushing some new object oriented language? Makes me feel all warm and fuzzy inside. Microsoft is masterful at C but not with C++. Most of their programmers are probably hard-core C programmers and you can tell it when you look at their supposed C++ code.

Microsoft, like anything else, that size, is divided into numerous departments and similar, as you probably know. Therefore it is completely illogical to expect the developers of C#(Anders Hejlsberg and his cohorts) to have anything to do with any code in the microsoft operating systems, except, of course, the .NET framework part of it.
You might be right - perhaps their programmers' C++-fu is weak due to way too much exposure to imperative programing, but the minds behind C# and its sibling languages in the .NET framework are, in my opinion, some of the greatest minds to shine their light on the programming world, ever.

Elysia
11-29-2008, 04:18 AM
...but the minds behind C# and its sibling languages in the .NET framework are, in my opinion, some of the greatest minds to shine their light on the programming world, ever.

Ugh. They need to be shot and burned.
C# and Microsoft's .NET crap is worst thing that has happened.
Majority of code is done in native, still today, yet all we hear is managed, managed, managed, managed, managed! It annoys me to no end. I don't want crap-managed.

abachler
11-29-2008, 08:21 AM
I've also noticed that most of Microsoft's so-called C++ code look strangely like C programs. If you look at the DXUT you will see one file has over 6000 lines in it. Does not look like C++ to me. So we have a company that does not appear to push good object oriented code pushing some new object oriented language? Makes me feel all warm and fuzzy inside. Microsoft is masterful at C but not with C++. Most of their programmers are probably hard-core C programmers and you can tell it when you look at their supposed C++ code.

Procedural programming is much more readable for examples, where the point is to illustrate the use of a function or method, not to produce the fastest most elegant code. Sometimes I think people confuse procedural methods with C, even though C++ can also be written procedurally and OOP is not incompatible with the procedural style.

Yes, in school you are taught to use OOP exclusively while learnign OOP, just like painters are taught to use a particular brush while learnign to use that brush, but to restrict yourself on real projects is to reject applying the most useful method for the task at hand, delaying the project, and possibly lockign out potential improvements. Mixing of 'pure' programming styles produces much better results than trying to paint a picture using only one size of brush and a single color.

VirtualAce
11-29-2008, 11:48 AM
...delaying the project, and possibly lockign out potential improvements.

While it is true you do not want to do this it is also true that you do not want to create a maintenance nightmare. C++ done procedurally becomes just that and is also hard to componentize later. I do not see it a lot except for in most of Microsoft's sample code so perhaps they are just trying to illustrate a concept and 'get it done' so to speak. Their DXUT is absolutely a mess and there are far better frameworks out there to begin with. After looking at DXUT I will not be recommending it to anyone but my worst enemies.

IceDane
11-29-2008, 07:10 PM
Ugh. They need to be shot and burned.
C# and Microsoft's .NET crap is worst thing that has happened.
Majority of code is done in native, still today, yet all we hear is managed, managed, managed, managed, managed! It annoys me to no end. I don't want crap-managed.

What's so bad about type-safety and garbage collection?

Elysia
11-30-2008, 02:47 AM
Slow.
There should be minimum run-time penalties and maximum compile time safety.

maxorator
11-30-2008, 08:55 AM
What's so bad about type-safety and garbage collection?
People are supposed to collect their own garbage. It's better to write code that doesn't leave garbage in the first place.

Type-safety is often a nuisance since I have to use many typecasts to do a simple operation - a very annoying thing for people who do a little bit of low-level stuff.

Elysia
11-30-2008, 09:23 AM
Spoken like a true C programmer...
I like type-safety. Less chance to do many errors.
It works very well with high-level design, and using proper types and constructors, even low-level stuff.

maxorator
11-30-2008, 09:41 AM
Spoken like a true C programmer...
I like type-safety. Less chance to do many errors.
It works very well with high-level design, and using proper types and constructors, even low-level stuff.
Well you're right, I've got to admit type-safety is good when I'm doing ordinary stuff... but not when doing something really low-level.

Elysia
11-30-2008, 09:53 AM
Such as? When / how / why?

maxorator
11-30-2008, 09:57 AM
Calculations with pointers where the type is irrelevant.

Elysia
11-30-2008, 10:01 AM
I can imagine such a thing, but the question begs to ask - is it necessary? Can it be done another way, without speed penalties or complications?
That's why I'm trying to see - a way through low-level stuff where type-safety does not hinder.

whiteflags
11-30-2008, 11:36 PM
Slow.

Picky, picky. It's just another way to manage memory, I'm afraid.

Ideally the garbage collector sweeps when something no longer has a reference, so henceforth any performance penalty occurs when things fall out of scope. Such things are short lived and frankly similar things happen when you have to do it yourself. delete has to manage the memory pool, that's about as much a time waster as any garbage collector.

Whatever, though. If you're comfortable doing it all yourself, go right ahead. But it only needs to be fast enough. Meet your specs. If what you originally wrote isn't good enough, then your world does not fall apart: I bet it ain't the memory management that's slowing you down.

Elysia
12-01-2008, 03:08 AM
Perhaps. But it's also about one big run with lots of CPU cleaning up, vs small bits and peaces here and there.
Plus garbage collection is usually slower with destructors.
And then it's the issue of memory. Garbage collectors kick in when they think enough memory has been used, while the typical manual approach frees memory directly when it's no longer needed.

And it's just not about garbage collection, but the runtime checks & whatnot that further slows things down.

These are the biggest issues I have against dotNet.

zacs7
12-01-2008, 04:01 AM
> Perhaps. But it's also about one big run with lots of CPU cleaning up, vs small bits and peaces here and there.
Would it not be better to free things when your program is in idle and not doing anything, rather than during some intensive task? I'd think so.

> Garbage collectors kick in when they think enough memory has been used, while the typical manual approach frees memory directly when it's no longer needed.
In the old'n days perhaps... VMs and company have come a long way in recent times, perhaps you need to brush up on your knowledge if you're going to knock them all the time.

Elysia
12-01-2008, 04:05 AM
> Perhaps. But it's also about one big run with lots of CPU cleaning up, vs small bits and peaces here and there.
Would it not be better to free things when your program is in idle and not doing anything, rather than during some intensive task? I'd think so.
And gobble up huge amounts of CPU? No thanks.
And what if it does not idle, and it memory intensive?


> Garbage collectors kick in when they think enough memory has been used, while the typical manual approach frees memory directly when it's no longer needed.
In the old'n days perhaps... VMs and company have come a long way in recent times, perhaps you need to brush up on your knowledge if you're going to knock them all the time.
I prefer not to. I know garbage collectors are not my thing, but I don't mean to steer anyone else away from it.

maxorator
12-01-2008, 04:13 AM
Ideally the garbage collector sweeps when something no longer has a reference, so henceforth any performance penalty occurs when things fall out of scope. Such things are short lived and frankly similar things happen when you have to do it yourself. delete has to manage the memory pool, that's about as much a time waster as any garbage collector.
Malloc/free (aka delete/new) don't actively manage memory. You use malloc - it finds you an open slot, you use free - it marks that slot as available. But the garbage collector actively searches through the entire memory at all times, trying to find non-referenced junks of memory. That's evil.

Freeing/allocating memory is not an intensive task - memory pages are just marked either committed or not. The massive initialization/deinitialization different frameworks like to do is what makes it intensive.

CornedBee
12-01-2008, 04:16 AM
But the garbage collector actively searches through the entire memory at all times
Nonsense. Exact, generational garbage collectors do nothing of the kind. Not even conservative mark&sweep collectors like those used in C++ (e.g. Boehm) search all the time.

Elysia
12-01-2008, 04:18 AM
Well, I guess it depends on the implementation. But if you don't "free" memory, then it would have to search through all allocations, looking for ones that aren't used anymore and free them. So it would actively be searching, although not all of the time, only when it kicks in and begins to collect.
Still, I am not fond of such a thing.

maxorator
12-01-2008, 04:23 AM
Nonsense. Exact, generational garbage collectors do nothing of the kind. Not even conservative mark&sweep collectors like those used in C++ (e.g. Boehm) search all the time.
I'm not talking about garbage collector libraries, I'm talking about the builtin garbage collectors in some languages. Imagine that someone allocates huge junks of memory and references them with each other, makes many complex structures inside that memory. Then suddenly, the code removes references to most parts of that memory - it makes no calls to memory allocation/deallocation functions, just sets a few things to zero. Garbage collector finds that and deallocates nonreferenced memory. How else could it find those without active search?

matsp
12-01-2008, 06:06 AM
I'm not talking about garbage collector libraries, I'm talking about the builtin garbage collectors in some languages. Imagine that someone allocates huge junks of memory and references them with each other, makes many complex structures inside that memory. Then suddenly, the code removes references to most parts of that memory - it makes no calls to memory allocation/deallocation functions, just sets a few things to zero. Garbage collector finds that and deallocates nonreferenced memory. How else could it find those without active search?

And why do you expect that to be any different from the best available garbage collectors? Builtin garbage collection should be AT LEAST as efficient as library based garbage collection - it is obviously not as efficient as directly telling the C library which bits of memory are needed and which are not - and depending on the circumstances, it can be pretty darn inefficient, but it's not a "scan everything all the time" - there are more clever methods to solve the problem (involving reference counts, trees and other clever stuff).

--
Mats

CornedBee
12-01-2008, 07:44 AM
In fact, builtin garbage collectors are better than library collectors, because they have more information they can use.

Let's look a generational, exact, compacting garbage collector like it is used in .Net. Here's how it works:

1) When the allocator is low on memory, it will start a Gen0 sweep. Generation 0 is a pretty small (a few hundred k perhaps) memory area where all new objects are placed. Because the GC is exact, it knows exactly which memory locations might contain references and looks only at those. Because most objects are very short-lived, chances are that most of generation 0 will be freed at this point. This sweep is very fast.
2) The objects not collected during a Gen0 sweep are compacted and promoted to generation 1.
3) If generation 1 exceeds a certain size, a Gen1 sweep is initiated. This works exactly like a Gen0 sweep, but generation 1 will be larger. What survives is promoted to generation 2.
4) Generation 2 is the highest generation. It is swept very rarely. Most things that survive to be promoted to Gen2 aren't freed until program shutdown anyway, or at least until completion of a lengthy operation.
5) Very large objects would mess up this scheme by filling a generation too easily. They are handled completely separately, with a classical free list scheme similar to classical allocators.

The key points here are:
1) Most of the time, only Gen0 is swept. This is a very small area. So it doesn't search the entire memory.
2) The collector is exact. It knows where the pointers are. It doesn't need to search memory for pointers. It can follow the chain of pointers and mark each object it encounters as live.
3) Due to compaction, allocation is extremely fast. It's nearly as fast as stack allocation. Stack allocation is one pointer addition. Unless a sweep is initiated, managed allocation is one pointer comparison (is gen0 full?) and one pointer addition.

C_ntua
12-01-2008, 08:08 AM
And there are some (or many) GC for C and C++. The people that made them explain how their GC can be more beneficial than allocating/deallocating memory. They also explain how their GC can slow things down in some occations. So it depends on what you are doing.
GC are getting better and better, so they have potential, that is all to say

maxorator
12-01-2008, 08:23 AM
I excluded library collectors because I know nothing about them, not because I think they're better/worse.

I don't know, I just can't accept it... not cleaning up after yourself is a violation of programming fundamentals IMO. I think everything that is opened, must be closed, what is allocated must be deallocated, what is mounted must be unmounted and so on. Why do modern programmers fight against these obvious rules of universe?

laserlight
12-01-2008, 08:33 AM
I don't know, I just can't accept it... not cleaning up after yourself is a violation of programming fundamentals IMO.
If you can avoid explicitly cleaning up after yourself, why not? The same idea applies with the use of smart pointers and containers that perform RAII in C++: since the components you use clean up after themselves, you do not need to explicitly clean up afer yourself.


I think everything that is opened, must be closed, what is allocated must be deallocated, what is mounted must be unmounted and so on.
Yes, and ideally a garbage collector will also accomplish these tasks.

CornedBee
12-01-2008, 09:27 AM
Programmers fight everything that is not part of their core job: solving a specific problem. Thus, when the problem is "write a data entry application", they'll fight everything that isn't directly part of this problem. Let's face it, memory management is not directly part of any problem except "performance snail" and "memory hog". Until these animalistic difficulties raise their ugly heads, programmers will be all too happy to shunt memory management as far to the side as possible.

Personally, I'm satisfied with the deterministic RAII capabilities of C++ in most situations, and annoyed by the lack of consistency in resource management in GCed languages. (Why is memory different from file handles?) But I don't have anything against garbage collection per se.

Elysia
12-01-2008, 10:59 AM
In fact, builtin garbage collectors are better than library collectors, because they have more information they can use.
This seems like inefficiency.
First, the promotions. Although it is good that they are promoted so they are not sweeped as often, promotion takes time.

Due to the different generations, allocation must take more time, or, if not, then deallocation or sweeps must take longer because there must be time dedicated for managing the whole generations thingy.

And regardless if it's a small area or a big area, it must be swept, which takes time, along with the constant lookup of pointers. Even if it knows where they are, it must take linear time because they have to be stored somewhere.

And as you say, some allocations can abuse this.

All have its ups and downs, and this is why I don't like garbage collectors. I'm old-fashioned and like control over it myself.

And also, I don't really believe garbage collectors are faster. Not unless there is significant evidence of the contrary.

CornedBee
12-01-2008, 11:14 AM
This seems like inefficiency.
First, the promotions. Although it is good that they are promoted so they are not sweeped as often, promotion takes time.
You really, really, really need to do research before making arguments.
Promotion of all objects at once is actually a single pointer assignment.


Due to the different generations, allocation must take more time, or, if not, then deallocation or sweeps must take longer because there must be time dedicated for managing the whole generations thingy.
No, and no. Allocation is not slowed down by generations at all. Deallocation isn't slowed down at all. Sweeping isn't slowed down at all. Compaction is the slowest part, but compacting isn't there because of generations; it's there because it's what allows the fast allocation and because it prevents memory fragmentation. Also, in the two typical cases (determined by the designers; I cannot vouch for their data collection methods), which are that nearly no objects survive and that nearly no objects are deleted, compaction is fast, too.


And regardless if it's a small area or a big area, it must be swept, which takes time, along with the constant lookup of pointers. Even if it knows where they are, it must take linear time because they have to be stored somewhere.
Yes. It takes linear time. Interestingly enough, though, it really doesn't take all that much time in comparison to managing heap data structures. N deallocations with M active memory blocks in a free list tree take N*logM time. N deallocations in a GC system take M time, but with M bounded by the size of Gen0, not all allocations.


And also, I don't really believe garbage collectors are faster. Not unless there is significant evidence of the contrary.
You can easily construct pathological cases either way. (The pathological case for the .Net garbage collector is to allocate a string of objects which have sizes that vary randomly between 1 and 60000 bytes, and giving each a 50% chance of being added to a global list that keeps it alive, or else being dropped immediately.)
Unless you really have the patience to create a big program twice, though, you can't measure real-world performance reliably. Even then, you'd need a team of experts to agree that yes, the program is otherwise a fair comparison.

I still suggest that a modern GC is faster than naive manual memory management in many, if not most, cases. By naive I mean that nothing beyond the native general purpose allocator is used.
You can always optimize manual memory management, something which is difficult (but not impossible) to do with a GC. You can use memory pools for mass deallocation, simple segregated storage for things like node-based containers, and all the other tricks to make memory use more efficient and less fragmented. But all this goes with significant effort.