C++: 4 paradigms?

[crichmon]

I've perused the FAQ, found some mention of paradigm, but didn't really find
an answer to my question.

What is meant by "C++ is a 4 paradigm language?" What are the 4 paradigms
of C++ and what makes them paradigms? Is C++/CLI the 5th paradigm of C++?
why/why not?

thanks,
crichmon

[Phlip]

crichmon wrote:

I've perused the FAQ, found some mention of paradigm, but didn't really find an answer to my question.

What is meant by "C++ is a 4 paradigm language?" What are the 4 paradigms
of C++ and what makes them paradigms? Is C++/CLI the 5th paradigm of C++?
why/why not?

- procedural. Programs control flow directly
- OO. Programs control flow indirectly, thru virtual methods
- generic. Like OO but bound at compile time

- declarative.

The last one is like SQL. You arrange elements in the shape of the result
you want, pull the rip cord, and the elements drive an engine to produce the
result.

I have no idea how that should work in C++ or if it's what they meant.

I have never learned a reason to distinguish these paradigms. Just write.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Ioannis Vranos]

crichmon wrote:

I've perused the FAQ, found some mention of paradigm, but didn't really find
an answer to my question.

What is meant by "C++ is a 4 paradigm language?" What are the 4 paradigms
of C++ and what makes them paradigms? Is C++/CLI the 5th paradigm of C++?
why/why not?

Yes C++ is a multiparadigm language and currently supports 4 paradigms.
The procedural paradigm (functions etc), the modular paradigm
(namespaces), the object oriented paradigm and the generic programming
paradigm (templates). Each paradigm is supported well with optimal space
and time efficiencies.

Regarding C++/CLI, I have not seen anyone else call it as the 5th
paradigm except me. Perhaps you have seen it in my pages where I write
"We can dare to say that C++/CLI is the fifth paradigm of C++". However
I do not if this has much scientific basis, and I am going to remove
that line if I get many complaints about it. :-)


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Alf P. Steinbach]

* Ioannis Vranos:

crichmon wrote:

I've perused the FAQ, found some mention of paradigm, but didn't really find
an answer to my question.

What is meant by "C++ is a 4 paradigm language?" What are the 4 paradigms
of C++ and what makes them paradigms? Is C++/CLI the 5th paradigm of C++?
why/why not?

Yes C++ is a multiparadigm language and currently supports 4 paradigms.
The procedural paradigm (functions etc), the modular paradigm
(namespaces), the object oriented paradigm and the generic programming
paradigm (templates). Each paradigm is supported well with optimal space
and time efficiencies.

I didn't know that.

But certainly it's not something everyone agrees on.

For example, I absolutely do not agree that C++ "supports" modular
programming, since there _is_ no module concept in C++. However,
C++ allows you to fake some of it by strictly following some set of
conventions (header file guards etc.). That's in the same spirit
as assembler language supports object-orientation (even old TASM).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ioannis Vranos]

Alf P. Steinbach wrote:

Yes C++ is a multiparadigm language and currently supports 4 paradigms.
The procedural paradigm (functions etc), the modular paradigm
(namespaces), the object oriented paradigm and the generic programming
paradigm (templates). Each paradigm is supported well with optimal space
and time efficiencies.

I didn't know that.

But certainly it's not something everyone agrees on.

For example, I absolutely do not agree that C++ "supports" modular
programming, since there _is_ no module concept in C++. However,
C++ allows you to fake some of it by strictly following some set of
conventions (header file guards etc.). That's in the same spirit
as assembler language supports object-orientation (even old TASM).

I have seen what I said above in TC++PL3 . In chapter 2 BS explains the
paradigms supported and you can find the modular paradigm on page 26 (2.4).


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Alf P. Steinbach]

* Ioannis Vranos:

Alf P. Steinbach wrote:

Yes C++ is a multiparadigm language and currently supports 4 paradigms.
The procedural paradigm (functions etc), the modular paradigm
(namespaces), the object oriented paradigm and the generic programming
paradigm (templates). Each paradigm is supported well with optimal space
and time efficiencies.

I didn't know that.

But certainly it's not something everyone agrees on.

For example, I absolutely do not agree that C++ "supports" modular
programming, since there _is_ no module concept in C++. However,
C++ allows you to fake some of it by strictly following some set of
conventions (header file guards etc.). That's in the same spirit
as assembler language supports object-orientation (even old TASM).

I have seen what I said above in TC++PL3 . In chapter 2 BS explains the
paradigms supported and you can find the modular paradigm on page 26 (2.4).

