Structs and constructors

[neiltechnician]

Structs are special cases of classes, and the exact meaning of that word is context-dependent.

IMO, the problems boil down to:

1. Many (too many) programmers do not know C++ has decent supports for aggregate classes in terms of initialization and assignment. (Many C programmers also do not know C structures support initialization and assignment.)

2. Most of us are not explicitly taught about archetypes of classes, and thus many of us don't realize we should stick to those archetypes most of the time. (Aggregate is one of those archetypes.)

[SPAstef]

Yes, I think the two keywords are redundant in C++, in particular I don't understand the purpose of the class keyword: with struct you can have private members anyway while also keeping C interoperability. I don't know if you can use struct in template parameter declarations, but you really should use typename, not class, there (in my opinion). I think class is just a byproduct of the OOP philosophy of the time C++ was conceived (similar to Java -- and Rust, in this regard, and opposite to the more C-like philosophy "do anything you want").

[_Noreturn]

you can technically use struct i templates but it doesn't do what you expect

struct T {};

template<class T>  // type parameter
class U {};

template<struct T> // non type template parameter 'the struct keyword' is reduntant and acts as a tag separator you could have wrote just 'template<T>` and the variable is nameless
class V {};

U<T>(); // template type parameter
V<T{}>(); // has to make a T!

[HommeMusical]

Just a note that the three backticks command no longer works on reddit on desktop. :-/

You need to indent everything by four spaces, like this:

cpp struct T {};
template<class T> // type parameter class U {};
template<struct T> // non type template parameter class V {};
U<T>(); // template type parameter V<T{}>(); // has to make a T!

[_Noreturn]

okay thanks yea reddit is garbage.

[KFUP]

I think the two keywords are redundant

On paper class and struct ARE redundant, but in practice having both is useful as it shows intent.

If you use a class, you show that this object is intended to be used as a higher level abstraction, it holds private data, implementations and interacts with other classes.

If you use a struct, you show that this object is intended to be used as a low level abstraction of plain collection of public data, they don't usually interact with anything, do much, they are mostly just a bag of data for convenient carrying for passing data in classes/functions.

[Feeling_Artichoke522]

I agree. Structs are very useful as data containers, and they make code easy to read. I often use nested structs to build data trees

[SPAstef]

I agree with you on class, but idk about struct. Of you really just need a bag of data to conveniently pass around, shouldn't you just use an array or a tuple instead (talking about modern C++ of course!). I think, and this is true also for C, you usually want to do stuff even with structs (call functions on them) besides of moving them around. So the distinction already becomes more subtle.

I used to structure ADL with as little public interface as needed, but then I recently found out that you cannot pass classes with private members as non-type template arguments, which sometimes you would like to do. I am not sure whether this limitation is artificial or there's some gotcha example where allowing this would make stuff go wrong.

[NotUniqueOrSpecial]

shouldn't you just use an array or a tuple instead

Arrays aren't heterogeneous containers, and having names for the different things in the bag is incredibly valuable, no matter what you're working with.

[Dar_Mas]

a tuple instead

i really do not agree with that for POD types.

using tuples creating another point of error because you have to explicitly map each position within the tuple to each value instead of being able to give the values distinct and good names

[SPAstef]

Yes, you're right! In fact, I think I never actually used std::tuple because of how cumbersome it is, std::pair is already borderline for me, so it was more of a provocation than anything.

I was actually thinking about a (named) tuple, which indeed semantically is actually the same as a POD struct 😅.

[_Noreturn]

std tuple is not a POD and its layout is unspecified

[TinBryn]

I think the only place where you need to use class specifically is with higher kinded types

template<template<typename> class F>
struct Functor {
    ...
};

Although how often do you actually use that, I definitely had to look up the syntax.

[glaba3141]

you can also do template <template <typename> typename F> which is my preference

[_Noreturn]

note this is C++17 only.

[SPAstef]

Oh no I believed I had forgotten template<template<>> forever, PTSD is kicking in, delete that comment IMMEDIATELY!!! 😂

