function is not an object

[asdf]

True or false ?

 

[Phlip]

True or false ?

Objects have state, identity, lifespan, storage, and behavior. Which of
those do functions have? Can you point to a function?

 

[asdf]

So function is not an object.

But I think I can point to a function, by the pointer to the function.

 

[pauldepstein]

True or false ?

This question seems to be about how the c++ community defines the
"object" concept.

I would say "false". Here's why.

The * symbol is used for dereferencing or defining a pointer to an
object.

However, the * symbol is also used to define a pointer to a function.

So, if a function is not an object, what is the type-of-thing that a
pointer to a function points to?

I would say that a pointer-to-a-function is an example of a
pointer-to-an-object, and hence a function is an object.

Paul Epstein

 

[Kai-Uwe Bux]

True or false ?

From the standard [1.8/1]

The constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An object is a region of storage. [Note: A function is
not an object, regardless of whether or not it occupies storage in the way
that objects do.]


Best

Kai-Uwe Bux

 

[Daniel T.]

True or false ?

From the book C++ FAQs 2nd ed.

FAQ 5.06: What is an object? It depends on who you are. To a
programmer, an object is a region of storage with associated
semantics. To a designer, an object is any identifiable component in
the problem domain.

FAQ 5.08: A class can be thought of as a C=style function that can
maintain state between invocations in a thread-safe manner and can
also provide multiple services. If there wer exactly one instance of
a class, and all its member functions except for exactly one public:
member function were removed, the result would be a C-style function
(the object's data would correspond to static data that is local to
the function.)

 

[Phlip]

Objects have state, identity, lifespan, storage, and behavior. Which of
asdf top-posted:

So function is not an object.

Read what I wrote. I think functions have all of those. Except you can't
create them with 'new', so their lifetime options are kind'a limit.

From the book C++ FAQs 2nd ed.

FAQ 5.06: What is an object? It depends on who you are. To a
programmer, an object is a region of storage with associated
semantics. To a designer, an object is any identifiable component in
the problem domain.

FAQ 5.08: A class can be thought of as a C=style function that can
maintain state between invocations in a thread-safe manner and can
also provide multiple services. If there wer exactly one instance of
a class, and all its member functions except for exactly one public:
member function were removed, the result would be a C-style function
(the object's data would correspond to static data that is local to
the function.)

However, the book Design Patterns sez to create the Flyweight Design
Pattern, you create a table of objects, each with no state.

Now if I felt like implementing that pattern using a table of function
pointers, then do I don't have a "reeeeeal" Flyweight Design Pattern??

Or is the Standard's answer to the question "are functions objects?" not
always absolute and perfectly useful?

 

[Daniel T.]

asdf top-posted:


Read what I wrote. I think functions have all of those. Except you
can't create them with 'new', so their lifetime options are kind'a
limit.

How does a function have state? More spicifically how does it have more
than one state?

However, the book Design Patterns sez to create the Flyweight Design
Pattern, you create a table of objects, each with no state.

By your own definition above (and Grady Booch's BTW) an "object" with no
state, isn't an object.

Now if I felt like implementing that pattern using a table of
function pointers, then do I don't have a "reeeeeal" Flyweight
Design Pattern??

Of course, but are the stateless things used by the pattern objects?

Or is the Standard's answer to the question "are functions objects?"
not always absolute and perfectly useful?

I don't think anyone would argue that only objects can be useful. Is the
definition useful? I think so, one needs to treat a state-full thing
differently than a stateless thing. An object different than a
non-object.

This doesn't really sound like it belongs in comp.lang.c++ though.

 

[Phlip]

How does a function have state? More spicifically how does it have more
than one state?

Well, it can only have one instance...

....so nobody said it had to have more state than instance... ;-)