Well I doubt that Bjarne says C++ supports modular programming in a
sense different from OO (e.g. like Modula or Pascal or Ada), but if he
really does then I for one disagree! ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ioannis Vranos]

Alf P. Steinbach wrote:

Well I doubt that Bjarne says C++ supports modular programming in a
sense different from OO (e.g. like Modula or Pascal or Ada), but if he
really does then I for one disagree! ;-)

Have you read the paragraph I provided you? In case you do not have this
book here is how it starts:

[It is placed after the procedural paradigm explanation and the topics
are placed in historical ordering].

"2.4 Modular Programming

Over the years, the emphasis in the design of programs has shifted from
the design of procedures and toward the organization of data. Among
other things, this reflects an increase in program size.

A set of related procedures with the data they manipulate is often
called a module. The programming paradigm becomes:
Decide which modules you want;
partition the program so that data is hidden within modules."

Then it has some more.

Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Alf P. Steinbach]

* Ioannis Vranos:

Alf P. Steinbach wrote:

Well I doubt that Bjarne says C++ supports modular programming in a
sense different from OO (e.g. like Modula or Pascal or Ada), but if he
really does then I for one disagree! ;-)
Have you read the paragraph I provided you?

Nope, cause you didn't provide it... :-)

In case you do not have this book
I don't. I have the first edition, though.

here is how it starts:

[It is placed after the procedural paradigm explanation and the topics
are placed in historical ordering].

"2.4 Modular Programming

Over the years, the emphasis in the design of programs has shifted from
the design of procedures and toward the organization of data. Among
other things, this reflects an increase in program size.

A set of related procedures with the data they manipulate is often
called a module. The programming paradigm becomes:

Decide which modules you want; partition the program so that
data is hidden within modules."

Hum, well, that could refer to just about anything, including OO, and
it doesn't say that C++ supports _whatever_ it is, so as usual I think
Bjarne has not overstated the case, but here is being misinterpreted.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ioannis Vranos]

Alf P. Steinbach wrote:

Have you read the paragraph I provided you?

Nope, cause you didn't provide it... :-)

I was talking about this: "In chapter 2 BS explains the paradigms
supported and you can find the modular paradigm on page 26 (2.4)."

"2.4 Modular Programming

Over the years, the emphasis in the design of programs has shifted from
the design of procedures and toward the organization of data. Among
other things, this reflects an increase in program size.

A set of related procedures with the data they manipulate is often
called a module. The programming paradigm becomes:

Decide which modules you want; partition the program so that
data is hidden within modules."

Hum, well, that could refer to just about anything, including OO, and
it doesn't say that C++ supports _whatever_ it is, so as usual I think
Bjarne has not overstated the case, but here is being misinterpreted.

OO paradigm is mentioned later and in this paragraph namespaces are
mentioned for implementing the paradigm:
"
[...]

C++ provides a mechanism for grouping related data, functions, etc.,
into separate namespaces. For example, the user interface of a Stack
module could be declared and used like this:
namespace Stack{ // interface
void push(char) ;
char pop() ;
}
void f()
{
Stack: :push(´c´) ;
if (Stack: :pop() != ´c´) error("impossible") ;
}
The Stack:: qualification indicates that the push() and pop() are those
from the Stack namespace. Other uses of those names will not interfere
or cause confusion.

The definition of the Stack could be provided in a separately-compiled
part of the program:
namespace Stack{ // implementation
const int max_size = 200;
char v[max_ size] ;
int top = 0;
void push(char c) { /* check for overflow and push c */ }
char pop() { /* check for underflow and pop */ }
}

The key point about this Stack module is that the user code is insulated
from the data representation of Stack by the code implementing
Stack::push() and Stack::pop(). The user doesn’t need to know that the
Stack is implemented using an array, and the implementation can be
changed without affecting user code.
[...]

"

Anyway it is an excellent book and I think every C++ programmer should
buy and *read* it.


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Alf P. Steinbach]

* Ioannis Vranos:

Anyway it is an excellent book and I think every C++ programmer should
buy and *read* it.

Yes, I agree.

In fact it's even stronger: if you like the book then you're probably
a good C++ programmer or C++ programmer material, and if not, then
likely not. ;-)

And yes, as shown (I snipped that example) it's possible to implement
Modula/Pascal/Ada-like modules in C++, by use of conventions. Some
features are not possible to implement though. For example, transparent
module initialization requires language _support_. And in a language
with module support you get automatic checking of module dependencies
and such, which must be faked via brittle include guards in C++. Etc.

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Tommy McDaniel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ioannis Vranos <iv*@guesswh.at.grad.com> wrote in message news:<cd***********@ulysses.noc.ntua.gr>...

