By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,905 Members | 1,783 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,905 IT Pros & Developers. It's quick & easy.

function is not an object

P: n/a
True or false ?

Sep 16 '06 #1
Share this Question
Share on Google+
20 Replies


P: n/a
asdf wrote:
True or false ?
Objects have state, identity, lifespan, storage, and behavior. Which of
those do functions have? Can you point to a function?

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 16 '06 #2

P: n/a
So function is not an object.

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

Phlip wrote:
asdf wrote:
True or false ?

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

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 16 '06 #3

P: n/a

asdf wrote:
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

Sep 16 '06 #4

P: n/a
asdf wrote:
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
Sep 16 '06 #5

P: n/a
"asdf" <li*********@gmail.comwrote:
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.)

--
There are two things that simply cannot be doubted. Logic and our
ability to sense the world around us. Doubt those, and you no longer
have anyone to discuss it with, nor any ability to discuss it.
Sep 16 '06 #6

P: n/a
>Objects have state, identity, lifespan, storage, and behavior. Which of
>those do functions have? Can you point to a function?
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.

Daniel T. wrote:
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?

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 16 '06 #7

P: n/a
"Phlip" <ph******@yahoo.comwrote:
>>Objects have state, identity, lifespan, storage, and behavior.
Which of those do functions have? Can you point to a function?

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.
How does a function have state? More spicifically how does it have more
than one state?
Daniel T. wrote:
>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.
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.

--
There are two things that simply cannot be doubted. Logic and our
ability to sense the world around us. Doubt those, and you no longer
have anyone to discuss it with, nor any ability to discuss it.
Sep 17 '06 #8

P: n/a
Daniel T. wrote:
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... ;-)
>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.
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.
>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?
Uh, I think they are implemented as instances of classes. So maybe they
aren't!
>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.
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.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Sep 17 '06 #9

P: n/a
In article <da****************************@news.west.earthlin k.net>,
da******@earthlink.net says...

[ ... ]
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.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Sep 17 '06 #10

P: n/a
Phlip wrote:
asdf wrote:
True or false ?

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.

Sep 17 '06 #11

P: n/a
pa**********@att.net wrote:
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.

Sep 17 '06 #12

P: n/a

Daniel T. wrote:
"asdf" <li*********@gmail.comwrote:
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.
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.

Sep 17 '06 #13

P: n/a

pa**********@att.net wrote:
asdf wrote:
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
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?

Sep 17 '06 #14

P: n/a
asdf wrote:
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.
Sep 17 '06 #15

P: n/a
On Sun, 17 Sep 2006 01:37:53 GMT, Daniel T. wrote:
"Phlip" <ph******@yahoo.comwrote:
>>>Objects have state, identity, lifespan, storage, and behavior.
Which of those do functions have? Can you point to a function?

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.

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.
>Daniel T. wrote:
>>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.

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.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Sep 17 '06 #16

P: n/a
pa**********@att.net wrote:
asdf wrote:
>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.
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.

--
Clark S. Cox III
cl*******@gmail.com
Sep 17 '06 #17

P: n/a

"asdf" <li*********@gmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...
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
Sep 17 '06 #18

P: n/a
Mike Wahler wrote:
"asdf" <li*********@gmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...
>True or false ?

Compile and run the below program to get your answer:

#include <ciso646>
Why bother with including <ciso646>? <iso646.his only needed for C, as
the macros it defines (in C) are already keywords in C++.
#include <iostream>

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

-Mike


--
Clark S. Cox III
cl*******@gmail.com
Sep 17 '06 #19

P: n/a
Somebody wrote:
>
So function is not an object.

Except you can't create them with 'new',
so their lifetime options are kind'a limit.
The question of whether a function is an object
will vary from one programming language to
another. In the C family, a function is not
a first-class object. In a functional language
it is. In Python, a function looks like a first-class
object. However, Python and functional languages
implement everything by reference, under the hood.

In most languages, to treat a function as parameter
to another function, we have to create a reference
to it. In the C family, the reference is a pointer.

C# has a clever approach to this problem with
delegates. I am not sure how delegates are
implemented by the compiler. The Java approach
to this problem is rather ponderous, but then
Java seems to take the long way around for a
lot of things that ought to be more direct.

In defense of Java, the designers were simply
trying to preserve consistency. Which reminds
me of a quotation from R.W. Emerson, "A foolish
consistency is a hobgoblin of little minds." No one
actually knows what that quotation means, but it
is often quoted whenever anyone brings up the
notion of "consistency."

The question of whether a function, in the sense
of a programming artifact, can have state will
depend on the design of that function. Ideally,
a function will not have its own state, but will
return information about the state of some
attribute of an object. Ideally, a function will
not have side-effects that change the state of
an attribute.

But we're talking about programming here so
ideals have nothing to do with anything. Under
the constraints of any existing programming
language, there are no ideals. Everything
we do is constrained by the rules of the
language we choose to use.

From a mathematical view, a function is not
an object. But that is another discussion for
another day.

Richard Riehle

Oct 4 '06 #20

P: n/a
ad******@sbcglobal.net wrote:
From a mathematical view, a function is not
an object. But that is another discussion for
another day.
What???

Oct 4 '06 #21

This discussion thread is closed

Replies have been disabled for this discussion.