Cheat Engine

[hcavolsdsadgadsg]

I don't really have much need to check the input at all, just passing a class instance by reference, that's the extent of the work being done... at the moment, at least. Is it generally preferable to wrap things like this in getter / setters?


Also on the subject of style:

createBuffer(BUFFERTYPE type, Buffer& b);

vs

createVertexBuffer(...)
createIndexBuffer(...)

They're both just simple chunks of memory at their core, whatever information needed about them, like number of verticies, can be figured out easily anyway. It would be condensing two almost identical implementations down to one.

[HomerSexual]

If this is for yourself, I would say go with solution 1 and document it well in code. But as far as standards are concerned, solution 2 is "best". I've talked with many people in industry who say that they have these ginourmous handbooks about readability of code, and that the code should usually speak for itself if written correctly. I think it's obvious that solution 2 is much clearer than 1.

[Slugsnack]

If you're not wanting to do anything else in the getter/setters then use public. You should use get/set instead of public when changing some property implicitly changes another and requires its update. At least, this is the rule I follow. However at the end, it is down to preference and no one is likely to berate you for using one over the other.

[atom0s]

#2 is my personal liking. Will look better as #2 vs. having #1 which will turn into some sort of if/else or switch case.

[hcavolsdsadgadsg]

[Flyte]

Never make variables in a class public. Ever. This is exposing the implementation of a class, when all you want to expose is the public interface that describes the behavior of the class.

It breaks:

• Class invariants, if they exist.
  
• Polymorphism. You don't have the ability to extend the class later.

Furthermore, if you find you're making a lot of getters/setters you're probably doing something wrong. Classes represent objects and methods are a way of interacting with an object of that type (think 'actions') - getting and setting private variables breaks this line of thinking (it also destroys any notion of abstraction).

With regards to the second question, present #2 to the users and use #1 internally - you get the best of both worlds.

[hcavolsdsadgadsg]

I don't really have a lot of getters / setters, but hopefully I have somewhat of a grip design wise.

Right now I have a structure like:


The engine holds and manages the various interfaces. Being primarily a graphics engine though, the rendering device is the beefiest thing by far.

The renderer manages and creates just about everything drawing wise... like surfaces to draw on, which in turn, wrap basic pixel drawing stuff and various types of blits so you don't have to drop down to the actual block of memory yourself if you don't really have to. So to do 2d drawing, there's an aptly named getBackbuffer() function that returns a pointer to the primary surface. Not entirely sure if I like having a surface do its own blits (to another surface even), but surfaces can also load bitmaps, so drawing a picture is simply having it load a file then copy it to the backbuffer.

The renderer doesn't really implement much itself, just wraps most stuff up. Drawing 3d it just pulls data from the buffers and matricies it holds and other objects get to nom on that and do their own lifting, like the vector type implements the transformation to screen space, etc.