• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
cozzie

Struct versus class?

46 posts in this topic

Thanks, that's a nice addition. In my vector struct indeed the members are all accessible (and should be).

Would you add for example a function in the struct to calculate the cross or dot product? Or would you add 'Global functions' (yikes!! smile.png) in the same header/ cpp files

Edited by cozzie
0

Share this post


Link to post
Share on other sites

One thing I like to do with C++ is use structs as classes, but hide the class related code when C is accessing it.  This came in handy a few times for me.

struct whatever_t
{
#ifdef __cplusplus
public:
  void func1();
  int  func2(void*);
  byte func3(char, float);

public:
#else
//  struct _vtbl
//  {
    void (*func1)(struct whatever_t* This);
    void (*func2)(struct whatever_t* This, void*);
    void (*func3)(struct whatever_t* This, char, float);
//  }*vtbl;
#endif
  int var1, var2, var3;
};

#ifndef __cplusplus
 void whatever_func1(struct whatever_t* This);
 void whatever_func2(struct whatever_t* This, void*);
 void whatever_func3(struct whatever_t* This, char, float);
#endif

I once needed the functionality of classes, but at the same time, needed compatibility with C and C++.  This is how I did it.

 

EDIT: Minus the vtable.

Edited by blueshogun96
0

Share this post


Link to post
Share on other sites

I would also like to add that the compiler adds the operator= for any struct, by coping 1-1 all its fields, in a class you generally have to define your own class_name operator=(const class_name right); however there are certain conditions on which the C++ compiler may add that operator automatically (implicitly). If I recall correctly there is yet another difference, but I fail to remember it for the time being, my apologies!

Hope I helped a little

-6

Share this post


Link to post
Share on other sites

structs have an advantage over class of being properly serializable. As soon as your object definition does not contain an advanced datatype pointer, you are fully valid to write it as a struct, which fits for your vector class. But this all is just a question of code producing culture, nothing critical.

 

But as to vectors, I would recomend you to not write algebraic functions as members of a vector, but go for a globaly used Algebra object that takes vectors as inputs and returns, or, manipulates existing vectors for result.

 

 

 

 

-9

Share this post


Link to post
Share on other sites

 

This is completely false. Making something a struct does not automatically make somethings serializable by default. Making something a class does not automatically make is unserializable. In C++, the difference between class and struct is completely cosmetic

I did not say struct is serializable as an implicit fact. I said what it should be in my eyes - serializable. A single struct object, fully operative, can be resurected from its memory foot print. I repeat, not a fact, but an -expectation? Get me? At least this is my vision of a struct, if someone tends to write a struct with function members and all that. I do not expect a struct like this

 

struct vec2d

{

float x;

float y;

CAlg* m_pAlg;

 

void Init()

{

x=m_pAlg.Nod(x,y);

}

 

}

-2

Share this post


Link to post
Share on other sites

You have mentioned that struct/class difference in compiler interpretation is none. It is pure interpratation of a programmer, meaning, a programer should consider struct as a certain manifesting, towards a memory available object, as is. Interpratation and purpose of struct in area of profesional instruction writing still exists! You can(should) reproduce a struct from its own allocated memory- as a self encapsulated object on self memory (what is a definition of a "program" actualy as well). While a class like CSceneManager, is a wide memory object, not reproducible and dependant only on its allocated memory. A struct object is reproducible and fully operatible on its member functions, or outer functions expecting this object, from its allocated memory. From a programmer professioal view, if someone codes struct that depend on outer memory, is an unprofessional programmer who does not use instruction writing properly. You of course does not have to write a struct to achieve this, but if you encourage yourself to define object as a struct, be aware of not making yourself look like a noob.

-4

Share this post


Link to post
Share on other sites
Thanks for all the replies and help.
For now I'm convinced that for vector3 I'll keep the struct and for functions that don't actually change or return "this" make free functions within the same header/cpp files for keeping code maintainable. Basically that means only operator functions within the struct, and maybe normalize since it directly changes the members.
1

Share this post


Link to post
Share on other sites

One thing that I think that Johnny is trying to say is that it's a common convention for struct to be used for POD types, and class to be used for non-POD types.


No, that's the problem. He started out by saying the common convention was a fact. Whether that was actual lack of knowledge or lack of skill in expressing himself in English will be difficult to ascertain.
However now he's moving towards saying no 'professional' programmer would use a struct for something else or look like a 'noob'. As Aardvajk already correctly pointed out, not exactly the most uncontroversial course of action. There is also the issue that even a pure POD struct is not the safest for serialization (thanks to padding) if you need portability between different compilers and/or platforms.

As someone who sometimes enjoys himself a brainteaser or two using template meta-programming I'd also like to point out a different major point of use for structs: templates, like this standard library construct among many.

While I personally used the structs-for-POD-like-constructs convention in the past, nowadays my personal heuristic has become more 'use struct { /* content */ } over class { public: /* content */ }'. Especially with templates, is far more convenient.

Edited by BitMaster
0

Share this post


Link to post
Share on other sites

Don't suppose you could give a brief summary of how structs are useful with templates could you? It sounds really interesting .

0

Share this post


Link to post
Share on other sites
This is really not a good topic to make examples out of thin air for, but there are plenty of example in the standard library. For example std::iterator_traits uses template specialization to grant access to several iterator-related information. Since a pointer was always intended to be a fully qualified iterator this could not have been done as member typedefs of the iterator type.

Then there is practically everything in the type_traits header of the standard library.

One of the simpler things I used (partial) template specialization for in the past was a uniform manager. When calling the setter with the right type (for example glm::vec3) then all parameters (type used, number of components, ...) could be derived automatically just from the static type information.
The interesting bit was that I had to change neither the GLM headers nor explicitly implement GLM-parameters in my uniform class. It was possible to do the same with any other type just by adding a small helper struct similar to std::iterator_traits without modifying the core headers.
Important here was the fact that everything interesting happened at compile. Once the optimizer had its way there was no difference in the generated code compared to setting all the uniform parameters by hand.

Edit: None of these things really require structs but they are generally implemented using structs (even in the standard library). Mostly because 'struct { ...' is shorter and easier on the eyes than 'class { public: ...', especially if there are a lot of them around. Edited by BitMaster
0

Share this post


Link to post
Share on other sites

Truth be told, I consider the introduction of class to be one of c++'s minor warts. I'm not sure why it was included--probably some amount of hitching-on to OO-lingo of the day, and a possibly misguided attempt to encourage people to use private data more. But certainly it accomplished nothing that simply adding public, protected, and private access modifiers to struct could have.

 

I get that privacy-by-default seems like a good idea in the same way that immutability by default (not found in C or C++ either) really is a good idea, but that's not actually the way people lay out their interfaces. You want people reading the code to see those public member functions first, not have to slog through a bunch of private member variable and member function declarations. I almost always start a class immediately with public:, followed by constructors and assignments. The only time I lead with the default private access level is when I have some private typedefs that are a) dependent types (I like to keep their definition close to the template params so I can see what's going on), or b) used inside a inline public member function. Those times are generally so rare I'd gladly have paid the price of having to say private: right off the bat occasionally.

 

Or, they could have introduced class with default public access (and default private inheritance), and kept struct as it was, supporting only public member variables and no inheritance, and extending it with constructors/destructors only. This would have encouraged their use as POD types, while giving them the minimum necessary additions to make them more convenient and, separately when they were not used at POD types, to let them be written in an exception-safe way (of course, with everything public you can't maintain invariant, but sometimes you might want to own a resource through a pointer or handle and need to clean it up).

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0