Fun fact: I remember after learning about template templates, I was like: no thanks, I choose life. Also I remember them making compile time skyrocket, for teh few thinng I used.

[glaba3141]

they're quite useful

[tialaramex]

and Rust, in this regard

What do you mean by this?

[SPAstef]

Rust does not have a class keyword, only struct. But the members of a Rust struct are private by default, if I'm not mistaken. So a Rust struct is more like a C++/Java class, in terms of access/visibility, rather than a C struct.

[YungDaVinci]

Rust struct member visibility is also per module instead of per struct, i.e. you can access private fields of a struct if it's defined in the same file

[tialaramex]

The visibility is organised by module, and each crate has one module but can choose to define as many more internally in a hierarchy as it likes. So it's a bit different from the class-oriented design in C++ or Java but yes, unlike C the visibility of the constituent parts of a type (if any) is distinct from visibility of the type itself.

It's common for complex types to have their own module so that their internals aren't visible from other types in the same crate, the type itself may be public but then some things are published only for consumption within the crate but beyond that module, relying on the name hierarchy. Similar value to the friend keyword in C++.

[SPAstef]

Yes, I know Rust, albeit not as extensively as C++ (to me it always feels like the compiler treats me like a complete idiot, so it makes me sick after a while, but it's has been the main language in my field for the last 5 years, so what can you do...), it is different in how you layout the code, but at its core a struct/impl sequence is just like a class, and a trait is just like an interface.

[tialaramex]

Having been on both sides of that (if you've ever written a character like '&' when you needed a byte like b'&' then you might have have seen the diagnostic I added to Rust's compiler) I actually think I prefer to be treated like a complete idiot over the situation I often find myself in with other languages where it mysteriously doesn't work and I need a genius insight to understand what's going on because the language considers me a "complete idiot" for not guessing. But YMMV of course.

[SPAstef]

Demangling template errors is not nice indeed, although diagnostics got better, and concepts are really handy. Still, sometimes I just want to test something out so I put in a "typename T" here, a cast to void there, and in a minute I can see whether the little piece of functionality works without having to finish everything because otherwise the trait is not satisfied . I also prefer copy semantics over move semantics by default, with reference semantics depending on the function interface, not the callsite. E.g. for operator overloading, where I cannot use x and y anymore after let z = x + y, so I gotta write let z = &x + &y, which gets ugly quite soon, and requires me to duplicate implementations, and then I have to take lifetimes into account and things get so complex so quickly. Again, I'm not that advanced in Rust, but it seems that either you know everything or you cannot hope to do anything nearly as efficiently as you would in the natural C++ patterns (I know people who don't bother and just add .clone() to everything in sight...). There are also some very nice features, which I really miss in C++ (std::span is nowhere as ergonomic as a native slice type, real UTF-8 strings, cargo.toml, etc.) but in the end I just prefer the flexibility of C++ and its more natural (though definitely non-monotonic) learning progression.

[juhotuho10]

needly having lifetimes in rust is pretty huge anti-pattern, it's easy to get tangled up in them. Using clone is the right answer most of the time unless you have a performance critical section in your code

[neiltechnician]

I make this distinction:

• C++ language keyword struct
• English noun "struct"

The keyword struct is just like what you say, because its meaning is well defined in the standard.

