Advice on next steps - shifting to OOP

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...

Quote:

---

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.

Quote:

---

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.

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.

Quote:

---

Originally Posted by officedog

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.

Quote:

---

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.

Quote:

---

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.

> 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?

Quote:

---

Originally Posted by zacs7

> 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...

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! :)

Quote:

---

Originally Posted by Elysia

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.

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.

Quote:

---

Originally Posted by officedog

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.

Quote:

---

Originally Posted by Elysia

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++.

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.

Quote:

---

Features and ease to develop modern applications.

---

Then what is a modern application?

Quote:

---

> 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.

Quote:

---

Originally Posted by whiteflags

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.

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.

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.

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? ;)

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.

We could drop the subject, if you want ;) It doesn't really matter to me.

Quote:

---

Originally Posted by Bubba

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://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/viewpo...?thread=115101

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

Quote:

---

Originally Posted by Bubba

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.

Quote:

---

Originally Posted by IceDane

...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.

Quote:

---

Originally Posted by Bubba

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.

Quote:

---

...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.

Quote:

---

Originally Posted by Elysia

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?

Slow.
There should be minimum run-time penalties and maximum compile time safety.

Quote:

---

Originally Posted by IceDane

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.

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.

Quote:

---

Originally Posted by Elysia

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.

Such as? When / how / why?

Calculations with pointers where the type is irrelevant.

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.

Quote:

---

Originally Posted by Elysia

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.

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.

> 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.

Quote:

---

Originally Posted by zacs7

> 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?

Quote:

---

> 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.

Quote:

---

Originally Posted by whiteflags

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.

Quote:

---

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.

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.

Quote:

---

Originally Posted by CornedBee

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?

Quote:

---

Originally Posted by maxorator

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

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.

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

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?

Quote:

---

Originally Posted by maxorator

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.

Quote:

---

Originally Posted by maxorator

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.

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.

Quote:

---

Originally Posted by CornedBee

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.

Quote:

---

Originally Posted by Elysia

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by CornedBee

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.

---

That's a very radical statement (what can be faster than just marking a memory page uncommitted after use?). About manual memory management - advanced programmers can make simple yet efficient memory management code in no time.

Quote:

---

(what can be faster than just marking a memory page uncommitted after use?)

---

I was referring to the general-purpose allocator, i.e. malloc/free on Unix and HeapAlloc/HeapFree on Win32, not the highly specialized (even if more low-level) page allocator, i.e. memmap/memunmap on Unix and VirtualAlloc/VirtualFree on Win32.

Quote:

---

Originally Posted by CornedBee

You really, really, really need to do research before making arguments.
Promotion of all objects at once is actually a single pointer assignment.

---

I'm not really trying to punch a hole through the whole theory or other arguments, just lying out my view of the whole.
And regardless, a bunch of conditions (even if just one) and pointer assignment is extra work, however small.

Quote:

---

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.

---

Of course there is. I'm not talking about a massive slow-down or so, but there must be some cpu time dedicated to managing the generations. Ie deciding to what generation it belongs. Deciding which generation to sweep, etc.
And add compaction to that list of expensive cpu cycles, too. Yes, it can be good. I do understand the principle and fragmentation, but sometimes it can be unnecessary, too. That is a trade-off, I suppose, so I would like to see some options to control that.

Quote:

---

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.

---

That's good and all - but you admitted it. It's slower, even if not by much.

Quote:

---

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.

---

It sounds to me, after all this, that is might just be slower. Even if just a little, still slower.
Of course, this is speculation, but just as you suggest it is faster, I suggest it is slower.
But I actually might think that it might be faster or it might be slower, depending on the area of use.
Doesn't make me a fan, though :/

Quote:

---

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.

---

And that effort should rightfully be reduced. It is our responsibility to make the most out of your applications with C++, since it is a highly flexible and fast language, so I would dearly see tools for that appear.

Thinking of dotNet makes me think of VBA, which completely disgusts me with its speed. It's slow as a crawl!

