.moderated cross post!!! Implementing functional paradigm with C++

[Sune]

Hi!

Neither C nor C++ is the 'ultimate language' but together I think
one gets pretty close. I have worked with C++ for 8 years in the
telecom industry with realtime applications and I am fed up with
the standpoint of OOP being the only way to go. I thought so too,
up until recently...

Although being quite C++ literate I really would like to get some
insight from you guys.

I think lean C-like functional programming with small clever C++
objects like: Serializable, ctor/dtor resource mgmt (RAII),
exception objects, etc etc together with C++ strong typing and
other nice features of C++ is the way to go.

This should give me great performance/effeciency, encapsulation and
cleverness.

However, I'm so poisoned with OOP that I'm not sure how to achieve
the functional paradigm in C++ without causing unwanted side
effects.

I want the following: only instantiate the objects I use...
I do not want the following: anything which has with STL to do...

Global functional objects?....

Thanks in advance
/Sune

 

[Jakob Bieling]

telecom industry with realtime applications and I am fed up with
the standpoint of OOP being the only way to go. I thought so too,
up until recently...

Maybe you have abused the language for 8 years? C++ is not a
language where OOP is the only way to go. You have more tools than OOP.
Use whatever suits your problem and do not squeeze everything into the
OO paradigm, as you probably did. You will enjoy C++ much more this way.

I think lean C-like functional programming with small clever C++

C is not a functional programming language ..

I want the following: only instantiate the objects I use...

I cannot follow your point there. Why would you instantiate more
objects in the first place? Or am I missing something?

I do not want the following: anything which has with STL to do...

Why?


And in which way is this cross-posted? This is at best multi-posted
(tho I do not know). And moderated .. no. Somehow I get the impression
you are just trolling .. no offense if that was not the case.

 

[Sune]

<C is not a functional programming language .. >
1) Will you consider tap into your superior knowledge of C/C++ and help
me if I trade
the word functional for procedural?


<I cannot follow your point there. Why would you instantiate more
objects in the first place? Or am I missing something?>
2) If I create an object all of its members get created too. A lot of
OO/C++ overhead
is due to this 'feature'. That's why I consider the PROCEDURAL
paradigm with
'small clever objects'. I agree this wasn't too clear in the
initial post.

<Why?>
3) Because STL is an abomination, not an abstraction. If you're happy
with it, good
for you. With your standards it's quite surprising, though....

<And in which way is this cross-posted? This is at best multi-posted
(tho I do not know). And moderated .. no. >
4) Will you consider tap into your superior knowledge of English and
help me if
explain that it is cross posted with 'comp.lang.c++.moderated'?

<Somehow I get the impression
you are just trolling .. no offense if that was not the case.>
5) No offense taken #8)

/Sune

 

[Jakob Bieling]

<I cannot follow your point there. Why would you instantiate more
objects in the first place? Or am I missing something?>
2) If I create an object all of its members get created too. A
lot of OO/C++ overhead is due to this 'feature'. That's why I
consider the PROCEDURAL paradigm with 'small clever objects'.

I do not really see any advantage. If the object needs the members,
they must be created. This does not change when using the procedural
approach.

On a side-note: C++ allows you to take the procedural approach just
as well. The fact that in C++ you do not have to create a class with a
'main' member (like in Java for example) shows just that.

<Why?>
3) Because STL is an abomination, not an abstraction. If you're
happy with it, good for you. With your standards it's quite
surprising, though....

Ok, I understand that you do not like the STL. But why? What are
your arguments?

<And in which way is this cross-posted? This is at best multi-posted
(tho I do not know). And moderated .. no. >
4) Will you consider tap into your superior knowledge of English and
help me if explain that it is cross posted with
'comp.lang.c++.moderated'?

Cross-posted = every news-group you posted to is clearly visible to
the readers of your post. Multi-post = you sent your post several times
to different groups .. now your readers think you only posted to the
group they are currently reading.