Regarding C++/CLI, I have not seen anyone else call it as the 5th
paradigm except me. Perhaps you have seen it in my pages where I write
"We can dare to say that C++/CLI is the fifth paradigm of C++". However
I do not if this has much scientific basis, and I am going to remove
that line if I get many complaints about it. :-)

I saw it on your page the other day, and remember wondering what basis
you had to say that. I'm not telling you what to put and not put on
your page, but maybe the fact that that particular piece stood out to
me also well before reading this means something.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA+0y2VB8FYP9YqDcRAmfrAJ9ON0tBcXG978LKKYekvk VHDbQ7fwCfc4Za
8OMIln9shItZlxgYC6rqN3U=
=bkCw
-----END PGP SIGNATURE-----

[Tommy McDaniel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Phlip" <ph*******@yahoo.com> wrote in message news:<X2***************@newssvr17.news.prodigy.com >...

crichmon wrote:

What are the 4 paradigms
of C++ and what makes them paradigms?
- procedural. Programs control flow directly
- OO. Programs control flow indirectly, thru virtual methods
- generic. Like OO but bound at compile time

- declarative.

In that case it seems that there is disagreement on the fourth
paradigm. The one I have seen mentioned elsewhere is modular. Maybe
this makes five paradigms.
I have never learned a reason to distinguish these paradigms. Just write.

Amen.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA+049VB8FYP9YqDcRAv7uAJ4xsvAVJpFCwScVCt/8bnTQ95Ia0QCfVQUJ
4YD46YE+TosdZty+Lkef0tg=
=LDHj
-----END PGP SIGNATURE-----

[tom_usenet]

On Mon, 19 Jul 2004 00:40:25 +0300, Ioannis Vranos
<iv*@guesswh.at.grad.com> wrote:

Regarding C++/CLI, I have not seen anyone else call it as the 5th
paradigm except me. Perhaps you have seen it in my pages where I write
"We can dare to say that C++/CLI is the fifth paradigm of C++". However
I do not if this has much scientific basis, and I am going to remove
that line if I get many complaints about it. :-)

Surely C++/CLI is just adds extensions to some of the already present
paradigms, particularly OOP.

Tom

[crichmon]

"Ioannis Vranos" <iv*@guesswh.at.grad.com> wrote in message
news:cd***********@ulysses.noc.ntua.gr...

crichmon wrote:

I've perused the FAQ, found some mention of paradigm,
but didn't really find an answer to my question.

What is meant by "C++ is a 4 paradigm language?" What
are the 4 paradigms of C++ and what makes them
paradigms? Is C++/CLI the 5th paradigm of C++?
why/why not?
Yes C++ is a multiparadigm language and currently
supports 4 paradigms. The procedural paradigm
(functions etc), the modular paradigm (namespaces),
the object oriented paradigm and the generic
programming paradigm (templates). Each paradigm is
supported well with optimal space and time
efficiencies.

Thanks everyone for the answers!

Regarding C++/CLI, I have not seen anyone else call
it as the 5th paradigm except me. Perhaps you have
seen it in my pages where I write "We can dare to
say that C++/CLI is the fifth paradigm of C++".
Yup, that's where I got it. :)

However I do not if this has much scientific basis,
and I am going to remove that line if I get many
complaints about it. :-)

crichmon

[Ioannis Vranos]

Tommy McDaniel wrote:

I saw it on your page the other day, and remember wondering what basis
you had to say that. I'm not telling you what to put and not put on
your page, but maybe the fact that that particular piece stood out to
me also well before reading this means something.

Well, I was thinking it in this way. C++ has already been open for a GC
(TC++PL C.9.1). However when it would get a mainstream supported one?

Only when one such VM had been standardised. So here we are, CLI is a
standard, C++/CLI is an upcoming standard on how to take advantage of
such a CLI when present, with *deterministic* destruction - explicit
delete on GC objects in the managed heap and creation of GC objects in
the stack - with the latest one to be the recommended style of
programming in C++/CLI, with generics (difference from templates is that
generics are executed at run-time while templates at compile-time and
some other restrictions of generics) etc. And of course the ability to
use ISO C++ and C++/CLI mixed (which makes the source code
compilation-portable, while the clean C++/CLI mode makes it possible the
executable itself to be portable across all CLI compliant VMs).

