Sign in to follow this  

Top Or Bottom?

This topic is 1350 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.


Recommended Posts

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

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

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.

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.

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.

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.

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

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.

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

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

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)

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.

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

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

Share this post


Link to post
Share on other sites
Sign in to follow this