But cross- or multi-posting to a group that is moderated, does not
make your post 'moderated', since it will 'appear un-moderated' in all
groups that are not moderated.

</OT>

regards

 

[arketype]

You aught to use boost. It is very STL like, but you can cut away all
the fat and use only what you need. For instance I extracted
boost::function, boost::bind and boost::scope_guard, and now I have a
straight C++ program with higher order programming support and very
flexible RAII.

No offence, but it seems as though you are being picky (this might be a
very good attitude for your application domain, who am I to judge?), so
I think you will need to 'pick through' the best of various libraries
and take what you need. Start with boost, try not to get intimidated,
and yes despite the MASSIVE amount of templates, it is lean and fast,
and it certainly is very clever!

Best of luck,
JJJ

 

[Sune]

Hi again

<I do not really see any advantage. If the object needs the members,
they must be created. This does not change when using the procedural
approach. >
Ok, a small example:

class File {

// members
string myName;
Contents* myContents;
int mySize;
unsigned char[10] myAccessRights;
};

Now, if size is the only thing I am interested in I get 3 unnessecary
object creations at File instantiation. If procedural:

int aSize = -1;

openFile( "filename.etc", nullptr, &aSize, nullptr );

Hope this makes sense?

<OT>
</OT>

BRs
/Sune

 

[Jakob Bieling]

Hi again

<I do not really see any advantage. If the object needs the members,
they must be created. This does not change when using the procedural
approach. >
Ok, a small example:

class File {

// members
string myName;
Contents* myContents;
int mySize;
unsigned char[10] myAccessRights;
};

Now, if size is the only thing I am interested in I get 3 unnessecary
object creations at File instantiation. If procedural:

int aSize = -1;

openFile( "filename.etc", nullptr, &aSize, nullptr );

Hope this makes sense?

Well, I get your point, I think.

As I said before, if OOP is not the right tool for your needs (*),
do not use it. C++ offers other tools as well, which you can and should
use.

(*) tho I think it was the right tool in your example, if you design
it right.


regards

 

[Dan Cernat]

Hi again

<I do not really see any advantage. If the object needs the members,
they must be created. This does not change when using the procedural
approach. >
Ok, a small example:

class File {

// members
string myName;
Contents* myContents;
int mySize;
unsigned char[10] myAccessRights;
};

Now, if size is the only thing I am interested in I get 3 unnessecary
object creations at File instantiation. If procedural:

int aSize = -1;

openFile( "filename.etc", nullptr, &aSize, nullptr );

Hope this makes sense?

<OT>
</OT>

BRs
/Sune

In C++ you don't pay for what you don't use. Who is making you use the
class File and the OO aproach for getting the file size? Use the
openFile function as in your example and be done with it. *You* are the
programmer. The procedural paradigm is very well supported by C++.
STL - you don't like it, don't use it.

/dan

 

[Sune]

Hi Dan,