So I do not know if we can call the GC thing a paradigm, but C++/CLI is
a new concept for sure.
BTW yesterday I discovered that Mono ( http://www.mono-project.com )
exists for GNU/Linux, Unix, Mac OS X and Windows itself.

The download page fro this CLI VM is:

http://www.mono-project.com/downloads

Interesting stuff.


Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

[Phlip]

Tommy McDaniel wrote:

Phlip wrote:

crichmon wrote:

What are the 4 paradigms
of C++ and what makes them paradigms?

- procedural. Programs control flow directly
- OO. Programs control flow indirectly, thru virtual methods
- generic. Like OO but bound at compile time

- declarative.

In that case it seems that there is disagreement on the fourth
paradigm. The one I have seen mentioned elsewhere is modular. Maybe
this makes five paradigms.

How could modular be a paradigm? How could a programming language not be
modular? JavaScript is modular.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Uwe Schnitker]

Ioannis Vranos <iv*@guesswh.at.grad.com> wrote in message news:<cd***********@ulysses.noc.ntua.gr>...

Alf P. Steinbach wrote:

Have you read the paragraph I provided you?

Nope, cause you didn't provide it... :-)

I was talking about this: "In chapter 2 BS explains the paradigms
supported and you can find the modular paradigm on page 26 (2.4)."

Note that Stroustrup no longer emphasises "modular programming" in his
more recent interviews or writings. I'd suppose it was included in
TC++PL to show what he sees as the historical progression from
procedural prgramming to OO.

He writes and talks a lot about the 4 paradigms nowadays:

1) C-Style Programming

2) Data Abstraction

3) OO Prgramming

4) Generic Programming

see, e.g.

http://www.research.att.com/~bs/style_and_libraries.pdf

written in 2002.

What Stroustrup describes as "Data Abstraction" is programming with
standalone concrete classes like std::string. He considers this
programming style to be quite different from OO programming with class
hierarchies. He also thinks that an appropriate emphasis on this
programming style is important to avoid creating unnecessarily complex
class hierarchies. See this interview with him:

http://www.artima.com/intv/goldilocks.html

I happen to agree - even if I'd prefer to use a term like "Class-Based
Programming" to "Data Abstraction".

[Don Kim]

> He writes and talks a lot about the 4 paradigms nowadays:

1) C-Style Programming

2) Data Abstraction

3) OO Prgramming

4) Generic Programming

That seems to fit the 4 most often used terms for the different paradigms
that C++ allows. Though, I've often seen the term "procedural" programming
for 1) and "Object Based" for 2). If I'm not mistaken, in Lippman's C++
Primer, the section before OO, is titled Object Based Programming.

There also is a lot of work going on to extend C++ into the functional
paradigm, such as Boost's Lamba library and another one called FC++. For
the latter, there is even a library extending FC++ to the declarative or
functional-logic paradigm. Its called LC++:

http://www.cc.gatech.edu/~yannis/lc++/

So it might be the case that C++ has 6 paradigms. If you include the work
going on in "template metaprogramming", which I'm not familiar with yet, and
it in fact extends the template mechanism beyond (good term "meta", since it
is the greek based term for beyond) its orginal design (which I heard it
does), then this might be another paradigm as well. On the new C++/CLI
extensions, its hard to say if it creates another paradigm, but I think it
might, since its goal is to allow all the C++ mechanisms to be run in a
managed run time enviroment and even the ability to run in both the managed
and unmanaged environment. This does in some sense, change the way you
program and the mental model you have of going about it.

Oh yeah, lets not forget there is also an extension to add Aspect Oriented
Programming to C++: http://www.aspectc.org/

So as I see it, here are the paradigms C++ allows:

(1) Proceedural
(2) Object Based (or Data Abstraction)
(3) Object Oriented
(4) Generic
(5) Functional
(6) Declarative
(7) Metaprogramming
(8) Aspect Oriented
(9) Managed Runtime (aka C++/CLI)

I would say the first 4 are the core paradigms, and the last 5 are yet to
have wide spread adoption, though (5), (7), and (9) are strong canidates for
it. Also, (9) is still fuzzy as to whether it is in fact a new paradigm or
just an extension to target a managed environment.

- Don Kim

[jeffc]

"Alf P. Steinbach" <al***@start.no> wrote in message
news:40****************@news.individual.net...

* Ioannis Vranos:

Anyway it is an excellent book and I think every C++ programmer should
buy and *read* it.

Yes, I agree.

How can you agree if you've neither bought it nor read it? The guy provides
you with chapter and verse for you to look up, you fail to do so, yet keep
arguing with him.

[jeffc]

"Uwe Schnitker" <sc********************@sigma-c.com> wrote in message
news:30**************************@posting.google.c om...

He writes and talks a lot about the 4 paradigms nowadays:

1) C-Style Programming

2) Data Abstraction

3) OO Prgramming

