Help a poor FORTRAN programmer with member functions?

Discussion in 'C++' started by Anthony Jones, Apr 8, 2004.

  1. 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(ITEM)
    ELSEIF (ITEM_TYPE .EQ. CIRCLE) THEN
    CALL PRINT_CIRCLE(ITEM)
    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(void* 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(circle);
    PrintObject(square);

    return 0;

    }
     
    Anthony Jones, Apr 8, 2004
    #1
    1. Advertising

  2. Anthony Jones

    Howard Guest

    "Anthony Jones" <> wrote in message
    news:...
    > 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(void* 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
     
    Howard, Apr 8, 2004
    #2
    1. Advertising


  3. > 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/
     
    Benoit Mathieu, Apr 8, 2004
    #3
  4. "Anthony Jones" <> wrote in message
    news:...
    >
    > 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(ITEM)
    > ELSEIF (ITEM_TYPE .EQ. CIRCLE) THEN
    > CALL PRINT_CIRCLE(ITEM)
    > 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
     
    John Harrison, Apr 8, 2004
    #4
  5. 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(ITEM)
    > ELSEIF (ITEM_TYPE .EQ. CIRCLE) THEN
    > CALL PRINT_CIRCLE(ITEM)
    > 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(void* 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(Shape *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(circle);
    > PrintObject(square);


    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.
     
    Kevin Goodsell, Apr 8, 2004
    #5
  6. Anthony Jones

    David Harmon Guest

    On Thu, 8 Apr 2004 19:51:23 +0100 in comp.lang.c++, "Anthony Jones"
    <> 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/
     
    David Harmon, Apr 8, 2004
    #6
  7. Anthony Jones

    Jeff Flinn Guest

    Anthony,

    See the few additions/modifications in your code below. You are very close
    but only missing a few items. You need to use virtual member functions
    rather than simple member functions. Which means you need to derive from an
    base class that declares a virtual member function.

    "Anthony Jones" <> wrote in message
    news:...
    >
    > 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(ITEM)
    > ELSEIF (ITEM_TYPE .EQ. CIRCLE) THEN
    > CALL PRINT_CIRCLE(ITEM)
    > 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 Geometry
    {
    public:
    virtual ~Geometry(){} // need a virtual destructor in this case

    virtual void Print(){}
    };

    >
    > class Square{


    replace with:

    class Square : public Geometry{


    > public:
    > void Print();
    > };
    >
    > void Square::print(){
    > cout << "This is a square";
    > }
    >
    > class Circle{


    replace with:

    class Circle : public Geometry{

    > public:
    > void Print();
    > };
    >
    > void Circle::print(){
    > cout << "This is a circle";
    > }
    >
    > // Print object function
    > // ---------------------
    >
    > void PrintObject(void* object){
    > object->Print();
    > }


    replace with:

    void PrintObject( Geometry* aObjectPtr )
    {
    aObjectPtr->Print();
    }

    or better yet:

    void PrintObject( Geometry& aObject ) // by reference
    {
    aObject.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(circle);
    > PrintObject(square);


    to use the reference version replace with:

    PrintObject( *circle ); // dereference the pointers to get references
    PrintObject( *square );

    >
    > return 0;
    >
    > }


    Better yet is to forego dealing with pointers altogether.

    int main()
    {
    Square lSquare;
    Circle lCircle;

    lCircle.Print();
    lSquare.Print();

    PrintObject( lSquare );
    PrintObject( lCircle );

    return 0;
    }

    Additionally, since typically a Print function would not modify the state of
    it's object, it's best to declare the member function as 'const'. As in:

    class Geometry
    {
    public:
    virtual ~Geometry(){}
    virtual void Print()const{}
    };

    And finally to show the real power:

    #include <vector>

    int main()
    {
    typedef std::vector<Geometry*> ;

    tGeoPtrs lGeoPtrs;

    lGeoPtrs.push_back( new Circle );
    lGeoPtrs.push_back( new Square );
    lGeoPtrs.push_back( new Circle );
    lGeoPtrs.push_back( new Square );
    lGeoPtrs.push_back( new Circle );

    for( tGeoPtrs::iterator lItr = lGeoPtrs.begin() ; lItr != lGeoPtrs.end()
    ; ++lItr )
    {
    (*lItr)->Print();

    // or

    PrintObject( *lItr ); // Pointer overload

    // or

    PrintObject( **lItr ); // reference overload

    delete *lItr; // delete it when we're done

    *lItr = NULL;
    }

    return 0;
    }

    This is just the beginning of the power/expressivenes advantages of C++
    versus Fortran.

    Jeff F
     
    Jeff Flinn, Apr 8, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matthew
    Replies:
    5
    Views:
    396
    Matthew
    Aug 20, 2004
  2. Luna Moon
    Replies:
    9
    Views:
    631
    Guest
    Sep 4, 2007
  3. Hicham Mouline
    Replies:
    0
    Views:
    450
    Hicham Mouline
    Apr 23, 2009
  4. Hicham Mouline
    Replies:
    1
    Views:
    435
    Michael DOUBEZ
    Apr 24, 2009
  5. deadpickle
    Replies:
    1
    Views:
    1,055
    Jens Thoms Toerring
    Nov 7, 2010
Loading...

Share This Page