noone is making me use the File object (I assumed in the example, that
it's part of a class library of mine). To implement a new procedure to
get _only_ the file size does not make sense to me if I have working
code such as the fictive File class. So down the line I end up paying
for what I _don't_ need out of convenience, this would not be the case
if a procedural approach was chosen.

Could you please give me some insight on my initial question?

Would global functional classes do? I want the encapsulation I would
get from using static in C...

BRs
/Olle

 

[Dan Cernat]

Hi Dan,

noone is making me use the File object (I assumed in the example, that
it's part of a class library of mine). To implement a new procedure to
get _only_ the file size does not make sense to me if I have working
code such as the fictive File class. So down the line I end up paying
for what I _don't_ need out of convenience, this would not be the case
if a procedural approach was chosen.

You are the programmer. If the code isn't good for your purposes, than
change it or write your own functions. Choose a different language.

Could you please give me some insight on my initial question?

Would global functional classes do? I want the encapsulation I would
get from using static in C...

Yes, one can go that way, but I don't see any advantages of using this
technique instead of plain old C.

/dan

 

[Sune]

Hey,

if I go this way I still can use the many useful features C++ actually
have:

- Exceptions => recursion roll-up, can't be ignored
like return values etc...
- Resource management ctor/dtor style => safe resource management
- Better typing

without having to pay for it. Effiecient AND safe...

You are the programmer. If the code isn't good for your purposes, than
change it or write your own functions. Choose a different language.

This approach isn't feasible in a commercial environment, I think. If
you still disagree, let's agree to disagree...

Any comments are appreciated.

BRs
/Sune

 

[Josh Mcfarlane]

Hey,

if I go this way I still can use the many useful features C++ actually
have:

- Exceptions => recursion roll-up, can't be ignored
like return values etc...
- Resource management ctor/dtor style => safe resource management
- Better typing

without having to pay for it. Effiecient AND safe...

This approach isn't feasible in a commercial environment, I think. If
you still disagree, let's agree to disagree...

Any comments are appreciated.

BRs
/Sune

Maybe I'm missing something. If you want a lean mean class with only
the size, then make a lean mean class with only the size. Nothing in
C++ forces you to use the least efficient denominator when using
functions. Nothing even forces you to use the OO aspect of C++

 

[verec]

Hi Dan,

noone is making me use the File object (I assumed in the example, that
it's part of a class library of mine). To implement a new procedure to
get _only_ the file size does not make sense to me if I have working
code such as the fictive File class. So down the line I end up paying
for what I _don't_ need out of convenience, this would not be the case
if a procedural approach was chosen.

struct File {
typedef /*OS specific*/ FileHandle ;
...
static size_t getSize(FileHanlde &) ;
...
} ;

....
size_t size = File::getSize(myDataFile) ;

Where's the overhead? The extra allocation? Where's that
"forced OO down your throat" ?

You can think of "structs" as "modules" or a primitive form
of namespace to organize _functions_ (not _methods_) and the
extra "static" keyword needed to "get rid of that OO stuff"
is quite a small price to pay ...

And when you despise OO, what is it precisely that youd don't
use/don't want to use?
inheritance? encapsulation? polymorphism? generic proggramming
(templates)?, "useless" abstractions?

IMHO, of course

 

[Sune]

Hi,

Josh and Jacob
-------------------------
you both think, just as Dan, that it is ok to design new code to get
the file size. I don't, period. Duplicate code is always a maintenance
nightmare. Let's do like Dan and I, let's agree to disagree.

Josh
-----------
I agree, nothing is forcing me to use OO in C++. I'll go procedural
from now on, with small, lean and clever objects. C++ is IT.

Jakob, on the topic of OO.
----------------------------------------
- Inheritance, school book nonsense.
- Polymorphism, a consequence of school book nonsense. Waste of CPU.
Use an action table with procedures instead, same abstraction
and encapsulation, no performance penalty.
- Encapsulation, not OO, ex: static keyword in C.
- Abstractions, not OO. The same goes for "useless" abstractions.
Are all OSes (written in C FYI) designed without abstractions?
WWWHHHOOOOAAAAAAAAAAAAAAAAAAA!!!!!!!!
- Templates are nice, not OO, a typing mechanism.

Your last 5 questions were supposed to be irony I guess(?). Instead
they make it painfully obvious that you have no clue what you are
talking about (like many no-questions-asked a OO pinheads). I'm
surprised you are using C++, I would have guessed Java.

About STL, check on Scott Meyer's message 'Manual Loops vs STL
Algorithms in the Real World' in the group to which I cross posted
initially: comp.lang.c++.moderated
(which I think you still haven't got)....

Here's a snippet:

Yes. It indicates that the comments describing said uses of
find_if, bind1st, etc are typically about 40,000 lines long.

In all fairness, there are about as many defending it.

Don't give up, I used to be as ignorant as you!
/Sune

 

[Jakob Bieling]

- Inheritance, school book nonsense.

If you would know when to use it properly, it would help you. If you
try to use it everywhere you can, just because people tell you it's
good, it will not help you.

- Polymorphism, a consequence of school book nonsense. Waste of CPU.
Use an action table with procedures instead, same abstraction
and encapsulation, no performance penalty.

Why do it manually, if you can let the compiler do that for you?
It's cleaner, easier to read and you do not lose anything.

- Encapsulation, not OO, ex: static keyword in C.

Hm, cannot quite follow you here. Are you saying encapsulation is
not OO? I tend to disagree. Just because there is a static keyword for
classes, which C has as well, does not mean anything. If I may remind
you, C has structs. And if you want, you can create an OO application in
C just like you can in C++. The difference is, that in C you have to do
more of the internals yourself (for example, passing the 'this' pointer
to the 'member' functions). The advantage of C++ is, that the language
hides those details and also gives guarantees about behaviour, which C
does not, in some cases.

OOP is just a paradigm and encapsulation is part of it. C++ supports
this more, C supports this less.

- Abstractions, not OO. The same goes for "useless" abstractions.

OOP is (amongst others) the concept of abstracting your real-world
problems into an object oriented solution. So abstraction is by
definition part of OOP (this does not mean that abstraction is not part
of any other paradigm). Even useless abstractions are OO. If you have
such a case, you should think about whether the OO-approach is the right
approach for your solution. As I said in a previous post: C++ offers
more tools. OOP just undergoes a hype, which is why some people try
using it everywhere, fail, and blame OOP.

Are all OSes (written in C FYI) designed without abstractions?
WWWHHHOOOOAAAAAAAAAAAAAAAAAAA!!!!!!!!

Not all OS are written in C. Counter-example: Windows, which is
partly written in C++. About abstraction of such, see above.

Your last 5 questions were supposed to be irony I guess(?). Instead

What questions? I did not ask any. You are probably confusing me
with verec.

regards

 

[Tobias Blomkvist]

Jakob Bieling sade:

Hm, cannot quite follow you here. Are you saying encapsulation is
not OO? I tend to disagree. Just because there is a static keyword for
classes, which C has as well, does not mean anything. If I may remind
you, C has structs. And if you want, you can create an OO application in
C just like you can in C++. The difference is, that in C you have to do
more of the internals yourself (for example, passing the 'this' pointer
to the 'member' functions). The advantage of C++ is, that the language
hides those details and also gives guarantees about behaviour, which C
does not, in some cases.

A nice presentation of OO in C can be found in the ebook
"Object Oriented Programming in ANSI-C"

Tobias

 

[Josh Mcfarlane]

- Inheritance, school book nonsense.
- Polymorphism, a consequence of school book nonsense. Waste of CPU.
Use an action table with procedures instead, same abstraction
and encapsulation, no performance penalty.
- Encapsulation, not OO, ex: static keyword in C.
- Abstractions, not OO. The same goes for "useless" abstractions.
Are all OSes (written in C FYI) designed without abstractions?
WWWHHHOOOOAAAAAAAAAAAAAAAAAAA!!!!!!!!
- Templates are nice, not OO, a typing mechanism.

I think there's some things you've been tainted to due to your
real-time applications. You never get something for nothing.
Polymorphism and Inheritance can be used to make code cleaner, and a
lot easier to maintain if used correctly.

Encapsulation is so much more than the "static" word in C.

I don't know where you are pulling the information that all OSes are
written in the "god-like C" language. It's probably a good combination
of languages, with a lot of raw assembly.

To me it sounds like you never truely got into the OO paradigm due to
having to optimize code to let it function at the real time level. You
should stop calling others "ignorant" just because they use code that
helps prevent errors, and they don't need that extra microsecond that
is lost due to using part of STL.

I program Windows GUIs in some of my projects, and Microsoft has MFC
with alot of nice classes. Sometimes I use them, sometimes I don't.
It's alot easier than I do as it's less duplicated effort, but using
them comes with a performance decrease (albiet slight for most items).

Nothing is free.

 

[Hans]

Sune wrote:
[snip]

Jakob, on the topic of OO.
----------------------------------------
- Inheritance, school book nonsense.
- Polymorphism, a consequence of school book nonsense. Waste of CPU.
Use an action table with procedures instead, same abstraction
and encapsulation, no performance penalty.

Is action table not just another name for vtable, i.e. an array of
function pointers? If so, the performance ought to be the same, but C++
will have better abstraction, since you will not have to manage the
tables manually.

- Encapsulation, not OO, ex: static keyword in C.
- Abstractions, not OO. The same goes for "useless" abstractions.
Are all OSes (written in C FYI) designed without abstractions?
WWWHHHOOOOAAAAAAAAAAAAAAAAAAA!!!!!!!!
- Templates are nice, not OO, a typing mechanism.

OK, here is a little feedback from an OO pinhead. A while back, I had
some free time during bad weather, and tried to write an RTOS in C++.
Of course I partially failed (~15 lines of inline assembler to
save/restore the stack pointer, various non-portable GCC
attributes...). However, writing that OS in C++, I found that
inheritance and polymorphism were very useful tools to improve
encapsulation and abstraction. You gave us a "File" example earlier,
now bear with an OS example:
The RTOS has three main classes: a singleton Scheduler, not meant for
inheritance; a very simple Task class, that can be further specialized,
and an abstract Resource class, that must be specialized. These three
classes create a very compact kernel, that can be tested and then
locked away. Very appealing to me, since I had to spend a few days
debugging assembly-level code getting the task switches right. A Task
only knows that it can acquire/release a resource (and block on the
resource, if someone else already has acquired it). The Scheduler only
handles pointers to the basic Task class.
Extending the kernel using inheritance is very simple:
The Task class has a large number of private methods that subclasses
cannot access, but the Scheduler can, thanks to the friend keyword.
This would of course have been possible to do in C, by putting the base
task and scheduler in the same file and use static on every function
that should not be public.
However, in C++, there is a further distinction: the difference between
public and protected members. The Task subclasses can access some
protected functions that do task-related things (such as manipulating
the resource the task might be hanging on). Other classes can do very
few things with a task - often nothing more than starting it.
The Resource class itself only contains some protected methods used to
block/release the resource. From this base class, many new types of
resources can be created: counting semaphores, mailboxes, pipes, etc.
The extension is done without having to change anything in the basic
kernel. Also, task classes do not need to be modified when a new type
of resource is added.

These I consider to be real, valid advantages of inheritance and
polymorphism. There is of course an occasional performance hit, since
calling a function indirectly through a vtable will add an extra
assembler instruction - but how often is that a problem? I would
happily sacrifice the extra cycles to get more encapsulation and
abstraction - I value my maintenance time more than the CPU's execution
time.
(Silly anecdote: I once came across a project were function calls were
considered prohibitively expensive. Fortunately I managed to avoid
becoming part of that project.)

Perhaps you could provide some examples or elaborations of why you
think inheritance and polymorphism is "school book nonsense"? Have you
had to endure one of those projects where they have design rules like
"everything must be a class" or "everything must inherit from class
Object"?

[snip]

 

[Sune]

<Is action table not just another name for vtable, i.e. an array of
function pointers? If so, the performance ought to be the same, but C++
will have better abstraction, since you will not have to manage the
tables manually.>

Manually, why? Regarding performance, see below.

<I would
happily sacrifice the extra cycles to get more encapsulation and
abstraction - I value my maintenance time more than the CPU's execution

time. >

From 'Efficient C++' by Dov Bulka and David Mayhew

Virtual functions negatively affect performance in 3 main ways:
1) The constructor of an object containing virtual functions must
initialize the vptr table, which is the table of pointers to its member
functions.

2) Virtual functions are called using pointer indirection, which
results in a few extra instructions per method invocation as compared
to a non-virtual method invocation.

1,2) Becomes an even larger performance problem if the base class is
virtual. Some, as EventHelix (strong C++ supporter) even tells people
not to use it at all for this reason.

3) Virtual functions whose resolution is only known at run-time cannot
be inlined. (For more on inlining, see the Inlining section.

Measurements in C/C++ Users Journal (June 2004) show that a call to a
virtual function takes 8 times the time of a inlined function.

<I would
happily sacrifice the extra cycles to get more encapsulation and
abstraction...>

- Abstraction is not a feat of OO but your mind. It's about conceptual
categorization. Babbage used abstractions...
- The necessary encapsulation can be achieved in procedural C++, an
anonymous namespace means private, the rest is public. protected is
considered even by Bjarne Stroustrup to be a language flaw.

Ok, I have to admit, when I wrote the most radical things about
inheritance I was upset beacuse that guy called me a troll without
understanding the least bit what I was talking about. Being a
condescending ass and all...

Inheritance is NICE if performance is of less importance AND you are
coding to meet requirements that are not a moving target (a system/CPU
architecture or GUI may be examples of this). I and many others who
work close to a customer who needs new features every 6 months (which
many times contradicts the requirements handed to us 6 months before)
move away from inheritance and move towards delegation. Why? Basically
because reality force us to constantly re-evaluate our abstractions,
and many times due to times constraints, violate some of them...
Delegation is more 'elastic' in these cases I think.

As Homer would have said:
- Stupid customer,
- ...stupid stupid reality.

Thanks for your input and for letting me cool down a bit #8)
/Sune

 

[Sune]

<Is action table not just another name for vtable, i.e. an array of
function pointers? If so, the performance ought to be the same, but C++
will have better abstraction, since you will not have to manage the
tables manually.>

Manually, why? Regarding performance, see below.

<I would
happily sacrifice the extra cycles to get more encapsulation and
abstraction - I value my maintenance time more than the CPU's execution

time. >

From 'Efficient C++' by Dov Bulka and David Mayhew

Virtual functions negatively affect performance in 3 main ways:
1) The constructor of an object containing virtual functions must
initialize the vptr table, which is the table of pointers to its member
functions.