4) Generic Programming
I happen to agree - even if I'd prefer to use a term like "Class-Based
Programming" to "Data Abstraction".

class-based programming = object-based programming (as opposed to
object-oriented programming), so I don't really see how this is a separate
paradigm since OO "includes" it.

[Alf P. Steinbach]

* jeffc:

"Alf P. Steinbach" <al***@start.no> wrote in message
news:40****************@news.individual.net...

* Ioannis Vranos:

Anyway it is an excellent book and I think every C++ programmer should
buy and *read* it.

Yes, I agree.

How can you agree if you've neither bought it nor read it? The guy provides
you with chapter and verse for you to look up, you fail to do so, yet keep
arguing with him.

It so happens that your assumptions _and_ allegations are incorrect.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[jeffc]

"Alf P. Steinbach" <al***@start.no> wrote in message
news:40****************@news.individual.net...

How can you agree if you've neither bought it nor read it? The guy provides you with chapter and verse for you to look up, you fail to do so, yet keep arguing with him.
It so happens that your assumptions _and_ allegations are incorrect.

Really? From this thread...
Have you read the paragraph I provided you?
Nope
In case you do not have this book

I don't.

[Alf P. Steinbach]

* jeffc:

"Alf P. Steinbach" <al***@start.no> wrote in message
news:40****************@news.individual.net...

How can you agree if you've neither bought it nor read it? The guy provides you with chapter and verse for you to look up, you fail to do so, yet keep arguing with him.

It so happens that your assumptions _and_ allegations are incorrect.

Really? From this thread...

Have you read the paragraph I provided you?

Nope

In case you do not have this book

I don't.

That is correct.

Your assumptions and earlier allegations are not.

Hth.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[jeffc]

"Alf P. Steinbach" <al***@start.no> wrote in message
news:40****************@news.individual.net...

That is correct.

Your assumptions and earlier allegations are not.

In that case, it would be best if you went and played with yourself back in
your cave somewhere.

[Alf P. Steinbach]

* jeffc:

"Alf P. Steinbach" <al***@start.no> wrote in message
news:40****************@news.individual.net...

That is correct.

Your assumptions and earlier allegations are not.

In that case, it would be best if you went and played with yourself back in
your cave somewhere.

Plonk.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[poiuz24]

> > Yes C++ is a multiparadigm language and currently supports 4 paradigms.

The procedural paradigm (functions etc), the modular paradigm
(namespaces), the object oriented paradigm and the generic programming
paradigm (templates). Each paradigm is supported well with optimal space
and time efficiencies.
I didn't know that.

But certainly it's not something everyone agrees on.

For example, I absolutely do not agree that C++ "supports" modular
programming, since there _is_ no module concept in C++. However,

sure: namespaces

put the public interface of your "module" into one namespace,
and the implementation into a second which drags in the interface
from the first. you'll end up with strict encapsulation of
functions, types, .. in one scope
C++ allows you to fake some of it by strictly following some set of
no need to fake .. namespace/using is all you need
i guess the keywords are a bit distracting .. take those
synonyms:

module := namespace
import := using
conventions (header file guards etc.). That's in the same spirit
as assembler language supports object-orientation (even old TASM).

headers are indeed a pain in the ass. "all" that would be needed
to get rid of them would be the compiler to spill out full static
type information into an object file for the linker to consume.

in .NET/CLI, thats "manifests"
in COM thats type libraries (TLBs)
in Java its in the class files itself

the important point to note of course: headers are not required
or defined by the C++ language standard, just happen to be
a widely deployed implementation artifact.

IMHO the two biggest failures of C++ standardization:

1. lack of ABI standardization
2. lack of full static type, standardized (per platform)
information in object files

1. would have prevented MS from inventing COM (a workaround for 1.)
2. would considerable lower complexity in build process

[White Wolf]

poiuz24 wrote:

IMHO the two biggest failures of C++ standardization:

1. lack of ABI standardization
2. lack of full static type, standardized (per platform)
information in object files

1. would have prevented MS from inventing COM (a workaround for 1.)
2. would considerable lower complexity in build process

Forgive me to say that, but your above words clearly show an absolute lack
of perspective on the topic. C++ is not a Windows only programming
language. The ABI standardization you are looking for is not even there for
the C language, on the Windows platform. That did not stop it from being
used there.

The C++ standard defines a programming language. Not a compiler, not a
linker, but a language. A language as the characters which make it up, and
their meaning. Having an ABI etc. falls into the hands of the platform
provider. If there is enough demand, they will make it work. Some may call
this a quality of implementation issue.

--
WW aka Attila
:::
31.69 nHz = once a year.