creating methods for objects

[=?iso-8859-1?b?QW5kcuk=?=]

Hi,

is it possible to override methods for one specific object, like you can
do in Ruby? Something like:

--8<--

class A {
public:
void method();
}

void A::method() {
// do something...
}

A x = new A();

void x::method() {
// do something else...
}

--8<--

Or anything close to that?

Thanks,

Andre'

 

[David Harmon]

On Fri, 18 Jun 2004 16:31:01 -0300 in comp.lang.c++, André

is it possible to override methods for one specific object, like you can
do in Ruby?

No. You might declare a derived class just for that one object.
You might use a pointer to a function, or some similar low-level
hackery.

 

[Phlip]

is it possible to override methods for one specific object, like you can
do in Ruby? Something like:

--8<--

class A {
public:
void method();
}

void A::method() {
// do something...
}

A x = new A();

void x::method() {
// do something else...
}

--8<--

Or anything close to that?

No.

C++ was invented to fit the C compiler and linker model, with minimal
changes to legacy compilers. Each translation unit must contain the same
definition of each method, just to simplify the linker's requirements.

Investigate function pointers and method pointers, to let 'x' point to a
method different from its class's method.

Why can't you just use Ruby if you need it? C++ is for big, low-level
systems; not for the average code written today.

 

[JKop]

Untested code, but you'll get the jist.


class BarnyardAnimal
{
private:

int something;

static int EatDefault(BarnyardAnimal& me, int food)
{
me.something = 7 + food; //Accessing member variable
}

public:

int (*pEat)(BarnyardAnimal&,int);

int Eat(int food)
{
pEat(*this,food);
}

BarnyardAnimal(void) : Eat(EatDefault)
{

}

};


int main(void)
{
BarnyardAnimal cow;

cow.Eat(5); //Default function

cow.Eat = ReturnFunctionPointer();

cow.Eat(7); //Calls other function
}


-JKop

 

[JKop]

JKop posted:

BarnyardAnimal(void) : Eat(EatDefault)
{

}

TYPO TYPO TYPO

BarnyardAnimal(void) : pEat(EatDefault)
{

}

int main(void)
{
BarnyardAnimal cow;

cow.Eat(5); //Default function

cow.Eat = ReturnFunctionPointer();

TYPO TYPO TYPO

cow.pEat = ReturnFunctionPointer();

cow.Eat(7); //Calls other function
}

-JKop

 

[JKop]

Ignore my last 2 posts. I'll rewrite the whole lot here without typos and
errors. The following compiles:


class BarnyardAnimal
{
private:

int something;

static int EatDefault(BarnyardAnimal& me, int food)
{
me.something = 7 + food; //Accessing member variable
}

friend int EatOther(BarnyardAnimal&, int);

public:

int (*pEat)(BarnyardAnimal&,int);

int Eat(int food)
{
pEat(*this,food);
}

BarnyardAnimal(void) : pEat(EatDefault)
{

}

};

int EatOther(BarnyardAnimal& me, int food)
{
;
}

int main(void)
{
BarnyardAnimal cow;

cow.Eat(5); //Default function

cow.pEat = EatOther;

cow.Eat(7); //Calls other function
}



-JKop

 

[Ioannis Vranos]

C++ is for big, low-level
systems; not for the average code written today.

What's that suppose to mean? I use C++ to build Windows (.NET)
applications elegantly and efficiently.






Regards,

Ioannis Vranos

 

[Ioannis Vranos]

Hi,

is it possible to override methods for one specific object, like you can
do in Ruby? Something like:

--8<--

class A {
public:
void method();
}

void A::method() {
// do something...
}

A x = new A();

void x::method() {
// do something else...
}

--8<--

Or anything close to that?

Thanks,

Andre'

You can use pointers to member functions, or define other "external"
functions or so something like:


class base1
{
// ...

public:
virtual void method() { ... }
// ....
};

base1 obj1;


// ...


class base2: public base1
{
public:
void method() { new definition }
};


base2 obj2;






Regards,

Ioannis Vranos

 

[Mike Austin]

What's that suppose to mean? I use C++ to build Windows (.NET)
applications elegantly and efficiently.

Wrong. You use Managed C++ to build Windows .NET applications.

Mike Austin

 

[Ioannis Vranos]

Wrong. You use Managed C++ to build Windows .NET applications.

What do you mean? The so called "managed extensions" are
system-specific extensions for the specific platform. For example for
X-Windows Applications you can use the QT API. For Windows you can use
Borland's CLX/VCL.






Regards,

Ioannis Vranos

 

[Phlip]

Mike Austin wrote:

What do you mean? The so called "managed extensions" are
system-specific extensions for the specific platform. For example for
X-Windows Applications you can use the QT API. For Windows you can use
Borland's CLX/VCL.

What /I/ mean is to write a GUI, or a Web site, or a bunch of business
rules, or glue between enterprise modules, you need a rapid and dynamically
typed language that stays out of your way.

C++ is fun and tricky because of all the ways to create undefined behavior.
Anyone who thinks one can efficiently develop while avoiding all these
issues is inexperienced with other modern languages. C++ is portable OO
assembler, and it always puts the needs of the CPU above those of the
programmer.

What Mike probably meant is "Managed C++" is not C++ because it uses p-code
to buffer (but not remove) all those undefined behavior problems.

 

[Ioannis Vranos]

What /I/ mean is to write a GUI, or a Web site, or a bunch of business
rules, or glue between enterprise modules, you need a rapid and dynamically
typed language that stays out of your way.

The above does not mean anything in particular.

C++ is fun and tricky because of all the ways to create undefined behavior.
Anyone who thinks one can efficiently develop while avoiding all these
issues is inexperienced with other modern languages. C++ is portable OO
assembler, and it always puts the needs of the CPU above those of the
programmer.

