Like Tree1Likes

Advice on next steps - shifting to OOP

This is a discussion on Advice on next steps - shifting to OOP within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Originally Posted by Elysia Spoken like a true C programmer... I like type-safety. Less chance to do many errors. It ...

  1. #31
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by Elysia View Post
    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.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  2. #32
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,169
    Such as? When / how / why?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  3. #33
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Calculations with pointers where the type is irrelevant.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  4. #34
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,169
    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 Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  5. #35
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,525
    Quote Originally Posted by Elysia View Post
    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.

  6. #36
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,169
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  7. #37
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    > 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.

  8. #38
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,169
    Quote Originally Posted by zacs7 View Post
    > 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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  9. #39
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by whiteflags View Post
    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.
    Last edited by maxorator; 12-01-2008 at 03:15 AM.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  10. #40
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  11. #41
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,169
    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 Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  12. #42
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by CornedBee View Post
    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?
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  13. #43
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by maxorator View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  14. #44
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  15. #45
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    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

Page 3 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. OOP flu
    By Hussain Hani in forum General Discussions
    Replies: 15
    Last Post: 06-27-2009, 02:02 AM
  2. Data Mapping and Moving Relationships
    By Mario F. in forum Tech Board
    Replies: 7
    Last Post: 12-14-2006, 09:32 AM
  3. Logical errors with seach function
    By Taka in forum C Programming
    Replies: 4
    Last Post: 09-18-2006, 05:20 AM
  4. recommendation for a good OOP book
    By Mario F. in forum C++ Programming
    Replies: 2
    Last Post: 06-15-2006, 04:28 PM
  5. Folding@Home Cboard team?
    By jverkoey in forum A Brief History of Cprogramming.com
    Replies: 398
    Last Post: 10-11-2005, 08:44 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21