Just a bit of background: I'm one of a group of FORTRAN programmers, looking
to switch to C++. We are trying to write a few simple examples to
demonstrate the power of the language to our manager, so he will send us all
on a conversion course.
One of many reasons is that our code is littered with examples of:
SUBROUTINE PRINT_ITEM(ITEM , ITEM_TYPE)
IF (ITEM_TYPE .EQ. SQUARE) THEN
CALL PRINT_SQUARE(IT EM)
ELSEIF (ITEM_TYPE .EQ. CIRCLE) THEN
CALL PRINT_CIRCLE(IT EM)
ELSEIF ...
(lots more item types)
ENDIF
END
(with apologies for sullying the group with FORTRAN code).
Obviously We need to find and modify all these blocks whenever we add a new
object type, or operation.
I want to write a C++ equivalent, using classes and member functions so that
I can print (or draw, or interrogate, or whatever...) an object without
knowing its type at runtime.
The latest of several attempts is shown below - the compiler complains about
the void* in the PrintObject function, though I thought I'd read that void*
could be used to mean "pointer to something, but I don't know what".
Can this code be modifed to get the effect I want? I'd like to avoid using
pointers to functions if possible.
Thanks!
#include <iostream.h>
// Class declarations
// ------------------
class Square{
public:
void Print();
};
void Square::Print() {
cout << "This is a square";
}
class Circle{
public:
void Print();
};
void Circle::Print() {
cout << "This is a circle";
}
// Print object function
// ---------------------
void PrintObject(voi d* object){
object->Print();
}
// Main Program
// ------------
int main(){
Square* square;
Circle* circle;
square = new Square;
circle = new Circle;
// Call member functions directly
circle->Print();
square->Print();
// Call member functions through PrintObject function
PrintObject(cir cle);
PrintObject(squ are);
return 0;
}
12  2066 
"Anthony Jones" <me@privacy.net > wrote in message
news:3K******** ************@ni ldram.net... I want to write a C++ equivalent, using classes and member functions so
that I can print (or draw, or interrogate, or whatever...) an object without
knowing its type at runtime.
You mean without knowing its type "at compile time"? It has to be known at
run-time, or you'd never be able to do *anything* with it! :-)
The latest of several attempts is shown below - the compiler complains
about the void* in the PrintObject function, though I thought I'd read that
void* could be used to mean "pointer to something, but I don't know what".
Yes, you can use a void* to store any other pointer, but you can never *use*
that pointer for anything (dereference it) unless you first cast it back to
whatever it's supposed to be.
// Print object function
// ---------------------
void PrintObject(voi d* object){
object->Print();
}
What you want to do instead of using a void* is to have a base class from
which all your specific shapes inherit. Then you make a virtual Print
function in the base class, and have each derived class overried that
function to do its own version of printing.
You really need to do some reading up on base classes, inheritance, and
virtual functions before attempting to go further on this.
-Howard
"Anthony Jones" <me@privacy.net > wrote in message
news:3K******** ************@ni ldram.net... I want to write a C++ equivalent, using classes and member functions so
that I can print (or draw, or interrogate, or whatever...) an object without
knowing its type at runtime.
You mean without knowing its type "at compile time"? It has to be known at
run-time, or you'd never be able to do *anything* with it! :-)
The latest of several attempts is shown below - the compiler complains
about the void* in the PrintObject function, though I thought I'd read that
void* could be used to mean "pointer to something, but I don't know what".
Yes, you can use a void* to store any other pointer, but you can never *use*
that pointer for anything (dereference it) unless you first cast it back to
whatever it's supposed to be.
// Print object function
// ---------------------
void PrintObject(voi d* object){
object->Print();
}
What you want to do instead of using a void* is to have a base class from
which all your specific shapes inherit. Then you make a virtual Print
function in the base class, and have each derived class overried that
function to do its own version of printing.
You really need to do some reading up on base classes, inheritance, and
virtual functions before attempting to go further on this.
-Howard What you want to do instead of using a void* is to have a base class from
which all your specific shapes inherit. Then you make a virtual Print
function in the base class, and have each derived class overried that
function to do its own version of printing.
You really need to do some reading up on base classes, inheritance, and
virtual functions before attempting to go further on this.
I also suggest that you have a look at some examples
available on the internet.
google for "c++ polymorphism example" ... you might find
some examples with circles and rectangles...
See for example http://onestepback.org/articles/poly/ What you want to do instead of using a void* is to have a base class from
which all your specific shapes inherit. Then you make a virtual Print
function in the base class, and have each derived class overried that
function to do its own version of printing.
You really need to do some reading up on base classes, inheritance, and
virtual functions before attempting to go further on this.
I also suggest that you have a look at some examples
available on the internet.
google for "c++ polymorphism example" ... you might find
some examples with circles and rectangles...
See for example http://onestepback.org/articles/poly/
"Anthony Jones" <me@privacy.net > wrote in message
news:3K******** ************@ni ldram.net...
Just a bit of background: I'm one of a group of FORTRAN programmers,
looking to switch to C++. We are trying to write a few simple examples to
demonstrate the power of the language to our manager, so he will send us
all on a conversion course.
One of many reasons is that our code is littered with examples of:
SUBROUTINE PRINT_ITEM(ITEM , ITEM_TYPE)
IF (ITEM_TYPE .EQ. SQUARE) THEN
CALL PRINT_SQUARE(IT EM)
ELSEIF (ITEM_TYPE .EQ. CIRCLE) THEN
CALL PRINT_CIRCLE(IT EM)
ELSEIF ...
(lots more item types)
ENDIF
END
(with apologies for sullying the group with FORTRAN code).
Obviously We need to find and modify all these blocks whenever we add a
new object type, or operation.
I want to write a C++ equivalent, using classes and member functions so
that I can print (or draw, or interrogate, or whatever...) an object without
knowing its type at runtime.
For God's sake! VIRTUAL FUNCTIONS
Look it up in your favourite text book. They do exactly what you need.
john
"Anthony Jones" <me@privacy.net > wrote in message
news:3K******** ************@ni ldram.net...
Just a bit of background: I'm one of a group of FORTRAN programmers,
looking to switch to C++. We are trying to write a few simple examples to
demonstrate the power of the language to our manager, so he will send us
all on a conversion course.
One of many reasons is that our code is littered with examples of:
SUBROUTINE PRINT_ITEM(ITEM , ITEM_TYPE)
IF (ITEM_TYPE .EQ. SQUARE) THEN
CALL PRINT_SQUARE(IT EM)
ELSEIF (ITEM_TYPE .EQ. CIRCLE) THEN
CALL PRINT_CIRCLE(IT EM)
ELSEIF ...
(lots more item types)
ENDIF
END
(with apologies for sullying the group with FORTRAN code).
Obviously We need to find and modify all these blocks whenever we add a
new object type, or operation.
I want to write a C++ equivalent, using classes and member functions so
that I can print (or draw, or interrogate, or whatever...) an object without
knowing its type at runtime.
For God's sake! VIRTUAL FUNCTIONS
Look it up in your favourite text book. They do exactly what you need.
john
Anthony Jones wrote: Just a bit of background: I'm one of a group of FORTRAN programmers, looking
to switch to C++. We are trying to write a few simple examples to
demonstrate the power of the language to our manager, so he will send us all
on a conversion course.
One of many reasons is that our code is littered with examples of:
SUBROUTINE PRINT_ITEM(ITEM , ITEM_TYPE)
IF (ITEM_TYPE .EQ. SQUARE) THEN
CALL PRINT_SQUARE(IT EM)
ELSEIF (ITEM_TYPE .EQ. CIRCLE) THEN
CALL PRINT_CIRCLE(IT EM)
ELSEIF ...
(lots more item types)
ENDIF
END
Yikes.
(with apologies for sullying the group with FORTRAN code).
Obviously We need to find and modify all these blocks whenever we add a new
object type, or operation.
I want to write a C++ equivalent, using classes and member functions so that
I can print (or draw, or interrogate, or whatever...) an object without
knowing its type at runtime.
The latest of several attempts is shown below - the compiler complains about
the void* in the PrintObject function, though I thought I'd read that void*
could be used to mean "pointer to something, but I don't know what".
Yes, and it also means "no type safety". void* should be avoided, and is
certainly not the right way to accomplish polymorphic behavior (which is
what you are looking for, whether you know that or not).
Can this code be modifed to get the effect I want? I'd like to avoid using
pointers to functions if possible.
Thanks!
#include <iostream.h>
I realize you are new to this, so please understand that I'll point out
any and all errors I spot in your code, regardless of whether they are
relevant to the immediate question. Also, my definition of an 'error'
includes anything that is not defined by the C++ standard, anything that
may behave unexpectedly, or that may behave differently on different
implementations (even if one of the "different implementations " is a
hypothetical implementation that does not actually exist). This is
standard practice for many of the people in this group.
That said, <iostream.h> is not part of the C++ standard. It is old,
pre-standard C++. Standard C++ uses <iostream> (with no .h).
// Class declarations
// ------------------
class Square{
public:
void Print();
};
In order to achieve polymorphic behavior, you need a few things that you
are missing: Inheritance, and virtual functions. Your example involves
shapes. Great, so create a class representing a shape. It will serve as
the base class for you other shapes.
class Shape
{
public:
virtual void Print() = 0;
};
class Square : public Shape
{
public:
void Print();
};
class Circle : public Shape
{
public:
void Print();
};
The "class Square : public Shape" part can be read as "Square IS A
Shape". This is often referred to as the 'is-a' relationship. Squares
and Circles are both types of Shapes, and thus share some of the same
functionality -- in particular, they all have the ability to perform the
'Print' operation.
The 'virtual' qualifier on Shape::Print() just means "this function can
behave differently in different base classes". This allows Square and
Circle to give their own version of Print() that does what they need it
to do. The '= 0' part is a bit more confusing. It has basically 2
effects: 1) It allows Shape to decline to implement Print(). There's no
reasonable way to print a generic shape, so this makes sense. It
essentially requires base classes to provide Print() instead (though a
base class can pull the same trick, passing the burden of implementing
the function onto /its/ base classes). 2) It makes Shape an abstract
class, which is a class that can really only be used as a base class.
You can't create an object of type Shape, because Shape is not a
complete class.
void Square::Print() {
cout << "This is a square";
In modern C++, 'cout' (along with most standard library names) resides
in namespace std. This means that the fully qualified name is std::cout.
You can use this fully-qualified name, or you can put a line like this:
using namespace std;
at the top of your source files, just after the #include directives.
This is sort of the lazy way of doing it, and can be bad in some cases,
but it's the easiest way to get started. There are other options as
well, but you'll learn about that later.
Other than that, no changes are required here.
}
class Circle{
public:
void Print();
};
void Circle::Print() {
cout << "This is a circle";
Same comments as for Square::Print() .
}
// Print object function
// ---------------------
void PrintObject(voi d* object){
Now, you don't want to use void* here. What you want is a function to
print an object. More specifically, a Shape. So try this instead:
void PrintShape(Shap e *shape)
{
object->Print();
shape->Print();
}
// Main Program
// ------------
int main(){
Square* square;
Circle* circle;
square = new Square;
circle = new Circle;
Generally, you shouldn't use 'new' unless you absolutely have to. It
tends to be used in real programs that do what you are demonstrating, so
its use here isn't completely inappropriate, but normally when you want
a Square you should just say
Square my_square;
It's also worth noting that a more typical way of doing what you are
doing would be like this:
Shape *square;
Shape *circle;
square = new Square;
circle = new Circle;
In fact, you'd probably be most likely to have a collection of Shape
pointers (in an array, or a container class). Such collections generally
have to be homogeneous, so they can't contain Square pointers and Circle
pointers. Luckily they don't need to, because Shape pointers can point
to Squares, Circles, and any other type that IS A Shape.
// Call member functions directly
circle->Print();
square->Print();
// Call member functions through PrintObject function
PrintObject(cir cle);
PrintObject(squ are);
Replace these with the new name 'PrintShape' and you're all set.
return 0;
}
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Anthony Jones wrote: Just a bit of background: I'm one of a group of FORTRAN programmers, looking
to switch to C++. We are trying to write a few simple examples to
demonstrate the power of the language to our manager, so he will send us all
on a conversion course.
One of many reasons is that our code is littered with examples of:
SUBROUTINE PRINT_ITEM(ITEM , ITEM_TYPE)
IF (ITEM_TYPE .EQ. SQUARE) THEN
CALL PRINT_SQUARE(IT EM)
ELSEIF (ITEM_TYPE .EQ. CIRCLE) THEN
CALL PRINT_CIRCLE(IT EM)
ELSEIF ...
(lots more item types)
ENDIF
END
Yikes.
(with apologies for sullying the group with FORTRAN code).
Obviously We need to find and modify all these blocks whenever we add a new
object type, or operation.
I want to write a C++ equivalent, using classes and member functions so that
I can print (or draw, or interrogate, or whatever...) an object without
knowing its type at runtime.
The latest of several attempts is shown below - the compiler complains about
the void* in the PrintObject function, though I thought I'd read that void*
could be used to mean "pointer to something, but I don't know what".
Yes, and it also means "no type safety". void* should be avoided, and is
certainly not the right way to accomplish polymorphic behavior (which is
what you are looking for, whether you know that or not).
Can this code be modifed to get the effect I want? I'd like to avoid using
pointers to functions if possible.
Thanks!
#include <iostream.h>
I realize you are new to this, so please understand that I'll point out
any and all errors I spot in your code, regardless of whether they are
relevant to the immediate question. Also, my definition of an 'error'
includes anything that is not defined by the C++ standard, anything that
may behave unexpectedly, or that may behave differently on different
implementations (even if one of the "different implementations " is a
hypothetical implementation that does not actually exist). This is
standard practice for many of the people in this group.
That said, <iostream.h> is not part of the C++ standard. It is old,
pre-standard C++. Standard C++ uses <iostream> (with no .h).
// Class declarations
// ------------------
class Square{
public:
void Print();
};
In order to achieve polymorphic behavior, you need a few things that you
are missing: Inheritance, and virtual functions. Your example involves
shapes. Great, so create a class representing a shape. It will serve as
the base class for you other shapes.
class Shape
{
public:
virtual void Print() = 0;
};
class Square : public Shape
{
public:
void Print();
};
class Circle : public Shape
{
public:
void Print();
};
The "class Square : public Shape" part can be read as "Square IS A
Shape". This is often referred to as the 'is-a' relationship. Squares
and Circles are both types of Shapes, and thus share some of the same
functionality -- in particular, they all have the ability to perform the
'Print' operation.
The 'virtual' qualifier on Shape::Print() just means "this function can
behave differently in different base classes". This allows Square and
Circle to give their own version of Print() that does what they need it
to do. The '= 0' part is a bit more confusing. It has basically 2
effects: 1) It allows Shape to decline to implement Print(). There's no
reasonable way to print a generic shape, so this makes sense. It
essentially requires base classes to provide Print() instead (though a
base class can pull the same trick, passing the burden of implementing
the function onto /its/ base classes). 2) It makes Shape an abstract
class, which is a class that can really only be used as a base class.
You can't create an object of type Shape, because Shape is not a
complete class.
void Square::Print() {
cout << "This is a square";
In modern C++, 'cout' (along with most standard library names) resides
in namespace std. This means that the fully qualified name is std::cout.
You can use this fully-qualified name, or you can put a line like this:
using namespace std;
at the top of your source files, just after the #include directives.
This is sort of the lazy way of doing it, and can be bad in some cases,
but it's the easiest way to get started. There are other options as
well, but you'll learn about that later.
Other than that, no changes are required here.
}
class Circle{
public:
void Print();
};
void Circle::Print() {
cout << "This is a circle";
Same comments as for Square::Print() .
}
// Print object function
// ---------------------
void PrintObject(voi d* object){
Now, you don't want to use void* here. What you want is a function to
print an object. More specifically, a Shape. So try this instead:
void PrintShape(Shap e *shape)
{
object->Print();
shape->Print();
}
// Main Program
// ------------
int main(){
Square* square;
Circle* circle;
square = new Square;
circle = new Circle;
Generally, you shouldn't use 'new' unless you absolutely have to. It
tends to be used in real programs that do what you are demonstrating, so
its use here isn't completely inappropriate, but normally when you want
a Square you should just say
Square my_square;
It's also worth noting that a more typical way of doing what you are
doing would be like this:
Shape *square;
Shape *circle;
square = new Square;
circle = new Circle;
In fact, you'd probably be most likely to have a collection of Shape
pointers (in an array, or a container class). Such collections generally
have to be homogeneous, so they can't contain Square pointers and Circle
pointers. Luckily they don't need to, because Shape pointers can point
to Squares, Circles, and any other type that IS A Shape.
// Call member functions directly
circle->Print();
square->Print();
// Call member functions through PrintObject function
PrintObject(cir cle);
PrintObject(squ are);
Replace these with the new name 'PrintShape' and you're all set.
return 0;
}
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
On Thu, 8 Apr 2004 19:51:23 +0100 in comp.lang.c++, "Anthony Jones"
<me@privacy.net > wrote, I want to write a C++ equivalent, using classes and member functions so that
I can print (or draw, or interrogate, or whatever...) an object without
knowing its type at runtime.
This issue is covered in Marshall Cline's C++ FAQ. See the topic
"[20.4] I have a heterogeneous list of objects, and my code needs to do
class-specific things to the objects. Seems like this ought to use
dynamic binding but can't figure it out. What should I do?" It is
always good to check the FAQ before posting. You can get the FAQ at: http://www.parashift.com/c++-faq-lite/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Nick Coghlan |
last post by:
Thought some folks here might find this one interesting. No great revelations,
just a fairly sensible piece on writing readable code :)
The whole article:
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=271&page=1
The section specifically on white space:...
|
by: Anthony Jones |
last post by:
Just a bit of background: I'm one of a group of FORTRAN programmers, looking
to switch to C++. We are trying to write a few simple examples to
demonstrate the power of the language to our manager, so he will send us all
on a conversion course.
One of many reasons is that our code is littered with examples of:
SUBROUTINE PRINT_ITEM(ITEM,...
|
by: Jeff Greenberg |
last post by:
Not an experienced c++ programmer here and I've gotten myself a bit
stuck. I'm trying to implement a class lib and I've run into a sticky
problem that I can't solve. I'd appreciate any help that I can get!
Consider 3 classes in the following heirarchy:
base
/ \
deriv1 deriv2
\
|
by: Adrian |
last post by:
I am trying to pass the address of a C++ function into a Fortran
routine to enable the Fortran routine to call this C++ function. I
have to do it this way as our build process does not allow circular
dependencies of DLL's.
Does anyone know how to do this, I have tried everything in my book.
I have a C++ function GetP:
DllExport void...
|
by: David Dvali |
last post by:
Hello.
I have one small program which I need to convert in C#.
The original source codes are written in Fortran 77.
Can anybody advice me what is the easy way to do this task?
Or may be there is some tools for it?
Thank you.
| | |
by: |
last post by:
Help! I'm new to c++, and am breaking my teeth on MS Visual C++ (bundled
within Visual Studio .NET 2003). Am trying to link simple c++ code to
fortran dlls created in Compaq Visual Fortran (v6.1). Posts concerning
this topic are common, but none of the posted solutions I've tried work
correctly with the above software. The linker can't seem to...
|
by: Daz |
last post by:
Hi all!
This question may hopefully spark a little debate, but my problem is
this:
I am sure it's not just me who struggles to think up names for
variables. Obviously, thinking up a name 'can' be simple, but when you
are trying to create variable names that are easy to remember,
descriptive, and not more than say 15-20 characters long, I...
|
by: StephQ |
last post by:
I face the following problem.
I wrote a poor's man plotting function: computePlot. This function
append some x-values belonging to step and the
correseponding f( x ) (for a given const member function f that takes
and return a double) values to a reference stringstream, let's call
this ss.
Then I usually use
ss.str()
to transfer the...
|
by: ghulands |
last post by:
I am having trouble implementing some function pointer stuff in c++
An object can register itself for many events
void addEventListener(CFObject *target, CFEventHandler callback,
uint8_t event);
so I declared a function pointer like
typedef void (CFObject::*CFEventHandler)(CFEvent *theEvent);
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it. ...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| |
