The term "method" is often used to discuss C++ code. Does the standalone term have a well-defined meaning in C++ or is it ambiguous? Is it acceptable to use the term by itself, or should it be qualified (e.g. a "class method" or "virtual method"), or should it be simply avoided altogether?
The term method is not defined in the C++ standard. The terminology uses member function instead.
Bjarne Stroustrup however defines the term method in his own glossary as virtual member function. So this shows evidence that the term is acceptable.
I would avoid this term entirely, as it is clear what you mean by "member function", but not "method" - that you asked this question is proof enough.
However, normative appearances of the word "method" in the C++14 standard are
In the content list:
17.5 Method of description (Informative)
This is repeated in the title of that section.
[basic.compound]:
These methods of constructing types can be applied recursively;
[cpp.include]
The method by which a sequence
of preprocessing tokens between a < and a > preprocessing token pair or a pair of " characters is combined
into a single header name preprocessing token is implementation-defined.
[library.general]
The following subclauses describe the definitions (17.3), method of description (17.5), [..]
In table 32, FLT_EVAL_METHOD is mentioned.
In stage 2 of num_get's do_get:
For arithmetic types, punct.thousands_sep() characters are inserted
into the sequence as determined by the value returned by
punct.do_grouping() using the method described in 22.4.3.1.2
[forwardlist.modifiers]:
Otherwise, inserts sz - distance(begin(), end()) elements at the end of
the list such that each new element, e, is initialized by a method equivalent to calling allocator_traits<allocator_type>::construct(get_allocator(), std::addressof(e), c).
[filebuf.virtuals]:
Behaves according to the description of
basic_streambuf<charT,traits>::uflow(), with the specialization that a
sequence of characters is read from the input with the same method as
used by underflow.
The term is clearly never referring to a "member function".
The C++ standard makes no mention of the term method. It should be noted that the official C++ FAQ does make use of this term, but to describe a virtual function; a simple Google search reveals more occurrences of this term.
I've never seen the term method in an IDE (Visual Studio), but I've seen the term member function. In my opinion method is a 'one size fits all' term.
The term method had been historically used as a synonym of the procedure of an object. Considering, an object has both data and behaviour, it is this behaviour which was referred as method.
Tracing backward, I could find a reference to the usage of the term method when referring to an MIT ALGOL version, AED-0
Quoting wikipedia
MIT ALGOL version, AED-0, linked data structures ("plexes", in that
dialect) directly with procedures, prefiguring what were later termed
"messages", "methods", and "member functions".
Over the years method had been an integral part of Object Oriented Analysis and Design and Object-oriented programming. Now C++ evolved as a procedural language where it extended C a procedural language to have object oriented capabilities. C had the concept of structure, and the data elements were called members. Refer Methods in C++.
To not break the lineage, C++ continued to call the elements of structured and the newer genre class as members.
Now, to differentiate between data and functions, instead of introducing a new terminology, it extended this terminology to call data members and member functions. Member functions which supported dynamic binding were called virtual functions.
So, strictly speaking, official references refrains from using the terminology methods when referring to member functions. The terminology is most prevalent among the people who have a more Object Oriented background. So if you want to remain unambiguous, it is best to use the terminology as
data member
member function
virtual functions
Here my analysis regarding the word method.
I did a scan on official documentation (standards, specifications, etc.) on several programming languages.
http://componentsprogramming.com/using-the-right-terms-method/
Adequate taxonomy (not dependent on any programming languages) will be published in a future article.
Regarding to C++, the correct terminology is: member/non-member function.
Some people use member/free functions.
Related
I have been reading Design Patterns(GOF), and it presents a clear distinction between the class and the type of an object as specified below.
The TYPE of the object is defined by it's interface(set of methods that it can handle) and the CLASS of the object defines its implementation.
I have read in many books on C++ that a Class is user-defined Type. And nothing more has been mentioned about the concept TYPE (not even as GOF mentions it.)
I just want to know does C++ standard mentions anywhere the concept TYPE in any way if not the way that GOF mentions.
Or is it assumed that this difference is too basic to mention?
C++ defines several kinds of types. Class types are just one such kind of type; others are integral types, floating-point types, pointer types, array types, function types, and so forth. The concept of "type" is well defined in C++.
The C++ standard discusses types in section 3.9 [basic.types] (in the 2011 ISO C++ standard; the section number may be different in other editions).
The Design Patterns book is is not language-specific, and it's using the words "type" and "class" in a different way than the way the C++ standard uses them.
I have been told for my PhD that I have to learn fortran 2003 language. I have never used and OOP program before nor fortran. I am trying to understand what the difference between type and class is. I know that classes are declared with the 'TYPE' keyword but I have also seen examples of the keyword 'CLASS' being used used so I am getting confused. Hope that makes sense.
The keyword type is used to declare derived types -- best not to get into the habit of thinking, perhaps imported from foreign languages, that type is used for declaring something called classes.
The keyword class is used, in restricted circumstances, to mean of the type specified or any of its extended types. extended type is Fortran-speak for a type which extends another type, essentially one which specialises or inherits from another type. The restricted circumstances within which class is used are in procedure dummy-argument lists and in declarations of entities with the attribute allocatable or the attribute pointer. A class entity gets a dynamic type at run-time, and its dynamic type may vary from run to run, or across a single execution of the program.
If you don't understand the explanation in the previous paragraphs it's possibly because I've explained things poorly, but it's also possibly because you don't yet have enough of a grounding in the basics of Fortran. To acquire the grounding find yourself an up-to-date online tutorial, an online reference guide, and start programming.
In both of his books
The C++ Programming Language, 2013 (4th edition) and
A Tour of C++, 2013
Bjarne Stroustrup writes:
Types such as complex ... are called concrete types because
their representation is part of their definition.
What follows to some extent clarifies the above statement:
In that, they resemble built-in types. In contrast, an abstract type
is a type that completely insulates a user from implementation
details. To do that, we decouple the interface from the
representation and give up genuine local variables. Since we don’t
know anything about the representation of an abstract type (not even
its size), we must allocate objects on the free store and access them
through references or pointers.
Questions
In the phrase "...their representation is part of their definition."
What is the meaning of type representation? That is, the representation of what exactly: The object layout in memory? The private and public data that the type holds? Or something else?
What is the meaning of type definition?
Are these typical meanings of type representation and definition as related to C++?
I decided to do some more research and I checked other sources. First I looked through ISO/IEC 14882:2011 specifications that state requirements for implementations of the C++ programming language, then through other sources.
Ad question 1
I was not able to find in ISO specs anything like "type representation" or "representation of a type". Instead there are 2 terms related to objects:
The object representation of an object of type T is the sequence of N unsigned char objects taken up by the object of type T, where N equals sizeof(T).
The value representation of an object is the set of bits that hold the value of type T. For trivially copyable types, the value representation is a set of bits in the object representation that determines a value, which is one discrete element of an implementation-defined set of values.
So it seems to me that the term type representation does not have any conventional meaning within the ISO standards.
Ok. Maybe it is something outside the ISO standards? Let's see what
Linux Standard Base C++ Specification 3.1 > Chapter 7. C++ Class Representations > 7.1. C++ Data Representation says:
An object file generated by the compilation process for a C++ program shall contain several closely related internal objects, or Class Components, to represent each C++ Class. Such objects are not a visible part of the source code. The following table describes these Class Components at a high level.
Table Class Components
Object.......................Contains
=----------------------------------------=
Class Data...................Class members
Virtual Table................Information needed to dispatch virtual functions,
access virtual base class subobjects and to access
the RTTI information
RTTI.........................Run-Time Type Information used by the typeid and
dynamic_cast operators, and exception handlers
Typeinfo Name................String representation of Class name
Construction Virtual Table...Information needed during construction and
destruction of Classes with non-trivial
inheritance relationships.
VTT..........................A table of virtual table pointers which holds the
addresses of construction and non-construction
virtual tables.
Ad question 2
I was again not able to find in ISO specs an explicit explanation of type definition.
Instead I found the following:
A declaration may introduce one or more names into a translation
unit... A class declaration introduces the class name into the
scope where it is declared...A declaration is a definition unless
[I removed things not directly related to the class declaration], ...
it is a class name declaration...
Here is a Microsoft interpretation of the same thing:
C++ Declarations - MSDN - Microsoft
A declaration introduces
one or more names into a program. Declarations can occur more than
once in a program...Declarations also serve as definitions, except
when the declaration:...;Is a class name declaration with no
following definition, such as class T;...
and
C++ Definitions - MSDN - Microsoft
A definition is a unique
specification of an object or variable, function, class, or
enumerator. Because definitions must be unique, a program can contain
only one definition for a given program element. There can be a
many-to-one correspondence between declarations and definitions.
There are two cases in which a program element can be declared and not defined: A function is declared but never referenced with a
function call or with an expression that takes the function's address.
A class is used only in a way that does not require its definition be
known.
Examples:
struct S; // declares, but not defines S
class T {}; // declares, and defines T
class P { int a;}; // declares, and defines P, P::a
Conclusions:
Candidate Answer N1:
proposed by Jonathan Wakely
(below is my understanding)
The phrase "Types such as complex ... are called concrete types because their representation is part of their definition" should be interpreted and understood in the following way:
● their(=type) definition is a technical c++ term whose meaning is conventional and can be found in c++ specs;
● their(=type) representation is (according to Jonathan Wakely) not a technical c++ term in this context, but its meaning can be easily figured out by anybody who understands English language well enough (and probably, it is my guess, has been previously exposed to the generous amount of c++ codes and texts). Type representation in this context means
"the properties that define what the type is and what it does", that is:
"for a concrete type: the type and layout of its members",
"for an abstract type: its member functions and their observable behavior"
● The whole phrase then (we are talking about the concrete classes) translates to:
"Types such as complex ... are called concrete types because the types and layouts of their members are part of their definition"
I think this interpretation makes sense, is understandable, and also agrees well with what follows it in the BS books.
Please correct me if something here is not ok**
QUESTIONS: in the phrase "...their representation is part of their definition." 1) What is the meaning of type representation? (that is, the representation of WHAT exactly: object layout in memory or private and public data that the type holds OR something else) 2) What is the meaning of type definition? 3) Are these typical meanings of type representation and definition as related to c++?
You're asking for the meaning of terms that Stroustrup doesn't use in the text you quoted!
He's not trying to define a formal specification of a term like "type representation" the way the C++ standard does, he's writing prose that is more informal. All the references to technical terms that you've dug up are misleading and not directly relevant.
(that is, the representation of WHAT exactly: object layout in memory or private and public data that the type holds OR something else)
Yes, both the things you mention. For a concrete type the properties that define what it is and what it does include the type and layout of its members. i.e. how it is represented in the source code.
For an abstract class, the properties that define what it is and what it does are its member functions and their observable behaviour. The details of how it produces that observable behaviour are not necessarily important, and sometimes aren't even visible in the source code because you actually use some concrete class defined in another piece of code and only use it through an abstract interface.
Edit: Judging from the comments you wrote below you apparently missed that I tried to give you an answer. What I wrote above refers to the properties that define what a type is and what it does. That is a "definition of a type".
If you had to write documentation for a C++ type for users, how would you define it?
For a concrete type you might describe the types of its members and so define some of its properties in terms of the properties of its members. e.g. "A std::complex<float> stores two float members, which represent the real and imaginary parts of the complex number." This tells you that std::complex<float> can only store complex numbers with the same precision as float, i.e. its precision is determined by the fact it is represented using two float members.
For an abstract class you would describe the behaviour of its member functions, which are likely to be virtual, so you describe it in terms of the interface it follows, not in terms of the details of its implementation.
But they are not formal terms, I think you are wrong to treat them as strict technical terms. He's just using the words with their usual English meaning.
You go looking out for a vegetable in dinner tonight. Wait.. a vegetable? The word vegetable defines something for sure but it carries no representation. Someone will surely ask you which vegetable. So a vegetable is an abstract concept.
So now you order some potatoes and onions. Well, they define some properties and represent themselves well enough so that you can locate them in the store. Potatoes and onions make up for concrete representation of a type with a well defined property and behavior.
Try writing two classes following this analogy. You may connect to what is meant by representation is part of their definition.
I stumbled over the same passage in the text, and it took me a while, but I believe I deduced from the text what is meant by representation and definition of a class.
Answer to question 1: The representation of a type are the data members. Those are the members of the type which store the information/state, as opposed to the methods/operations on them.
Answer to question 2: The definition is simply the code implementing the class. (like the definition of Vector below).
Rationale: See section 2.3.2 of the same book and pay close attention on the use of the word 'representation':
Having the data specified separately from the operations on it has advantages, such as the ability to use the data in arbitrary ways. However, a tighter connection between the representation and the operations is needed for a user-defined type to have all the properties expected of a "real type."
It seems that "representation" here now replaced "data".
Here, the representation of a Vector (the members elem and sz) [...]
elem and sz are precisely the data members of the Vector class defined in that section:
class Vector {
public:
Vector(int s) :elem{new double[s]}, sz{s} {} // construct a Vector
double& operator[](int i) { return elem[i]; } // element access: subscripting
int size() { return sz; }
private:
double* elem; // pointer to the elements
int sz; // the number of elements
};
Further Explanation:
For a concrete type, it is possible from the definition to tell how much memory must be allocated for the data members of an object of this type. When you declare a variable to be of that type somewhere in the source code of your program, the compiler will know its size in memory.
In the case of the class Vector defined above, the memory required for the data members of an instance of that class would be whatever memory is needed for an integer sz and a pointer to a double elem.
An abstract type on the other hand, may not specify data members in its definition, so that the memory required for an object of such a type would be unknown.
For more on abstract types see section 3.2.2 of the same book and note that the abstract class Container defined in that section has no data members (further supporting my answer to question 1).
With this understanding in mind, some of the exposition that follows the sentence in question where the words definition and representation are used makes sense.
I'll paraphrase:
since the representation is part of the definition of a concrete type, we can place an object of such a type on the stack, in statically allocated memory, and in other objects and we can refer to such objects directly and without the use of pointers or references, etc..
If we didn't know the size of the data members of an object, we wouldn't be able to do these things.
In response to question 3:
I do not know the answer to question number 3, but believe that as stated in previous answers, the terminology used here is informal and shouldn't be viewed as some sort of standard. This goes with the spirit of the part of the book this is written in which is only giving a brief high-level informal overview over C++ not assuming previous knowledge and thus avoiding jargon.
Can someone please disambiguate class attributes and methods for C++? I was under the impression that attribute means any member variable, and method means any member function.
Thanks
Define "correct".
Referring to data members and member functions as "attributes/properties" and "methods", respectively, is common practice - it's the general OO wording. ("attributes" are used in C++ for something else, though, so this may very well be a source of confusion.)
The C++ standard, however, does not use these terms (apart from attributes of course, as explained above). If you don't want to risk anything and always be correct, use "data members" and "member functions".
But if you only want to explain C++ to a Java programmer, you may get away with "property" and "method" in the beginning.
I would not do that. While it can be understood in the general context of OO, it will be confusing in C++ as attribute has a precise definition in the standard, that is not that of data member.
A class' attributes would translate to its members. A method is not the same as a member function in general. But "In object-oriented programming, a method is a subroutine (or procedure) associated with a class." - Wikipedia.
In common words, an attribute describes something, "One of the attributes of this car is that it's quite long", or "one of the attributes of the giant panda is it's striking black and white colours".
I XML, attributes are used to add extra information in a tag, e.g <species id=3212>Ailuropoda melanoleuca<common_name>Giant Panda</common_name></species> - id is an attribute, Ailuropoda melanoleuca is a value, common_name a tag within species.
But I call the variables in a class "member variables", and functions in a class "member function" or "method".
I have read that C++ is super-set of C and provide a real-time implementation by creating objects. Also C++ is closed to real world as it is enriched with Object Oriented concepts.
What all concepts are there in C++ that can not be implemented in C?
Some say that we can not over write methods in C then how can we have different flavors of printf()?
For example printf("sachin"); will print sachin and printf("%d, %s",count ,name); will print 1,sachin assuming count is an integer whose value is 1 and name is a character array initililsed with "sachin".
Some say data abstraction is achieved in C++, so what about structures?
Some responders here argues that most things that can be produced with C++ code can also be produced with C with enough ambition. This is true in some parts, but some things are inherently impossible to achieve unless you modify the C compiler to deviate from the standard.
Fakeable:
Inheritance (pointer to parent-struct in the child-struct)
Polymorphism (Faking vtable by using a group of function pointers)
Data encapsulation (opaque sub structures with an implementation not exposed in public interface)
Impossible:
Templates (which might as well be called preprocessor step 2)
Function/method overloading by arguments (some try to emulate this with ellipses, but never really comes close)
RAII (Constructors and destructors are automatically invoked in C++, so your stack resources are safely handled within their scope)
Complex cast operators (in C you can cast almost anything)
Exceptions
Worth checking out:
GLib (a C library) has a rather elaborate OO emulation
I posted a question once about what people miss the most when using C instead of C++.
Clarification on RAII:
This concept is usually misinterpreted when it comes to its most important aspect - implicit resource management, i.e. the concept of guaranteeing (usually on language level) that resources are handled properly. Some believes that achieving RAII can be done by leaving this responsibility to the programmer (e.g. explicit destructor calls at goto labels), which unfortunately doesn't come close to providing the safety principles of RAII as a design concept.
A quote from a wikipedia article which clarifies this aspect of RAII:
"Resources therefore need to be tied to the lifespan of suitable objects. They are acquired during initialization, when there is no chance of them being used before they are available, and released with the destruction of the same objects, which is guaranteed to take place even in case of errors."
How about RAII and templates.
It is less about what features can't be implemented, and more about what features are directly supported in the language, and therefore allow clear and succinct expression of the design.
Sure you can implement, simulate, fake, or emulate most C++ features in C, but the resulting code will likely be less readable, or maintainable. Language support for OOP features allows code based on an Object Oriented Design to be expressed far more easily than the same design in a non-OOP language. If C were your language of choice, then often OOD may not be the best design methodology to use - or at least extensive use of advanced OOD idioms may not be advisable.
Of course if you have no design, then you are likely to end up with a mess in any language! ;)
Well, if you aren't going to implement a C++ compiler using C, there are thousands of things you can do with C++, but not with C. To name just a few:
C++ has classes. Classes have constructors and destructors which call code automatically when the object is initialized or descrtucted (going out of scope or with delete keyword).
Classes define an hierarchy. You can extend a class. (Inheritance)
C++ supports polymorphism. This means that you can define virtual methods. The compiler will choose which method to call based on the type of the object.
C++ supports Run Time Information.
You can use exceptions with C++.
Although you can emulate most of the above in C, you need to rely on conventions and do the work manually, whereas the C++ compiler does the job for you.
There is only one printf() in the C standard library. Other varieties are implemented by changing the name, for instance sprintf(), fprintf() and so on.
Structures can't hide implementation, there is no private data in C. Of course you can hide data by not showing what e.g. pointers point to, as is done for FILE * by the standard library. So there is data abstraction, but not as a direct feature of the struct construct.
Also, you can't overload operators in C, so a + b always means that some kind of addition is taking place. In C++, depending on the type of the objects involved, anything could happen.
Note that this implies (subtly) that + in C actually is overridden; int + int is not the same code as float + int for instance. But you can't do that kind of override yourself, it's something for the compiler only.
You can implement C++ fully in C... The original C++ compiler from AT+T was infact a preprocessor called CFront which just translated C++ code into C and compiled that.
This approach is still used today by comeau computing who produce one of the most C++ standards compliant compilers there is, eg. It supports all of C++ features.
namespace
All the rest is "easily" faked :)
printf is using a variable length arguments list, not an overloaded version of the function
C structures do not have constructors and are unable to inherit from other structures they are simply a convenient way to address grouped variables
C is not an OO langaueage and has none of the features of an OO language
having said that your are able to imitate C++ functionality with C code but, with C++ the compiler will do all the work for you in compile time
What all concepts are there in C++
that can not be implemented in C?
This is somewhat of an odd question, because really any concept that can be expressed in C++ can be expressed in C. Even functionality similar to C++ templates can be implemented in C using various horrifying macro tricks and other crimes against humanity.
The real difference comes down to 2 things: what the compiler will agree to enforce, and what syntactic conveniences the language offers.
Regarding compiler enforcement, in C++ the compiler will not allow you to directly access private data members from outside of a class or friends of the class. In C, the compiler won't enforce this; you'll have to rely on API documentation to separate "private" data from "publicly accessible" data.
And regarding syntactic convenience, C++ offers all sorts of conveniences not found in C, such as operator overloading, references, automated object initialization and destruction (in the form of constructors/destructors), exceptions and automated stack-unwinding, built-in support for polymorphism, etc.
So basically, any concept expressed in C++ can be expressed in C; it's simply a matter of how far the compiler will go to help you express a certain concept and how much syntactic convenience the compiler offers. Since C++ is a newer language, it comes with a lot more bells and whistles than you would find in C, thus making the expression of certain concepts easier.
One feature that isn't really OOP-related is default arguments, which can be a real keystroke-saver when used correctly.
Function overloading
I suppose there are so many things namespaces, templates that could not be implemented in C.
There shouldn't be too much such things, because early C++ compilers did produce C source code from C++ source code. Basically you can do everything in Assembler - but don't WANT to do this.
Quoting Joel, I'd say a powerful "feature" of C++ is operator overloading. That for me means having a language that will drive you insane unless you maintain your own code. For example,
i = j * 5;
… in C you know, at least, that j is
being multiplied by five and the
results stored in i.
But if you see that same snippet of
code in C++, you don’t know anything.
Nothing. The only way to know what’s
really happening in C++ is to find out
what types i and j are, something
which might be declared somewhere
altogether else. That’s because j
might be of a type that has operator*
overloaded and it does something
terribly witty when you try to
multiply it. And i might be of a type
that has operator= overloaded, and the
types might not be compatible so an
automatic type coercion function might
end up being called. And the only way
to find out is not only to check the
type of the variables, but to find the
code that implements that type, and
God help you if there’s inheritance
somewhere, because now you have to
traipse all the way up the class
hierarchy all by yourself trying to
find where that code really is, and if
there’s polymorphism somewhere, you’re
really in trouble because it’s not
enough to know what type i and j are
declared, you have to know what type
they are right now, which might
involve inspecting an arbitrary amount
of code and you can never really be
sure if you’ve looked everywhere
thanks to the halting problem (phew!).
When you see i=j*5 in C++ you are
really on your own, bubby, and that,
in my mind, reduces the ability to
detect possible problems just by
looking at code.
But again, this is a feature. (I know I will be modded down, but at the time of writing only a handful of posts talked about downsides of operator overloading)