Yep. This whole discussion just seems like a C vs C++ styleguide slapfight.
Having the functions that operate on the struct attached directly to the struct declaration, vs having some functions that the first parameter is the struct on which the function operates, doesn't seem like a particularly meaningful distinction to me. OK, you like C-style programming in favor of C++-style programming, congrats. It's still a class either way.
It's an extremely common pattern in C to have a struct with a bunch of associated functions which behave exactly like methods, taking a pointer to the struct as their first argument.
Well, function pointers are only one aspect of this. Suprisingly many experienced C programmers I've met don't know that you can safely cast pointer to struct to pointer to it's first field, which is pretty important trick to achieve reasonable OO (with real inheritance) in C.
This is an awful article. It is extremily rare to choose `struct` vs `class` because of their default visibility. It is much more usual because of style.
Is it a functor? Is it a data structure? Do I need C-compatibility? Do I want to encapsulate behaviour and validate correctness? Do I want to maintain the company style?
> the only difference between a struct and a class
In C++ land, this would be true.
C doesn't let you write methods within structs. C structs don't even have inheritance. No virtual table is generated. There is no single-dispatch mechanism.
Not true. Using C structs themselves in C++ is very common - when you include the C header file, the relevant declarations are wrapped in "extern "C" {}" which gives structs C semantics. You can do this because C++ is backwards compatible with C.
Most of the time when you use a struct in C++ you're just ignoring most of the capabilities of objects (which is fine!). If you declare a struct in C++, you're getting an object. The only difference between the struct and class keywords in C++ is the default privacy of the members.
Maybe it was the era that I learned C++ (which was in the 98 days), but I was taught something closer to this convention, and didn't realize until just now there was such little difference by the book. Just bundling some data together? Use a struct. Doing more? Use a class.
I still think this distinction is useful overall, because there often is more of one in many languages, but I will be more precise when speaking about C++ specifically in the future. I would also still argue the same thing overall, that is, Rust does not have what C++ calls classes. Our structs are apparently even simpler than C++ structs.
Also a class in C++ is by default exactly the same as a struct (except for default access control which is a minor thing). An OOP style class would be any class type (including struct) with virtual functions which you would have to opt in.
That was not the point I was trying to make. What I was trying to make it that the need for encapsulation and abstraction does not go away, and that people will re-invent them if they are taken away.
More specifically, I think structs, or something like structs, are inevitable. And methods are also inevitable. Whether it be by OOP-style classes that contain both fields and methods, or in the Julia style where you have structs, and global-scoped functions with struct-specific methods, or in the Rust style you linked to with structs that conforms to a trait, which implements the method is not important for my specific point.
All three ways add complexity to the language, but such kind of complexity is unavoidable, because it will show up in the code anyway. Even if you use C, which does not have an explicit connection between structs and functions (i.e. methods), you will just write functions where you document that such and such argument should be a pointer to such and such type.
I believe your conclusion is rooted in a lack of experience in writing C code. You seem to think that developers are going to go out of their way to allocate and initialize the struct manually. In almost every codebase I've worked in, struct types always have an allocation/initializer function, so I look for that first, and generally find a set of other functions that are used to work on that struct type, organized into a single .c file usually named something similar to that struct type. It is a convention, not syntactic sugar. In C++ or C#, you have syntactic sugar that makes it more difficult to violate the rule, but does not actually enforce anything.
Agreed. In the literal sense they are very much two keywords for the same concept, but culturally, a struct is POD and a class is not.
Personally I think the mistake was in making them the same. In Ides, a friend's LLVM-based PL (no contributions here, just some discussion and ideas), an instantiated 'struct' is a non-polymorphic object rather like in C#; this allows for more expressive code by logically attaching methods to the struct but without creating a vtable and breaking C compatibility.
What's the difference between struct and class in C++? IIRC the standard says they're the same except that members are public by default on struct and private by default on class. You could as well argue that C++ doesn't have structs.
The different allocation between structs and class objects in C# is a total head scratcher. Didn't it ever occur to the language designers that someone might want to choose how to allocate memory?
I think the “somehow” is not too hard to guess… it is easy to think that “class” is the only way to declare a class, especially since “struct” is taken from C. I’m sure very few intro C++ explanations ever mention “struct” as a way to declare a class.
Having the functions that operate on the struct attached directly to the struct declaration, vs having some functions that the first parameter is the struct on which the function operates, doesn't seem like a particularly meaningful distinction to me. OK, you like C-style programming in favor of C++-style programming, congrats. It's still a class either way.
reply