«

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

"Sune" <> wrote in message
news: ups.com...

> 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.
--
jb

(reply address in rot13, unscramble first)

<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 #

/Sune

"Sune" <> wrote in message
news: ups.com...

> <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?

<OT>

> <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
--
jb

(reply address in rot13, unscramble first)

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

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

"Sune" <> wrote in message
news: ups.com...
> 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
--
jb

(reply address in rot13, unscramble first)

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

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

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