C++ is occupies both the high level and low level space. And you can
choose the level of abstraction you like for your programming. For
regular applications running on top of an OS, you can state at the high
level of programming, where C++ has nothing to jealous from other
languages since it supports 4 paradigms and each one is supported well
(better than most one-paradigm programming languages out there).

So for example, instead of using a char * with new[] for strings, better
use std::string.

What Mike probably meant is "Managed C++" is not C++ because it uses p-code
to buffer (but not remove) all those undefined behavior problems.

Check these interesting things about C++ and .NET interaction:

There check the Visual C++ paragraph:
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx#language


This will become part of the future C++ standard:
http://www.ecma-international.org/news/ecma-TG5-PR.htm






Regards,

Ioannis Vranos

 

[Ioannis Vranos]

Check these interesting things about C++ and .NET interaction:

There check the Visual C++ paragraph:
http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx#language


This will become part of the future C++ standard:
http://www.ecma-international.org/news/ecma-TG5-PR.htm

And you can download the draft standard from here:

http://msdn.microsoft.com/visualc/homepageheadlines/ecma/default.aspx






Regards,

Ioannis Vranos

 

[Phlip]

Phlip wrote:

The above does not mean anything in particular.

You understand dynamic typing, right?

C++ is occupies both the high level and low level space. And you can
choose the level of abstraction you like for your programming. For
regular applications running on top of an OS, you can state at the high
level of programming, where C++ has nothing to jealous from other
languages since it supports 4 paradigms and each one is supported well
(better than most one-paradigm programming languages out there).

So for example, instead of using a char * with new[] for strings, better
use std::string.

Bob Hairgrove wrote [in another thread]:

Since the base class destructor [of std::list<>] is
not virtual, it is not called when
your derived class is destroyed.

The most important resource to optimize is programmer time.

C++ always errs in favor of the CPU, not the programmer. In some languages
all destructors are virtual, and the overhead for each class object is high.
In C++ it is low. If you are programming a cell phone, use C++.

 

[Ioannis Vranos]

The most important resource to optimize is programmer time.

C++ always errs in favor of the CPU, not the programmer. In some languages
all destructors are virtual, and the overhead for each class object is high.
In C++ it is low. If you are programming a cell phone, use C++.

Also it favours space efficiency too. What about a heavy duty, non-cell
phone, server system where we want to utilize every cycle and byte of it?

Is writing the keyword "virtual", which is rarely needed in essence,
really that tiresome?






Regards,

Ioannis Vranos

 

[Phlip]

Also it favours space efficiency too. What about a heavy duty, non-cell
phone, server system where we want to utilize every cycle and byte of it?

A great way to write one of those is in a soft language, but then profile
where the big footprint and the time bottlenecks are. Fix the latter by
improving its algorithm, then converting it to a lower level language.

The 80/20 rule says that 80% of your bottlenecks are in 20% of your code, so
converting 20% of it to C++ will speed you up.

Is writing the keyword "virtual", which is rarely needed in essence,
really that tiresome?

If that were the only loophole...

 

[Richard Herring]

Bob Hairgrove wrote [in another thread]:

Since the base class destructor [of std::list<>] is
not virtual, it is not called when
your derived class is destroyed.

And he was incorrect, as he acknowledged.

 

[Branimir Maksimovic]

A great way to write one of those is in a soft language, but then profile
where the big footprint and the time bottlenecks are. Fix the latter by
improving its algorithm, then converting it to a lower level language.

That would be inpractical. One usually knows where are bottlenecks,
so, adequatly, project can be divided in soft/ hard parts, about
the time when project starts.

The 80/20 rule says that 80% of your bottlenecks are in 20% of your code, so
converting 20% of it to C++ will speed you up.

Why converting? This just wastes time and possibly introduces knew
bugs.


Greetings, Bane.

P.S. Once I'v wrote banking application using C++ builder,
faster then other two guys that used oracle forms. I was finished
long ago before they finished fighting with their tool in order to met
user requirements

 

[Phlip]

Phlip wrote:

That would be inpractical. One usually knows where are bottlenecks,
so, adequatly, project can be divided in soft/ hard parts, about
the time when project starts.


Why converting? This just wastes time and possibly introduces knew
bugs.

Greetings, Bane.

P.S. Once I'v wrote banking application using C++ builder,
faster then other two guys that used oracle forms. I was finished
long ago before they finished fighting with their tool in order to met
user requirements

You probably carefully analyzed requirements, developed an object
model, and implemented it. Props. (That means "proper respects",
honestly.)

I once took a program written in absolutely despicable BASIC, all one
big function, and re-wrote it as a very small amount of Ruby code.

http://flea.sourceforge.net

I did it by converting the BASIC into a form that I could call with
system(""). Then I put the simplest possible input into that program,
collected the output, and wrote a test case which forced my Ruby code
to return the same output.

When the test failed for the correct reason, I wrote just enough Ruby
to pass the test. Then I wrote another test requesting the next
simplest feature, and I got that test to pass.

As the Ruby code grew, I attended to its design, and refactored to
develop its object model. While refactoring, I ran all the tests every
1~10 edits.

Today that program contains around 100 tests. While developing it, the
only bugs I found were in the immediate feature I worked on. Adding
new features did not cause bugs, and refactoring to improve the design
did not cause bugs. And improved designs resist bugs.

In my current work I am unfamiliar with the profile of bug risks that
you fear, but of course in the olden days I would never have
refactored my modules so aggressively. These days I use test-first
development to avoid operating a debugger, and am free to change my
designs at whim, including changing a module's language.