The *only* two differences between C++ structs and classes are 1) the default access modifer for members (data and methods), which is private for classes and public for structs and 2) the default inheritence behavior which is private for classes, but public for structs.

Structures do not support methods neither inheritance nor polymorphism.

I found a c++ reference that says that structures can contain methods!?! It is news to me. There is a difference about how things are stored in memory. When you create a structure element it is a fixed block in memory. When you create a class you get one of these managed memory elements that can move around on you. The compliler is supposed to take care of that but I've got a program which may have another problem somewhere but it seems to run if I use an array of structures instead of an array of classes. The program runs, it just doesn't seem to really do anything with the elements inside of the class. When I simply change the class to a structure, it appears to run. My guess is that I have fallen through a compiler hole. But structures may be simpler for the compiler to deal with. The reference suggests that you can use either approach. You figure?? HJ

The *only* two differences between C++ structs and classes are 1) the default access modifer for members (data and methods), which is private for classes and public for structs and 2) the default inheritence behavior which is private for classes, but public for structs.

Structs existed before C++ being an integral part of the C language. As such, from the point of view of bullet-proof code, they may actually work better than methods because there has been longer to get the bugs out. On the other hand, reverting to using structs unless you need to, breaks the Object Oriented nature of the code writing, which confuses people who have to maintain it later. If you choose to use structs rather than methods for a particular object, best if you make sure you comment fully on why you are doing so.

In C# struct is value type and class is reference type.

For example:

User user = new User();

user.Name = "A";

User user2 = user;

user2.Name = "B";

If User is structure then user.Name is "A", but if User is class then user.Name is "B".

@Javier: Yes, I'm also wondering what's going on here...

struct has by default public specifier while class has private.

if one define 'struct' and create object using 'class' keyword. Default specifier for the objects are public..

Both can have methods

No question, but don't forget that C++ and C# have a history, and part of that history is that structs predated them. It used to be quite useful to have a "Jump Table" or "Patch Table" as a structure to work around. These days we have all the tables, and lists in our libraries to work from, but C didn't used to come with anything but the STD library which was quite limiting. the .H file was almost critical to making C practical, and the .H file was where the Tables were designated.

Also, remember that Object Oriented Programming is all about "HIDING" data so that you reduce the side effects. In the bad old days, of C, everything was public, so changeable code, where one piece of code was changing another, was frowned on, if only because it created "Spagetti Code" that was impossible to maintain. Again I caution you, don't break the model, use Classes wherever possible and document the Structs well, because someone else is going to have to maintain your code, and is just as likely to throw the offending code out, if they don't know why it was critical.

@Graeme * I want to clarify one point. First you are correct that the fact that C had a single global area for data storage was a very serious limitation. It was fine for small applications but you had to figure out how to manage the data if you wanted to produce a large application. However, this problem can be overcome. The global storage limitation did not, in of itself, cause "spagetti code." I will grant you that it could be a contributor but it isn't a direct cause. The arrival of "C with classes" was a great improvement allowing you to package code and associated data together. C++ is the next step but it comes at the expense of complexity. The orginal C specification is about 50 pages in length. The C++ documentation comes in several very thick volumes in amazingly small print. I assure you, you can write un-maintainable code in C++, Java, Ada or any language you want. I know because I think I have done it on occasions.

Finally, I have never understood "hiding data." Who are you trying to hide the data from? The person responsible for maintaining the code? Is this really a productive way to do things? I'm just asking. HJ

Ok, I understand your confusion.

The concept Data Hiding, was developed as one of the rationales for OOPS. (As an old codger I remember the problems I had trying to convert from proceedures ala Pascal to OOPS). Luckily because I remember, I understand the nature of Data-hiding. In pre-oops languages, the main program was a complex melange of data and procedures or Subroutines depending on the language. In OOPS, your Main Method, should be relatively easy to understand, but will invoke other objects, and their methods. Because the Objects are separately packaged, you don't need to know the exact structure of the data element, you simply need to understand the interface the object presents to the world, and the meaning of the program becomes clear. It is only, if a part of the program fails, that you need to unpack that objects source code, and dig into the data structures for that object.

It is the clarity, when it comes to maintenance that makes OOPS shine. Given an object that you don't understand, but that has an interface that you do, you can replace the object with one that is more understandable simply by replacing the one objects source file. If you get the interface right, (Test driven development anyone?) you can slot it into the program without having to worry about the nature of the structures in the other data areas of the program.

What it actually means, is that you can limit the confusion, of a complex program, simply by compartmentalizing (hiding) data within the object interface.

@Graeme * Speaking as a fellow, old codger OOPS is nice when it works. I shouldn't say bad things about it since most of the software that is giving me problems is my own. Thank you for your response. HJ

OOPS done properly does require more programmer discipline, but tends to result in much cleaner programs with less side effects. To do it properly however, you probably need to understand both the Agile System, and Test Infected programming. Most of my problems happen when I lose programmer discipline and let my code go too far without a Unit Test. But in the Agile System, re-factoring should be done often, and I can often recover from monolythy by refactoring.

The main objection I have heard to it, is the inheritance overhead. Every time, you allow one object to inherit from another, you get more overhead. With extremely large programs, paging the overhead becomes more expensive.

The trick, as I understand it, is to keep your whole inheritance overhead within the size of your processor cache.

The idea of daily builds, with Unit Tests, and Agile Programming was built for just such an eventuality. You write a toy program that seems to do what is wanted, to keep the boss happy, (Like it simulates doing it, instead of actually doing the math) then you have something to show each time the management comes around. Since you are improving the project each time they look in, they get the feeling that something is happening other than the fact that you are sitting at desks watching porn all day.

Unit tests, lots of Unit tests, are also not only a great way to stabilize your code, but a way to baffle with bull, in that if the micro-manager doesn't know why he is watching all the test results, there is a chance you can explain them as QA stuff, and he will take it.

Not only that, but it gives them something to object to, which allows you to find out more about what they want, without begging them for information. Each time they actually look in, you get more feedback on the human interface, and they stay out of your hair mostly on the coding aspect other than that, because they can see that progress is happening.

There is no defense against micro-managing incompetence, except to put a layer of insulation between the production coding people and the micro-manager.

Well, part of that is standing up for the System you are using.

You said this would be an Agile Shop, so don't ask me to break the rules of Agile Systems, or something to that nature, may have to be repeated over and over again until the manager either cans you, or listens to you.

In the case where it looks like you will have to bail out, have an exit plan. Hopefully something better than "you can't fire me, I just quit!" Sometimes the manager is doing it to separate the talent from the program, the specifications are often designed to keep the programmer from knowing what he is programming. (The Mushroom Effect).

If it looks like you actually understand, you are out the door because you might actually have a claim against the programs code if it comes to litigation. One of the reasons that open source software has taken off, is that a lot of programmers that were frozen out of their jobs, have written open source stuff, and have had the pleasure of seeing big companies have to acknowledge their contribution in order to keep their code. Take a look at the README in MySQL and you can see a list of programmers that contributed before it became MySQL, it must really fry Oracle, that MySQL is more popular than Oracles own proprietary software.

there is information hidden capabilities in class but there is not in struct like Private, Public and Protected members

1)By default, all the members of the class are private but the members of the structure are public.

2)Structure doesn't support inheritance...

3)In a Structure we can't initialize the value to the

variable but in class variable we assign the values.

4)Structure are value type.They are stored as a

stack on memory . Whereas class are reference type. They

are stored as heap on memory.