Quote:
[Originally Posted by disavowed;81568]Yes, that second sentence makes it much more than just a userdefined type  |
He says it more succinctly here:
"C++ language provides you with some built-in types, such as char, int, and double. A type is called built-in if the compiler knows how to represent objects of the type and which operations can be done on it (such as + and -) without being told by declarations supplied by a programmer in source code.
Types that are not built-in are called user-defined types(UDTs). They can be standard library types - available to all C++ programmers as part of every ISO Standard C++ implementation - such as string, vector, and ostream...., or types that we build for ourselves, such as Token and Token_stream
Why do we build types? The compiler does not know all the types we might like to use in our programs. It couldn't, because there are far too many useful types - no language designer or compiler implementer could know them all. We invent new ones every day. Why? What are types good for? Types are good for directly representing ideas in code. When we write code, the ideal is to represent our ideas directly in our code so that we, our colleagues, and the compiler can understand what we wrote. When we want to do integer arithmetic, int is a great help; when we want to manipulate text, string is a great help; when we want to manipulate calculator input, Token and Token stream are a great help.....
We want to represent such an "idea" or "concept" in code as a data structure plus a set of functions. The question is: "Exactly how?"..... C++ provides two kinds of user-defined types: classes and enumerations. The class is by far the most general and important, so we first focus on classes. A class directly represents a concept in a program. A class is a (user-defined) type that specifies how objects of its type are represented, how those objects can be created, how they are used, and how they can be destroyed. If you think of something as a separate entity, it is likely that you should define a class to represent that "thing" in your program. Examples are vector, matrix, input stream, string, FFT (fast Fourier transform), valve controller, robot arm, device driver, picture on screen, dialog box, graph, window, temperature reading, and clock".
Quote:
[Originally Posted by disavowed;81568]Actually, he doesn't say that 
He says, "C++ retains C’s ability to deal efficiently with the fundamental objects of the hardware (bits, bytes, words, addresses, etc.)." That's C++ the langauge he's talking about; he's not talking about what objects are made of. |
I hear you and I did state that the focus of an object was broader than just bits and bytes. When you come down to it, though, objects are just collections of code statements. You would never know that when you read many books on C++. They make everything unnecessarily complex.
I don't know how old you are, but when I was studying a limited amount of programming years ago, things were much more clear than they are today. For some reason, it was decided to obfuscate programming, no doubt by geeks, for geeks.
Mathematicians are just as bad. If a simple explanation will suffice for undergraduates, they will insist on presenting bafflegab that would only appeal to the most dedicated of mathematicians. For an undergraduate, three dimension visualization in calculus is adequate for most purposes but math is taught as if putting the notion in the undergraduate's mind that 3-D representations will lead to the dummy thinking that's all there is. So, they present all-encompassing descriptions of basic calculus that confuse more than clarify.
Quote:
[Originally Posted by disavowed;81568]And the reason is that objects don't have to be made of bits and bytes.. it's up to the compiler to decide how to implement them. One could create a compiler that stores object data in string format in a SQL database. That's why abstractions exist, because often times there are many ways to do the same thing. |
Ultimately they do. A processor only understands bits and bytes in the form of electrical impulses. That's the reality. I think that people programming in high level languages, especially those teaching it, should bear that in mind. Stroustrup seems to be keenly aware of that when he teaches C++ and that's why I enjoy reading him so much. He doesn't hide behind abstraction, he explains it in simple terms.
I understand the reason for abstracting programs but it seems to go too far at times. It has gone so far that most authors I have read on C++ can't explain simple concepts. Richard Feynman lamented that in university. He would not give a physics lecture unless he could explain a concept in words. Most profs would be lost doing that.
In RE, it helps to stop and ask yourself what the code is trying to do. In fact, that sometimes applies in general to life. What the heck am I trying to accomplish? Many times the answer to that lies deep in emotions and we do things driven by a feeling rather than as something we enjoy doing. In programming, I think it's very important for the beginner to understand what is being accomplished rather than filling his head with abstracted concepts.
You see the effect of that in university. People come out of there not really understanding what they have learned. When I was studying, one guy went two years before he realised that the L in (L di/dt) was a physical device...an inductor. I worked for a graduate engineer who could not draw transistors in a drawing correctly.
Quote:
[Originally Posted by disavowed;81568]I don't understand your reasoning here. User can define structures. Furthermore, users can clearly define classes. |
I am in no way trying to present myself as an expert. You know far more about it than I do. However, you can type in STRUCT in a C++ program and the compiler will know what you mean. Is that true for CLASS?