Why are structs used for linked lists and classes used for binary trees?

[btb4198]

Why are struct use for linked list and classes used for binary tree.

honestly what is the different between a class and a struct?
I have a teacher one tell me that a class was a struct on steroids.
but what does that really mean ?

 

[FactChecker]

I wouldn't describe a class as "a struct on steroids" because it is the main part of an entirely different type of program organization.
A struct is useful any time there is a lot of data that you want to organize in a certain way (a student has an address, several classes. Under an address is a street name, a city, a state, and a zip code. Under each class are several grades, etc).
A class is the basic idea in Object Oriented Programming (OOP), which was a revolution in how to design a computer program. A class is used to define "objects", how they are created and destroyed, how they behave, what data is relevant to them and should remain hidden from anything else, etc., etc., etc. A class may contain several structures of data, along with functions defining how the data can be initialized, modified, read, and deleted. It can also have functions defining how the object should behave in different circumstances.

 

[FactChecker]

I'm sure that you can already think of several uses for structures in programs.

IMO, a good example of the use of a class and OOP is the computer simulation of a traffic intersection. In that, you would want to have a series of vehicles, cars, trucks, bicycles, pedestrians, motorcycles, blind pedestrians, etc., entering the intersection. Your program would want to create each one as an object when it enters the intersection. The objects of different types (different classes) would behave very differently as they go through the intersection. They would be able to keep track of their progress and collect data for themselves. When they made it through the intersection, they would report the results to some central bookkeeper function and then would destroy themselves. OOP and classes make this type of programming much easier to do.

 

[Mark44]

honestly what is the different between a class and a struct?

As far as C++ is concerned ( you posted this thread with the C/C++/C# tag) there is essentially very little difference between a struct and a class. The only difference is that for a struct, the default access for members is public, while for classes, the default access is private.

 

[FactChecker]

As far as C++ is concerned ( you posted this thread with the C/C++/C# tag) there is essentially very little difference between a struct and a class. The only difference is that for a struct, the default access for members is public, while for classes, the default access is private.

It seems that in C++ there is very little technical difference between the two, but that they are conventionally used differently.
By convention, struct is used to store related data elements together whereas a class is used to define the interface to processes associated with the class. (see https://www.fluentcpp.com/2017/06/13/the-real-difference-between-struct-class/)

 

[Mark44]

It seems that in C++ there is very little technical difference between the two, but that they are conventionally used differently.
By convention, struct is used to store related data elements together whereas a class is used to define the interface to processes associated with the class. (see https://www.fluentcpp.com/2017/06/13/the-real-difference-between-struct-class/)

Right, but in C++ a struct can have function members (in O-O parlance, methods), but as you say, that's not how things are usually done.

 

[Filip Larsen]

A convention I have often met (and use myself) is to use structs for fully public data object, i.e. an object that simply acts as a container of sub-parts, especially for pure data exchange around component-interfaces.

Such data objects can of course still be defined as classes with getter and setters if one really likes, but in C++ a struct allows for a nice low ceremony way to define a data object . Or it can start as a struct and evolve into a class later if needed (i.e. to ensure certain invariants or even simple behavior) with low refactoring impact.

Using structs as a low ceremony data object also seems to get good support from some of the newer languge versions, like for example initializers from C++11 and designated initializers from C++20, so in that way is not considered "bad practice" even if some O-O purists may choose to frown upon their use.

 

[FactChecker]

A convention I have often met (and use myself) is to use structs for fully public data object, i.e. an object that simply acts as a container of sub-parts, especially for pure data exchange around component-interfaces.

Such data objects can of course still be defined as classes with getter and setters if one really likes, but in C++ a struct allows for a nice low ceremony way to define a data object . Or it can start as a struct and evolve into a class later if needed (i.e. to ensure certain invariants or even simple behavior) with low refactoring impact.

Using structs as a low ceremony data object also seems to get good support from some of the newer languge versions, like for example initializers from C++11 and designated initializers from C++20, so in that way is not considered "bad practice" even if some O-O purists may choose to frown upon their use.

I suppose that a struct that starts as simply an organized container of related data might naturally evolve to include methods to access and modify the data. That would allow it to use different methods to store the data without the user being knowledgeable of the details. So it makes sense that it would become very similar to a class. Although my initial reaction to this was negative, I am starting to like it more in an advanced computer language.

 

[Filip Larsen]

I suppose that a struct that starts as simply an organized container of related data might naturally evolve to include methods to access and modify the data.

That often how most of my internal data objects start, but if it ends up needing semantics you could argue that is just lack of good planning to start with fields, and to some degree this is correct. If you know in advance that a (data) structure needs non-trivial semantics (i.e. more than simple independent getters and setters) it is usually better start it of as a proper OO class to allow for less refactoring work.

My main use for structs (with public data fields only), however, is mostly for use on interfaces between components and sub-systems, allowing for better isolation of different contexts. Wikipedia describes this as Passive Data Structure which in C++ translates to Plain Old C++ Object (POCO).

In addition, in paradigms like Domain-Driven Design there is also some consensus that pure data objects is a good abstraction mechanism allowing e.g. entities to be isolated from different framework-specific mechanisms that really has no business-relevant meaning.

 

[jtbell]

As far as C++ is concerned ( you posted this thread with the C/C++/C# tag) there is essentially very little difference between a struct and a class. The only difference is that for a struct, the default access for members is public, while for classes, the default access is private.

When I learned and taught C++ (about 1995-2005), the introductory textbooks that I saw always used structs only as in C, namely with only public members, and with only member data (no member functions). Classes could have private members and member functions.

I remember being rather amused to learn (maybe around 2000-2002) that struct and class are actually interchangeable, if you always explicitly specify either public or private for member data and functions.

I don't know how recently-written introductory C++ textbooks handle this. Are there any? It seems to me that C++ fell out of favor for introductory programming courses around 2005-10.

 

[Warp]

When I learned and taught C++ (about 1995-2005), the introductory textbooks that I saw always used structs only as in C, namely with only public members, and with only member data (no member functions). Classes could have private members and member functions.

I remember being rather amused to learn (maybe around 2000-2002) that struct and class are actually interchangeable, if you always explicitly specify either public or private for member data and functions.

On a related note, the standard does define the concept of a POD ("Plain Old Data") type, which probably matches the closest to what you originally learned.

A POD type is either a scalar type or a struct/class (or union) that's an aggregate type with only POD types as members, no reference members, and no user-defined copy constructor nor destructor. (Although C++11 redefined a POD struct/class to be a trivial type, standard layout type, with all non-static members being POD. This permits a POD type to be singly-inherited from another POD type.)

The idea with defining a POD type is that it's compatible with any C library that uses structs. Which means that POD types are the closest thing in C++ that can be called "a C struct". (Although note that POD types are allowed to have constructors and non-virtual member functions. This is because they still remain compatible with C libraries.)

 

[FactChecker]

One important use of struct that I encountered was the need to map out memory so that several programs in different programming languages could access the data. I don't know if that is possible with a struct in C++ that includes methods, constructors, and destructors. I vaguely remember having a problem with C++ structs due to that. It was a long time ago and I can't remember the details or what the solution was.

 

[Warp]

One important use of struct that I encountered was the need to map out memory so that several programs in different programming languages could access the data. I don't know if that is possible with a struct in C++ that includes methods, constructors, and destructors. I vaguely remember having a problem with C++ structs due to that. It was a long time ago and I can't remember the details or what the solution was.

As mentioned, if the struct (or class) is of a "POD type", then it's fully compatible with C (and any other language that may use the same construct).

A POD struct can have member functions as long as they aren't virtual. The only types of member functions that aren't allowed are (as mentioned) virtual functions, as well as a copy constructor and a destructor. This is because they change how the struct/class behaves in a way that's not compatible with C. Normal (non-virtual) member functions do not affect the layout or behavior of a struct, so they are allowed for a POD type.

 

[FactChecker]

As mentioned, if the struct (or class) is of a "POD type", then it's fully compatible with C (and any other language that may use the same construct).

A POD struct can have member functions as long as they aren't virtual. The only types of member functions that aren't allowed are (as mentioned) virtual functions, as well as a copy constructor and a destructor. This is because they change how the struct/class behaves in a way that's not compatible with C. Normal (non-virtual) member functions do not affect the layout or behavior of a struct, so they are allowed for a POD type.

I didn't say that the language forbids member functions. It complicates the layout of the data for making messages or memory maps. My memory on the subject is very vague and I can not give more detail.

 

[Warp]

I didn't say that the language forbids member functions. It complicates the layout of the data for making messages or memory maps. My memory on the subject is very vague and I can not give more detail.

I mean that (non-virtual) struct member functions do not affect the layout, the bit representation, of the struct, and thus such structs can be used to interface with C libraries (and any other languages that handle such constructs).

 

[Silly Questions]

I'm with those who say, "If it does only data-like things use Struct. If it does class-like things use Class."

Others have dropped the acronym "POD" which I quite like. For POD use Struct. If you need to overload "<" with a KeyOfTheDay.Com web service call use Class. In between those two extremes use your best judgment.

In the memory-map case Struct is your way of saying, "Hands off this data type," (if the phrase "Memory Map" wasn't a big enough clue.)

Ultimately what you want is readable code. Will using "Struct" in a given situation make your code more readable? "Ahh, Struct, I know what to expect when I see Struct. There'll be no Class-like surprises here!" That's what you want. Use Struct and Class consistently to achieve it.

The counterargument is that "C" in its entirety is deprecated in C++. Always use Class. You might imagine I would argue against this, but if you're surrounded by purists and readable code is the goal what should you use? Class. The purists do have a point I acknowledge. I've never actually met a C++ purist in person, let alone an entire shop of them, but they make good arguments in online lectures.

 

[Svein]

I can give you a concrete example. Several network services (SNTP, IEEE1588, SNMP ...) have a strict data format which maps naturally to a struct. It is possible to add methods to the struct and call the result a class, but since the internal state machines and processes of a protocol handler are never available outside the handler itself, there is no reason to do that.