C++Talk.NET

Sune · Guest

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

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Andor Gaudia · Guest

Sune wrote:

Sune · Guest

Hi Andor!

You are the first person where I don't have to spend half a day
defending my agenda. Thanks again.

1) I do not want to use global functions:
- I do not know how to properly scope them, in C
I have static, in C++ I know of :
class ...{ private etc....; hence the
suggested global functional classes.
- I like the name scoping a class give me.

2) I do not want to use static member functions:
- To my knowledge static members cannot be inlined...

Please feel free to add your thoughts, everybody...

BRs
/Sune

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Nemanja Trifunovic · Guest

Mirek Fidler · Guest

Sune · Guest

Hi and thanks for your patience,

Nemanja, yes. I mean procedural programming. Sorry, my copy of SICP is
probably spinning in agony in my book shelf # Cool

...sorry...

Mirek, does inlining a global function using a C++ compiler mean that
the used compiler must comply with C99 or does it use the ordinary 'C++
inlining'? A stupid question perhaps, it's just that I've never done
it.
Still, all global functions will be accessible from everywhere, right?
Due to that the static keyword in C being different from static in C++.
I don't like that, do you know away around this too?

BRs
/Sune

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Mirek Fidler · Guest

Sune wrote:

tony_in_da_uk@yahoo.co.uk · Guest

Hi Sune,

As Mirek suggested, you should investigate namespaces as a way to avoid
having too many global symbols. Specifically, an anonymous namespace
allows a block of declarations and definitions to be private to the
translation unit. For example:

x.cc

namespace
{
// static linkage in x.o
int my_num;
void my_fn(int x) { ... }
}

// external linkage in x.o
void some_fn() { my_fn(my_num };

More generally, I think I might understand what your concerns are.
Some C++ systems start considering object creation, map lookups, string
creation etc. as "cheap" operations simply because they're easy to code
and execute repeatedly. Consequently, efficiency starts to suffer and
the procedural logic is lost in long OO hierarchies. Every struct
becomes a class with getters and setters, even if only used internally
to an implementation file. Obfuscation overwhelms abstraction. But
that's just poor programming... overhauling the OO design is better
than going procedural as a knee-jerk reaction. Not sure in your case,
but I've also seen some C++ "old-timers" who've been programming C++
full-time much longer than I have who knew a lot very early on, and
just assumed there wouldn't be much more to learn, but language usage
and best practice has evolved enormously. Perhaps your company or
industry is in a time-warp, or equally, full of people who are
over-keen to innovate and lacking perspective. Still, it helps to
thoroughly understand best practices for namespaces, singletons, when
to have static member functions etc.. There's no sound reason to go
out of your way either to use or to avoid OO programming... just use it
when it seems appropriate.

Sune · Guest

Cheers to you,

this was the best and well balanced answer I've got in a long time. As
you seem to see where I'm coming from, what literature would you
recommend?

BRs
/Olle

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

tony_in_da_uk@yahoo.co.uk · Guest

Glad to have been of help Smile

.

A lot of good programming comes from experience. While you've
obviously got the years, I've found 3 years in 3 places can be better
than 15 years in one. Being forced to see how different people code is
invaluable. Seeing the consequences of mistakes, and having to make
eloquent arguments for change and demonstrate the benefits forces you
to learn your stuff really well. As a contractor, most of my learning
has come that way. Alternatively, perhaps joining a couple open-source
projects, and having your submissions reviewed, is a better education
than reading a book. Still, I'll try to recommend a few...

The book that I think is vastly underrated is right there under
everyone's nose, but too often used only as a reference... TC++PL III
by Stroustrup. It reflects an enormous amount of experience, insight
and maturity - the bloke's a genius not only as a technician and
programmer, but also as a communicator. Read through it gradually,
browse an appendix, try out an exercise or two and relate it to the
discussions. There are single sentences that convey a point that other
books spend chapters on. Also, his Design and Evolution book's worth a
read, as understanding the reasons behind different decisions leapfrogs
many of the why and what questions you see on forums like this.

Traditionally people recommend Meyers and Sutter for this distilled
common sense stuff (as distinct from Alexandrescu etc for the wow
stuff, though his recent collaboration with Sutter is in the common
sense camp). They are good reads, though there's a small percentage of
advice that I disagree with. Effective STL is particularly good though
- a must read, especially for someone who's clearly frustrated with the
STL.

Re disagreements: again it boils down to experience with larger
systems. Not that my experience is terrifically balanced or
comprehensive, but it's very good in certain areas. Sometimes these
authors are too caught up in finding an issue to write about to
appreciate the bigger picture, and even 3 * 55 engineering problems
don't yield a balanced indication of programming issues.

For example, one that particularly narks me: all this stuff about
having only core functions as function members, and moving anything
that can be moved outside as non-member functions. Simply rot. It's a
lot like premature optimisation: we should code for maximum client
usability (convenience, clarity and concision of expression, safety),
and only compromise that when there are proven or obviously real
potential physical design concerns (i.e. compilation time, link time).
It boils down to where to draw the line, but people recommending
overly-simplistic rules (like the poor misguided souls who believe the
world should be uniformly using defensive programming) aren't always
helping. Member function pros include meeting expectation,
familiarity, localisation, automatic, consistent semantics, listing in
IDEs etc..

(More) Cheers,

Tony

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Andor Gaudia · Guest

Sune wrote:

Mirek Fidler · Guest

Andor Gaudia wrote: