Jump to content

  • Log In with Google      Sign In   
  • Create Account


We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.

Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Member Since 25 Jul 2003
Offline Last Active Yesterday, 05:35 PM

Posts I've Made

In Topic: References or Pointers. Which syntax do you prefer?

23 April 2014 - 02:17 PM

For sure, I plan to make habitual use of them.  I've just read a good deal of RAII which has been touted as 'sufficient' in the face resource leaks.  Perhaps that's all it is, sufficient, but not exemplary.


That's a good point, unique_ptr confers an expected meaning of how the pointer is to be used.  Barring a comment, a naked pointer doesn't say anything about its expected purpose.


While I haven't been on a large project, one that I'm currently working on is coming close.  Relationships are established such that it's important to keep track of ownership issues.  I am vaguely aware that the system is complex enough, that despite my best intentions, I'm going to miss some critical step that will cause future headaches.


A (newbie) usage question:  


Suppose I have a base class and several derived classes.  I maintain a vector of Base (abstract) objects and one for each Derived type objects.  The Base vector is a superset of all the Derived vectors.  A factory creates each derived object and I add it to the Base vector and the appropriate derived vector.  Where should unique_ptr/shared_ptr/etc. live in this scheme?  My inexperienced guess is that it lives between factory (allocation) and storage on the vectors after which point it is moved onto the vector.  Or should it be something different?


BTW, thanks Servant and Ravyne.

In Topic: References or Pointers. Which syntax do you prefer?

23 April 2014 - 09:20 AM

A common style that I've seen is const-references for in-params (which should act like pass-by-value, but are expensive to copy) and pointers for all out params.
The rationale behind this is that it makes out-params very obvious at the call-site, similarly where in other languages the caller must use an 'out' keyword.

It'd be nice if the syntax were a little cleaner in C++, but then it'd also be nice if owning pointers (std::unique_ptr) were a built-in feature like in Rust. C++ is not for people afraid of typing or syntax spew. tongue.png

That would completely kill C++ as being a pay-for-what-you-use / opt-in language. Most embedded systems that I've worked on still use raw-pointers, or a smart pointer that acts like a raw one, but only performs leak detection during development.


Is a valid use of raw pointers for things within a class?  For example, if I construct an object (and correctly release resources if the object fails to construct) and then provide the correct release in the destructor would this be a valid use?  I guess that's the RAII paradigm in a nutshell.  Or would you advocate smart pointers even in this scenario?


I suppose if I need to share a dynamic resource to things outside of the raw pointer containing class then smart pointers become essential.  But even general purpose libraries intended for mass consumption avoid smart pointers because there's no hard bound guarantee that the same smart point convention is followed by programs which use different implementations.  How then is the problem of detecting resource leaks handled?  Is there a method to the madness or are designs/tools up to the task?


If there's any doubt, these are genuine questions and not quibbles with the concept of smart pointers.  I just haven't been on a large enough project to see what disasters might befall the unwary.

In Topic: linker error

07 October 2013 - 09:12 PM

is the line int ccc_win_main() incorrect?

Probably not, but it's also not main.  I'm guessing that in a different execution module, which happens to define main(), it will do some setup of the graphics library and then eventually call ccc_win_main().  You may need to link against this module or you may even need to compile it and then link.

In Topic: linker error

07 October 2013 - 08:43 PM

The entry point in C++ / C programs is the function 'main'.  The linker is telling you that you do not have it defined in your program.

In Topic: Game crashes when character goes out of screen

07 October 2013 - 01:52 PM

I assume your lowest point is y = 0 as you clamp to this value if the character's coordinates ever go less than 0.


mapheight * mapblockehight = 640.  Based on your y=0 position clamp, 640 represents a place "off" the screen.  Pixel 639 is 'on' the screen.  With just the '>' symbol you're skipping the very first line of pixels off the screen.  This means, possibly, that the very top of your character's pixel row will be rendered offscreen, depending on how you define player->y and player->height.  If player->y represents the first vertical pixel and player->height represents the number of pixels in height your player is, you'll have an "off by one" issue in the above checking code.


In your position update code, do you ever clamp the y value?