By your own definition above (and Grady Booch's BTW) an "object" with no
state, isn't an object.

I don't care what authority said what objects are objects - including
myself. If I want to call functions used as objects in the Flyweight Pattern
"objects", then they are. What's most important is the term is useful, not
that it's more exact or more authoritative.

Of course, but are the stateless things used by the pattern objects?

Uh, I think they are implemented as instances of classes. So maybe they
aren't!

I don't think anyone would argue that only objects can be useful.

I didn't say that.

Is the
definition useful? I think so, one needs to treat a state-full thing
differently than a stateless thing. An object different than a
non-object.

How about we relax and write good OO designs.

 

[Stefan Ram]

How does a function have state?

The word "function" has no meaning.

Unless, a context is specified. A function in the language C
might have a state, while a function in mathematical set
theory does not have a state.

By your own definition above (and Grady Booch's BTW) an
"object" with no state, isn't an object.

Not having a state might as well considered to be a
special case of having a state, i.e., a degenerated
state (a state of a 1-state-system).

From the outside, an object should only have behavior,
manifested by its way to respond to messages. In the general
case, one can not tell this way whether the object directly
has an internal state.

This doesn't really sound like it belongs in comp.lang.c++ though.

In C++, an object is a typed region of storage.

This differs from the meaning of the term "object" as in
"object-oriented programming". In C++, an object (in the
sense of C++) is not a function (in the sense of C++). So,
unless a context is specified,

the word "object" has no meaning.

 

[Jerry Coffin]

[ ... ]

How does a function have state? More spicifically how does it have more
than one state?

Usually by using a static variable. For example:

enum dir { in, out };

int rand(enum dir direction, int var = 0) {

static int seed;

if (direction == in) {
seed = *var;
return 0;
}
else {
seed *= 31415927;
++seed;
return seed;
}
}

A function can have as much state data and as many states as it wishes
(within the storag limits of the implementation, of course).

I'd also note that this is somewhat language-specific. Quite a few
languages don't support a function with state like C++ does. Some
attempt to define functions so they fit closely with the usual
mathematical definition, where the output depends only on the input.
Others allow some sort of state, but with substantial limitations, and
still others more or less arbitrary state.

 

[Kaz Kylheku]

Objects have state, identity, lifespan, storage, and behavior. Which of
those do functions have? Can you point to a function?

All of the above, yet functions are not considered objects.

 

[Kaz Kylheku]

So, if a function is not an object, what is the type-of-thing that a
pointer to a function points to?

The type-of-thing is a function.

I would say that a pointer-to-a-function is an example of a
pointer-to-an-object, and hence a function is an object.

But a pointer-to-function is not an example of a pointer-to-object.

In C, pointers are partitioned into object pointers and function
pointers. Neither one is a subclass of the other.

In C++, there are additional partitions for pointers to (non-static)
data members and member functions.

 

[Kaz Kylheku]

From the book C++ FAQs 2nd ed.

FAQ 5.06: What is an object? It depends on who you are. To a
programmer, an object is a region of storage with associated
semantics. To a designer, an object is any identifiable component in
the problem domain.

That might be from a C++ FAQ, but in fact it's an assertion about
object-oriented design.

In C++, an object is whatever the ANSI/ISO standard says an object is;
no more, no less. There are no "component", "design", or "problem
domain" concepts in C++.

FAQ 5.08: A class can be thought of as a C=style function that can
maintain state between invocations in a thread-safe manner and can
also provide multiple services.

What bullshit.

 

[Salt_Peter]

This question seems to be about how the c++ community defines the
"object" concept.

I would say "false". Here's why.

The * symbol is used for dereferencing or defining a pointer to an
object.

However, the * symbol is also used to define a pointer to a function.

So, if a function is not an object, what is the type-of-thing that a
pointer to a function points to?

I would say that a pointer-to-a-function is an example of a
pointer-to-an-object, and hence a function is an object.

Paul Epstein

A function is simply an assembled sequence of events.
An object is a concrete entity based on a type / blueprint.
The fact that a pointer can point to either a function or an object is
irrelevent since a pointer could very well be pointing to garbage or
nothing.
Is garbage or null an object too?

 

[red floyd]

True or false ?

Yes. The answer to your question is either true or false.

In addition, it's considered bad form to put the question only in the
subject line of your post.

 

[Dmitry A. Kazakov]

How does a function have state? More spicifically how does it have more
than one state?

I think you guys should clarify the terms first. Function (subprogram) is a
value. Value is state. It cannot have itself. But this does not prevent us
from having stateful objects, which states are subprograms.

That was an external, client-side view. But internally a subprogram has a
lot of state. For all it is the stack of and everything that lives on, plus
all side-effects of. Consider a recursive subprogram as an example. As it
does the recursion its state changes and new objects including ones of the
subprogram type might be created, all with different states.

Consider also co-programs and concurrent programs.

By your own definition above (and Grady Booch's BTW) an "object" with no
state, isn't an object.

Hmm, there is no such thing as no state. If you have an [distinct] object
you could always invent state by treating its identity as the state. So if
something were not an object, that is not because it didn't have state.

 

[Clark S. Cox III]

This question seems to be about how the c++ community defines the
"object" concept.

I would say "false". Here's why.

The * symbol is used for dereferencing or defining a pointer to an
object.

However, the * symbol is also used to define a pointer to a function.

Those are both irrelevant. The * symbol is also used to multiply two values.

So, if a function is not an object, what is the type-of-thing that a
pointer to a function points to?

A function.

I would say that a pointer-to-a-function is an example of a
pointer-to-an-object, and hence a function is an object.

No, the C and C++ standards are quite explicit about the fact that a
pointer-to-function *is not* a pointer-to-object.

 

[Mike Wahler]

True or false ?

Compile and run the below program to get your answer:

#include <ciso646>
#include <iostream>

int main()
{
std::cout << true or false << '\n';
return 0;
}

-Mike

 

[Clark S. Cox III]

Compile and run the below program to get your answer:

#include <ciso646>

#include <iostream>

int main()
{
std::cout << true or false << '\n';
return 0;
}

-Mike