Quote:

---

Originally Posted by Elysia

I'm not really trying to punch a hole through the whole theory or other arguments, just lying out my view of the whole.
And regardless, a bunch of conditions (even if just one) and pointer assignment is extra work, however small.

---

I really think the point was that if someone tells you your viewpoint is ignorant regardless, you owe it to yourself to research. I'm distantly reminded of fundamentalist Christians reworking intelligent design when it's convenient, just to raise the same tired arguments against evolution.

Quote:

---

That's good and all - but you admitted it. It's slower, even if not by much.


It sounds to me, after all this, that is might just be slower. Even if just a little, still slower.
Of course, this is speculation, but just as you suggest it is faster, I suggest it is slower.
But I actually might think that it might be faster or it might be slower, depending on the area of use.
Doesn't make me a fan, though :/

---

It sounds to me like we're making progress though. I don't want to make you a fan. But it was very annoying that (particularly max) had this illusion that new/delete was done in constant time.

I haven't done the research in a long time so I would appreciate cited corrections if anyone can offer them. new typically fragments its heap into manageable sizes, say 4K at the smallest. When you run out of little blocks it starts segmenting the bigger ones where appropriate. If you've fragmented the memory pool like this, things get interersting. It may be able to compact smaller blocks and send that to you. It can also just perform a "real" allocation, which is as slow as the OS API. But both of these operations take time. Introducing new memory to the heap structure is nontrivial.

The only scheme that I am really familiar with that can speed this up is the free list. The free list is a static linked list of memory blocks--appended to when you delete something. Instead, now new can traverse the free list for a block to return (after initializing it and stuff if delete didn't do that). If the free list doesn't have a block of the appropriate size or larger then it goes to the heap.

Of course, I'm not privy to which compiler vendors use the free list in their implementations. To get it the best thing to do is install some library maybe.

So new/delete is not a performance miracle. It's just often... not relevant to user time. You crack me up sometimes. You're the champion of ease of use, but when it comes to real performance tradeoffs, you defend every CPU cycle. Garbage collection is not an infinite loop at least. *laughs* CornedBee made the distinction that the real cost is only marginally slower. With the benefits it provides, you need to decide where to pick your battles, and get your core job done.

So hopefully this discussion was educational for some of you. Do whatever you want in practice, but don't become a fundamentalist without knowing the subject very well.

Quote:

---

Originally Posted by whiteflags

So new/delete is not a performance miracle. It's just often... not relevant to user time.

---

Just so that you know... I'm trying to compare garbage collection vs manual allocation. Not necessarily new/delete. There are other ways of allocation, which may be faster than new/delete.
Additionally, I once created an array class that was faster than vector, and I'm not kidding. It was a simple matter of allocating virtual memory blocks after another linearly instead of deleting and reallocating and copying data everytime it had to grow.
So what we learn from that is that I will always prefer manual allocation before garbage collection. *shrug*

Quote:

---

You crack me up sometimes. You're the champion of ease of use, but when it comes to real performance tradeoffs, you defend every CPU cycle.

---

Of course! :) That's why I chose C++ and not VB, or C# or Java.

Quote:

---

Garbage collection is not an infinite loop at least. *laughs* CornedBee made the distinction that the real cost is only marginally slower. With the benefits it provides, you need to decide where to pick your battles, and get your core job done.

---

That old argument :/
I don't like it, but I know it's the truth and it hurts.

Quote:

---

So hopefully this discussion was educational for some of you. Do whatever you want in practice, but don't become a fundamentalist without knowing the subject very well.

---

I actually got some insight into some garbage collectors, and while I do appreciate the work that goes into making them as efficient as possible, I still don't think they can beat manual allocation... *shrug*

I usually manage memory so that the amount of allocations is minimal - mostly only on loading data/save files/whatever and startup. If the amount of data grows a lot on runtime, then I allocate by very big pieces at a time - it's not too difficult to implement.