Thread: C++ question

Eibro, is this a function?

int p();

It is a function in C++, but not according to your definition of a function because it doesn't take any arguments.

The definition says "number of arguments." In this case the number is 0. The definition is fine, just misleading. It still qualifies functions without arguments as functions.

Originally posted by Eibro
Destructors don't specify a return type; if they were a function you'd be getting a big fat error.

We already went over this -- it says "might" and we already showed that Stroustrup calls constructors functions and they have no return type. Are you saying that Stroustrup is wrong, or were you not paying attention for the last 15 posts?

Well here are the answers. The question may be worded differently, but they are questions found in testbanks from previous C++ text we have used.

1. B
2. C
3. C
4. B

The Virtual question was taken from Deitel and Deitel third ed. It says this in Ch 10.

Originally posted by Eibro
What are you talking about? Seriously.
Destructors don't classify as functions because they cannot take arguments.

Really sad that you'd make a conclussion like that. Simply because the function takes no arguments and can't be overloaded doesn't mean anything. If there was a function which had parameters but couldn't be overloaded, would that be any different? No. The fact that the forced version of the destructor takes no arguments means nothing at all. Be logical.

And if you really wanted to get down and dirty, the destructor does have an implicit argument -- it needs a pointer to an instance of the datatype it destructs. All member functions need a this pointer, a destructor isn't any different.

Originally posted by Eibro
As for Poly, i've proven my point. Destructors aren't functions, so C is correct answer.

Even if in some wild stretch of the imagination you consider destructors not functions, you are completely ignorant to the fact that ALL OTHER PURE VIRTUAL FUNCTIONS CAN HAVE DEFINITIONS. I merely used pure virtual destructors as an example because they have to have definitions in order to get any use out of the class other than just static functions, etc. and because they are the most common place that you'd find pure virtual functions with definitions.

If you had enough intelligence to actually read some of the posts other than your rediculous ranting you'd see that someone already gave a definition of a pure virtual function which mentioned that they can have definitions, confirming my point.

Answer C is wrong. Grow a dick.

Originally posted by Eibro
Yes it does. It means it's not a function.

Again, I disagree, but I do agree that we are getting nowhere. This is just silly now. Whether or not someone refers to it as a function is rather trivial. We all know what they do and their similarities to regular member functions, lets just leave it at that.

EDIT: Also, I'm in Connecticut now, back from college, so I might not be as far.

From Text:

A pure virtual function is a virtual function that has no definition within the base class.....

When a virtual function is made pure, and derived class must provide its own definition.

That's not a proper definition.

A pure virtual function is a virtual function that has no definition within the base class.....

When a virtual function is made pure, and derived class must provide its own definition.

Hooray.

Also, beware of quoting Stroustrup. Taken from one of the early chapter is his 3rd edition -

In addition, it is guaranteed that a char has at least 8 bits, a short at least 16 bits, and a long at least 32 bits

Taken from the C++ standard -

2 There are four signed integer types: “signed char”, “short int”, “int”, and “long int.” In this
list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natural
size suggested by the architecture of the execution environment39) ; the other signed integer types are
provided to meet special needs.

edit -

Sorry it should have concluded -

3 For each of the signed integer types, there exists a corresponding (but different) unsigned integer type:
“unsigned char”, “unsigned short int”, “unsigned int”, and “unsigned long
int,” each of which occupies the same amount of storage and has the same alignment requirements (3.9)
as the corresponding signed integer type40) ; that is, each signed integer type has the same object representation
as its corresponding unsigned integer type. The range of nonnegative values of a signed integer type
is a subrange of the corresponding unsigned integer type, and the value representation of each corresponding
signed/unsigned type shall be the same.

3.9 - that is, large enough to contain any value in the range of INT_MIN and INT_MAX, as defined in the header <climits>.

and I'll repeat again

A pure virtual funtion can have a definition. The text definition that Mister C provided was not proper. Making a member function pure virtual forces the class to become abstract and therefore you can't instantiate it, however the pure virtual function can still have a definition.

You're quibbling about semantics. The source of the "text definition" quoted by Mister C is the same that you and Eibro having been throwing back and forth.

Your point is that a destructor may be considered as a function insomuch that it may invalidate the answer. This may be true if you're following your definition (or somebody elses' loose definition). Mister C has also chirped in with a definition from a different angle. Unless you can provide a strict definition of the terms used from a standard then I'd guess for all intents and purposes answer C is correct.

The question as to whether or not a destructor is a function has nothing to do with if C is correct. I just used it as an example of a function where a pure virtual function has a definition. Since there is such a problem with people calling a destructor a function, (which we have already put to rest, we decided not to argue about it in this thread any more as it's getting far off topic), any other member function can be looked at in the same way. All member functions that are pure virtual can have a definition, plain and simple. There's no problems with simantics there.