• 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
slicer4ever

Top Or Bottom?


38 posts in this topic

Reading his most recent version of his The C++ Programming Language book makes it look like Bjarne does top too. His first code from 16.2.3 Access Control:

class Date{
      int d, m, y;
public:
      void init(int dd, int mm, int yy);     // initialize

      void add_year(int n);                  // add n years
      void add_month(int n);                 // add n months
      void add_day(int n);                   // add n days
};

I don't know his reasoning behind it, but I do know mine. My reasoning is, since the default is private why change it to public just to turn around and make it private again. 

Edited by BHXSpecter
0

Share this post


Link to post
Share on other sites
In C++ private as default class access modifier was a style choice with a solid reason, and not salt on banana:

Well yes, exactly. that is what I'm saying. Hence the pittoresque example smile.png

 

When you write class foo, you are implicitly requesting from the compiler:

class foo
{
private:

The private: is implied, since that is what class is about (in contrast to struct).

 

If, on the other hand,  you put the private members first, you are requesting from the compiler:

class foo
{
private:
public:

It's legal, but absurd. Nonsensical, like putting salt on a banana and throwing it away. Or, like producing a 24k gold zippo and painting it black because you don't like gold (no kidding, one well-known designer actually did that in the 1980s...). You ask for private and immediately throw it away.

 

 

The logically correct thing (leaving protected out of consideration for simplicity) would be to either:

struct foo
{
    // here be public stuff
private:
    // blah
};

or

class foo
{
    // here be private stuff
public:
    // blah
};

Of course, "struct" does not sound nearly as cool as "class", so nobody uses struct (other than to bundle together 2-3 PODs without methods, maybe). But actually it would be the correct thing to do, if that is the behavior you want.

Edited by samoth
0

Share this post


Link to post
Share on other sites

I don't know Samoth, I see your point but I would imagine most people don't use class or struct based on implicit accessibility (and go for the more traditional class = complex container with logic, struct = POD approach), so from that point of view it's not nonsensical at all, as the default accessibility doesn't factor into the decision either way, i.e. the programmer did not "ask for private/public", but for a struct or for a class. The fact that the language has some rules about what the default accessibility is is just irrelevant from that perspective.

 

To me this appears like a style decision, depending on how you interpret the more subtle parts of the language. In your case (the pedantic view, if you will) you prefer to honor the default accessibility settings. In the other case, the programmer prefers not to rely on them (or even know they exist at all) and to explicitly define his own accessibility fields, rearranging them to his liking. The final code is the same, and each style is equally correct "philosophically" from the corresponding perspective.

0

Share this post


Link to post
Share on other sites

Well, it sure isn't wrong to do one or the other.

 

Clearly, this is pretty much an opinion-based (or preference-based) decision. And yes, I certainly agree that the common understanding is that a class is rather the complex thing with built-in logic, and a struct is a few PODs tied together in one lump. Which is likely the reason (apart from the fact that "class" sounds more classy) why everybody writes class for classes (regardless of layout or accessibility).

 

Still, for some reason, Mr. Stroustrup decided that struct is public by default, and class is private by default. I wouldn't know his personal reasons for that decision, but it's apparently something that made sense in some context. Maybe he wanted to make everything private by default, but finally decided to leave struct as it was because C++ was just C with classes then. Or, something else, who knows.

 

Either way, as it stands, there's the way that I personally find "the correct way" due to these defaults, and there's the way that I personally find "nonsensical", since it does the exact opposite. That doesn't have to mean that my opinion is the only correct one, but it's how I feel about it.

 

In the end, like all languages, programming languages, too, are for expressing an intent, and as long as the compiler (and the people around you) understands what you want, it's fine.

0

Share this post


Link to post
Share on other sites

structs are public by default because that was most likely how they were in C and he just kept it in C++ since C is a subset of C++. He made classes private by default  because they were designed with data hiding in mind.That is what I was told in my programming class years ago.

0

Share this post


Link to post
Share on other sites

C is a subset of C++
Hahahaha... careful, never say that aloud without looking over your shoulder first. You risk being burned at the stake by two angry mobs  biggrin.png

 

But yes, I agree that this was likely the reason for several design decisions (including this one) a long, long time ago when C++ was C with classes.

0

Share this post


Link to post
Share on other sites


Hahahaha... careful, never say that aloud without looking over your shoulder first. You risk being burned at the stake by two angry mobs

Then they would have to burn Bjarne Stroustrup at the stake too as he still says that in his recent edition of The C++ Programming Language. :P

0

Share this post


Link to post
Share on other sites

 


Hahahaha... careful, never say that aloud without looking over your shoulder first. You risk being burned at the stake by two angry mobs

Then they would have to burn Bjarne Stroustrup at the stake too as he still says that in his recent edition of The C++ Programming Language. tongue.png

 

 

It does say "with minor exceptions", though... which I guess is true, even if I don't personally consider them minor.

0

Share this post


Link to post
Share on other sites

For me:

 

