• (disco) in reply to RaceProUK
    RaceProUK:
    HardwareGeek:
    Will the reception have C food?
    Go fish ;)

    /me draws a card.

    hmm.... got any sevens?

  • (disco) in reply to accalia
    accalia:
    /me draws a card.

    hmm.... got any sevens?

    Hey, wait for your turn!

  • (disco) in reply to boomzilla
    boomzilla:
    Hey, wait for your turn!

    Don't worry, it's just a @RaceProUK condition instigated by an @Accalia in the concurrent thread.

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    boomzilla:
    Hey, wait for your turn!

    Don't worry, it's just a @RaceProUK condition instigated by an @Accalia in the concurrent thread.

    BEST COMMENT YET TODAY!

    :rofl:

  • (disco) in reply to Lawrence

    I worked with one woman who supposedly had a masters in CS. She knew syntax, sure, but I couldn't give her a single task without pseudo-coding the whole process for her. And, even then, she would completely mangle the logic half the time.

    It's one thing if you want to bring in a junior dev to "help out" and learn, but all-too-often, companies tend to have the thought process "I know we need 2 senior developers on this project, but 1 senior developer and two junior developers is just as good". In the end, it just means that the senior developer ends up spending half his time "fixing" the junior dev's work (more, if you actually try and show them what they did wrong), and then gets yelled at when the dealine slips.

  • (disco) in reply to asdf
    asdf:
    Steve_The_Cynic:
    (1) It's portable only if you use std::less to do the pointer comparisons, because that is guaranteed to compare pointers in whatever funky architecture-specific way is necessary.

    Yeah, I remember that. Don't ask me why I needed to sort objects by their location in memory some time ago…

    (Sorry about the delay responding. Company bash in Barcelona, you know the sort of thing.)

    I wouldn't dream of it. One obvious reason is that you need something as a criterion to distinguish two objects, and it's the only thing left. In this case, the "sort by location in memory" isn't that you need them in that order so much as that you need them in an order, and location in memory is guaranteed to be unique for distinct objects.

  • (disco) in reply to dkf
    dkf:
    None of which should stop you from using `malloc()` (or `new` in C++, which is a fancy wrapper round `malloc()`) if you need it. Sometimes people lose sight of that.
    Argh, just noticed this. ```new``` is in no way whatsoever a wrapper around ```malloc```, except if your compiler / runtime environment happens to make it so.

    In particular, this code is UB:

      int *p = new int;
    
      free(p);
    

    And so is this:

      int *p = malloc(sizeof(int));
    
      delete p;
    

    Why? Because C++98 (YMMV on C++11, although I doubt they'd have changed this) says that new and malloc don't necessarily use the same arena, and so they can only be used in matched pairs.

    EDIT: Sorry, forgot to mention that I chose int as the type to allocate to avoid all possibility of arguments about the other thing that new does: calling the constructor of a constructable class.

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    EDIT: Sorry, forgot to mention that I chose ```int``` as the type to allocate to avoid all possibility of arguments about the other thing that ```new``` does: calling the constructor of a constructable class.

    You could use void* p = ::operator new( sizeof(int) ); and ::operator delete( p ), respectively, Those allocate from the same arena as the "normal" new/delete, but do not initialize memory in any way (i.e., no constructors etc). In a sense, those are the actual replacements for malloc()/free() in C++.

Leave a comment on “High Performance Memory Allocation”

Log In or post as a guest

Replying to comment #:

« Return to Article