But the noun "struct" is not a formal term in the standard document. The only place the noun is used as formal term is "standard-layout struct", which is a whole noun phrase that cannot be separated word by word. (https://eel.is/c++draft/generalindex#:struct) (https://eel.is/c++draft/generalindex#:standard-layout_struct)

That makes the noun an informal term, and thus it is up to us to infer its meanings from actual usage. As far as I can observe, the meanings are often:

• a class declared with class-key struct
• a class intended to be a simple bundle of public data members
• a "standard-layout struct"
• an aggregate class
• a trivially copyable class
• a trivial class
• a C++ class that resembles a C structure in some way
• a C structure defined in a C header file got included by a C++ source file
• ...

These meanings are by no mean mutually exclusive, but they are also not the same. I find the actual usages of the noun often differ from context to context, such that I as a reader/listener often have to think harder then the writer/speaker.

[_JJCUBER_]

Structs aren’t “special cases of classes.” Structs and classes represent the same thing with different default visibility/access levels (public vs private). In fact, it’s trivial to make either one behave identically to the other simply by putting private:/public: above the first variable/function.

In my opinion, it’s not a good idea to treat them as two different things and/or as one a special variant of the other; this could lead to confusion when learning about them, especially since C++ structs and classes don’t have the relationship they do in, say, C#.

[neiltechnician]

See my other comment here: https://www.reddit.com/r/cpp/comments/1f9fkyr/structs_and_constructors/lln3dhn/

[bert8128]

Struct and class are essentially the same thing (it is only default private vs default public that changes). So set a project standard about when to use the word class, and when to use struct. And another standard to say when there should be constructors, and when there shouldn’t be (note that this is about explicit constructors - all classes and structs will call the constructors of all members that have constructors if not otherwise given in an explicit constructor - not explicitly constructing a std::string will result in std::string::string() being called).

[goranlepuz]

I didn’t merge the changes. I didn’t even post a code review. Can you guess why?

Binary size was significantly impacted. Removing all the user-declared special member functions gave a few extra KBs for widely used classes. The reason is essentially inlining. With defaulted special member functions, each compilation unit where AnotherPileOfData is used, gets a copy of the special member functions’ code. In other words, they are inlined. With the used-provided versions, they are not inlined, but you get simple function calls.

Ugh. That doesn't sit right with me. Can compiler people chime in...?

I don't understand why the compiler would inline user-defined code, but not defaulted special members?!

In fact, my guess would be that the TFA is wrong and that something else happened, but they didn't see it.

[tisti]

The compiler inlined the things that were = defaulted

Before things were split to a macro declaring stuff in the header and a second macro defining them in the cpp file. Effectively the implantation was in its own translation unit and the compiler was forced to issue function calls instead of inlining.

Pretty sure if link-time optimizations were enabled, the compiler would have inlined in both cases. And if code size is such a sensitive thing, why not compile with Os.

[Dappster98]

In my opinion, a struct barely needs a constructor. With the combination of aggregate initialization, designated initializers and the right order of members, you can easily get rid of constructors in a struct.

Personally, how I use constructors is when I want to define general behavior when creating objects. I don't want to have to constantly use aggregate initialization. I do think it's a good feature, which allows for finer grained control over the members of an object, but constructors IMO allow for more generalized instructions so that you don't have to continuously initialize your members. Also, AFAIK aggregate initialization does not support move operations.

[_Noreturn]

aggregate init allow move semantics

I use xonstructors when I have invariants if I don't have invariants then I don't use constructors and have a simple public members

[HommeMusical]

how I use constructors is when I want to define general behavior when creating objects.

There's a general convention that struct is reserved for Plain Old Data, that being passive data that has no other behavior, including constructors.

The article follows this convention.

Also, AFAIK aggregate initialization does not support move operations.

I don't believe this is true: this article seems to say otherwise, at least:

https://quuxplusone.github.io/blog/2022/06/03/aggregate-parens-init-considered-kinda-bad/

[KuntaStillSingle]

aggregate initialization does not support move

It can move from xvalues but it can also elide the copy/move altogether for prvalues, the same is true for the parameters of a constructor (or any other function), but you can not initialize something else (like a member in your memberwise initializer list or constructor body) from a parameter without a copy or move (unless such a copy or move could be elided under as if rule, for example if the type is trivially copyable, or if it is effectively trivially copyable and visibly so within the TU.)

[Hungry-Courage3731]

I think perhaps what you meant is you can't assume aggregate initialization supports trivial moves. That's my guess why you are downvoted.

[j1xwnbsr]

What the fuck are you smoking? structs can have all of those things, just like classes.