  1. Using declarations
  2. Private typedefs
  3. Private enumerations
  4. Private constants
  5. Private classes
  6. Public typedefs
  7. Public enumerations
  8. Public constants
  9. Public classes
  10. Private member variables
  11. Public member variables
  12. Private member functions (ctors, dtors, assignments, modifying functions, status functions, comparison functions)
  13. Public member functions (ctors, dtors, assignments, modifying functions, status functions, comparison functions)
  14. Friend declarations
  15. Free function operator overloads for class and class members (outside of class)

I prefer to not have ambiguity: it keeps me from having to wonder.

 

As for why... I am not sure. I feel that types are first. For functions, I read documentation, but for types, I feel that gleaning the header file is more likely, since there are few parameters or other such intricacies, unlike with functions. So, using declarations and types at the top. I put member variables in the middle, before functions; chances are, you aren't supposed to pay attention to those, so having them in the center, while types and the interface are on the extremeties, makes sense to me, and because of the old C (and other languagues') paradigm of putting variables at the top of the block, before everything. I feel that private should go before public, because of the default member access of classes, and habit. I sort member functions by their purpose, as noted above. Free functions generally go last, due to reliance on types declared earlier in the translation unit.

 

I also sort type and variable declarations.

 

 

 

...What?

Edited by Ectara
0

Share this post


Link to post
Share on other sites

Hmmm... my C# style does not fit into either category neatly.

I do:

- Fields
- Properties
- Constructors
- Methods
- Explicit interface implementations

(I don't sort any of them by access modifier)

 

Same kindda

 

- const

- fields (that have no related properties)

- properties and fields, with collections and generics first

- delegates and event handlers

- constructors

- event methods

- methods organised by #regions based on interface

- and if destructors are needed it goes together with the disposer method (not property) in a #region at the bottom

 

Although I doubt this is common practice, to keep statics (when necessary) separate I make use of partial keeping statics separate but in the same partial class.

 

As for C++ it is straight up bottom

Edited by Strix_Overflow
0

Share this post


Link to post
Share on other sites

Since I prefer coding constructor forced (defined) objects , for security production reasons, I put public stuff first as I put constructor first. Though it bothers me becouse primarily I develop private members as a developer of the class, the public members are rather frequented by others, not by me who designs the class. A header file with private stuff being first also does me good (do not know why though). But I stick to bottom, since it is common coding culture and better for users of my code (though I doubt this too)

0

Share this post


Link to post
Share on other sites

I think my code is generally ordered/grouped by relevance to surrounding code. This means that I pretty much have to use IDE tools to locate a method/field/whatever, but once I do I can usually find helpers and nested calls right next to it, helping me to avoid jumping around alot when reading code. Public/private has no impact on my ordering.

0

Share this post


Link to post
Share on other sites

I tend to organize my classes not so much in terms of visibility, but in terms of complexity. Fields both public and private go at the top. Then properties or any relevant getters/setters (when I use them) go next, because they generally don't do much except set or retrieve the fields. Then the constructors, destructors, and other boiler-plate like copy-constructors, move constructors, etc. THEN methods, arranged by length and importance. Important methods go first, while long methods come last. Also, if I'm adding something new to a class, the new methods go at the bottom, new fields go at the bottom of the field list, etc. Within each of these categories, I tend to put public things before protected before private, but I'm not picky on that particular front. 

 

The reason for this is that often-times I'll spend most of my work in the longer and more complex methods, and they become easier to find when they're at the bottom - since I just have to scroll to the bottom to find the thing I'm working on. Of course, that isn't as big of a deal with IDE code navigation help, but it lets me get a sense by looking at the code file where complicated things are.

Edited by Oberon_Command
0

Share this post


Link to post
Share on other sites
public class MagicalGirl {
    private Top boobs;
    public Top grab(){
        return boobs;
    }
    
    private Bottom datAss;
    public Bottom grep(String g){
        int count = 0;
        while (g.contains("jizz")){
            count++;
        }
        return datAss.stack().get(count);
    }

    public void setBottom(Bottom huge){
        datAss = huge;
    }
}

I have to say, it's a hard decision.

Edited by tom_mai78101
0

Share this post


Link to post
Share on other sites

 

...snip...

 

gatta say, i could have done without reading that.

 

Agreed! He has apparently watched too many animes unsure.png.

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