2) Virtual functions are called using pointer indirection, which
results in a few extra instructions per method invocation as compared
to a non-virtual method invocation.

1,2) Becomes an even larger performance problem if the base class is
virtual. Some, as EventHelix (strong C++ supporter) even tells people
not to use it at all for this reason.

3) Virtual functions whose resolution is only known at run-time cannot
be inlined. (For more on inlining, see the Inlining section.

Measurements in C/C++ Users Journal (June 2004) show that a call to a
virtual function takes 8 times the time of a inlined function.

<I would
happily sacrifice the extra cycles to get more encapsulation and
abstraction...>

- Abstraction is not a feat of OO but your mind. It's about conceptual
categorization. Babbage used abstractions...
- The necessary encapsulation can be achieved in procedural C++, an
anonymous namespace means private, the rest is public. protected is
considered even by Bjarne Stroustrup to be a language flaw.

Ok, I have to admit, when I wrote the most radical things about
inheritance I was upset beacuse that guy called me a troll without
understanding the least bit what I was talking about. Being a
condescending ass and all...

Inheritance is NICE if performance is of less importance AND you are
coding to meet requirements that are not a moving target (a system/CPU
architecture or GUI may be examples of this). I and many others who
work close to a customer who needs new features every 6 months (which
many times contradicts the requirements handed to us 6 months before)
move away from inheritance and move towards delegation. Why? Basically
because reality force us to constantly re-evaluate our abstractions,
and many times due to times constraints, violate some of them...
Delegation is more 'elastic' in these cases I think.

As Homer would have said:
- Stupid customer,
- ...stupid stupid reality.

Thanks for your input and for letting me cool down a bit #8)
/Sune