Jump to content
  • Advertisement

flure

Member
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

133 Neutral

About flure

  • Rank
    Member
  1. flure

    Seg faults?

    Segmentation faults are usually caused by memory leaks. To get rid of them, use a tool such as Valgrind, or alleyoop, which is a frontend to valgrind. It will output all the memeory leaks of your program, including the file and the line in your source code where it occurred, making it easy to correct. Good luck :)
  2. flure

    realloc returns zero

    Quote:Original post by Anon Mike You can try to hack your way around this particular realloc failure or you may discover some sort of corruption that is causing this but in the end... I think the bug should come from posterior memory leaks. The original poster should track them with a specialized tool, as Valgrind for example. Quote:Original post by Anon Mike Quote:but is this a natural phenomenon of realloc to return a 0 that must be handled now & then yes, it is quite natural for realloc to fail. realloc fails when it doesn't find enough space for the new block. But, when it fails, the original pointer is still valid ! That's why, to avoid bugs, realloc should be used with a temporary pointer (see my above post). Quote:Original post by Anon Mike The fact that you're asking for a small amount of memory is irrelevant. Eventually you'll either run out of memory or fragment your heap so bad that an alloc of 0 bytes will fail. He should have to do millions of allocations to stumble upon such a problem. I think the bug is elsewhere. Quote:Original post by Anon Mike Quote:I was under the impression that resizing blocks was vastly faster than full reallocation Only if you're decreasing the size of the memory block or you get lucky and there is a free adjacent block big enough to hold the increased size and your compiler libraries even bother to try to do this. realloc can easily be worse than malloc if you end up copying the original memory needlessly. That happens less than you think. The original poster IS right, realloc is faster. If it finds enough bytes just after the already allocated block, it just has to "extend" the pointer, instead of copying it elsewhere. And this is the most common case. Quote:Original post by Anon Mike Using realloc heavily can also make heap fragmentation worse that it otherwise would be which will make your memory problems bigger. Excuse me, but ... bullshit. As I said above, realloc will try to extend the block. Using a newly created pointer and copying from the source will NOT do that optimisation, thus fragmenting EVEN MORE than realloc. Maybe you should google on "man realloc" before posting such misinformation.
  3. flure

    realloc returns zero

    Quote:Original post by PnP Bios Don't use realloc. 1) create a new chunk of memory 2) memcopy the old chunk to the new one 3) delete the old one 4) reassign the pointer Why not use realloc ? You just say that because you don't know how to use it !! realloc works like this : /* p is the pointer (of type p_type) that we want to reallocate */ p_type* temp = NULL; temp = realloc (p, new_size); if (temp==NULL) { free (p); handle_error_and_quit (); } p = temp;
  4. flure

    bool or int?

    At least in C and C++, there aren't 1-bit datatypes. bool is another name for an integral type (short, int, long). By the way, I would recommend not to use bool. Because bool only handles TRUE or FALSE. Even if that's perfectly what you need just now, when expanding your app, or even just this function, you may happen to be in need of values other than TRUE and FALSE. Thus I recommend you to use enum types for function return values, and even for parameters, at least for clarity. for example, if you have a function like this one : /** * Changes the state of the window. * @param windowstate TRUE for setting fullscreen, FALSE for setting windowed. * @return TRUE if everything goes well, FALSE otherwise. */ bool SetWindowState(bool windowstate); Then I'd recommend you to write it like that : /** * Changes the state of the window. * @param windowstate Specifies the desired window state. * @return information about what really happened. */ eWindowStateRet SetWindowState(eWindowStateParam windowstate); with these type definitions : typedef enum { WS_RET_OK, WS_RET_NOK, WS_RET_FATAL } eWindowStateRet; typedef enum { WS_PRM_FULLSCREEN, WS_PRM_WINDOWED, WS_PRM_ICONIFIED } eWindowStateRet;
  5. Quote:Although using smaller values is more efficient space-wise, it is less efficient time-wise. You forgot padding. On most recent PC, all data is aligned to 4-bytes boundaries. So why use 2-bytes datatypes instead of 4-bytes ones ? That's the real reason why one would use int instead of short. Anyway, in C, nobody's guaranteed that ints are 4-bytes, it depends on the architecture. If you *do* want your data to be 4-bytes regardless of the architecture, then use long instead of int. But, the one real reason i think of why are we all using int instead of long or short, is that it's faster to write :)
  6. Works with Wine under GNU/Linux, except that I can't use the shift and control keys, so I miss a big part of the gameplay ... Anyway it seems to be quite clever and I'm awaiting for a more GNU/Linux friendly version :)
  7. flure

    Enum's

    try this : enum DayIndex { Monday = 0, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday }; std::string DayNames[7] = { "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday" }; DayIndex day = Tuesday; // for example cout << DayNames[day];
  8. flure

    fprintf is buggy

    just replace %n by %d and read the manual page about [f|s|sn]printf ...
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!