C (functional programming) VS C++ (object oriented programming)

[Flash Gordon]

Malcolm McLean wrote, On 07/10/07 16:28:

I've never worked on a database-intensive program.

I do. It's a major part of my job.

However I suspect it has become obsolete.

You are wrong.

There are advantages in having
short fixed fields; for instance often a compare can be done by casting
to wide integer and performing a single instruction. This only works if
padding is specified as zero.

Yes, you need to pad with a defined character (space is sometimes used
rather than a null). However the reason is NOT to allow tricks like you
describe above. The reason is so that it can be part of a key (not the
entire key) in such a way as to allow easy sorting and searching without
the datebase itself having to have any understanding of how the key is
constructed.

However nowdays everything would be managed by an sql box and that sort
of consideration is getting out of date.

The incorrect reason you suggested for fixed width fields is dead,
however fixed width fields are very much alive and kicking. Oh, I come
across them a lot in the applications we interface with, not just in our
own applications.

By the way, when I checked last BerkeleyDB had some big customers.

So strncpy() has a declining
niche.

Well, its use has certainly declined since file-systems generally don't
work the same way.

 

[spacecriter \(Bill C\)]

I think I become more and more alone...
Everybody tells me that C++ is better, because once a project becomes
very large, I should be happy that it has been written in C++ and not
C. I'm the only guy thinking that C is a great programming language
and that there is no need to program things object oriented.

Many people says also that they save more time by programming projects
object oriented, but I think its faster to program them in a good
structured functional way.

What do you think?

I think that if you use a compiler capable of handling either an OO design
or a structured design, you can do what suits your current application.

I am currently using a C++ compiler to develop a structured design.

I find that the structured style of programming can more readily accomodate
a large number of changes, or a significant paradigm shift found after the
design is complete. I have found that OO designs are harder to change, and,
thus, slower to respond in those situations.

 

[Chris Thomasson]

message [...]

Sour grapes: an (ironic or sarcastic) expression of bitterness or
hatred. Nastiness.

Sometimes, consuming seemingly "normal" levels of 'cleverly/professionally'
brewed 'fermented/aged' grape juice in a 'tasty/oak-based-medium' will
actually cause a seemingly normal person to flip his very nature around on
its head, into a radically random position...

Don't drink an drive....


What that rambling rant had to do with the question at hand, well, I don't
quite know...

Sorry!

 

[santosh]

spacecriter (Bill C) wrote:

I find that the structured style of programming can more readily
accomodate a large number of changes, or a significant paradigm shift
found after the design is complete. I have found that OO designs are
harder to change, and, thus, slower to respond in those situations.

Proponent of OOP will be very interested with this paragraph.

 

[Charlton Wilbur]

s> spacecriter (Bill C) wrote:

s> Proponent of OOP will be very interested with this paragraph.

Not really: he's speaking of his own experience, and I can't change
what he's experienced; and convincing him that the experience is the
exact opposite for many people is probably a waste of time.

Further, c.l.c is a poor choice of fora for an extended OOP advocacy
flamewar.

Charlton

 

[spacecriter \(Bill C\)]

s> Proponent of OOP will be very interested with this paragraph.

Not really: he's speaking of his own experience, and I can't change
what he's experienced; and convincing him that the experience is the
exact opposite for many people is probably a waste of time.

Further, c.l.c is a poor choice of fora for an extended OOP advocacy
flamewar.

Agreed.

I really didn't mean to throw out any flame bait, but after re-reading what
I wrote, I could see how it would be misconstrued in that fashion.

I mearly meant to point out to the OP that I shared his perspetive on
structured programs, and that C++ != OOP.

 

[Charlie Gordon]

I dont agree any suhc thing. But they are fatally flawed.


You are either a very bad programmer or a troll. Sorry but strncpy does
what the documentation says. The fact that you seem unwilling or
incapable of using it correctly has become a tad boring to be honest.

These are false accusations: I know perfectly well what strncpy does and am
quite capable of using it correctly. In my projects, I have never seen a
single place where its semantics were appropriate. strncpy has never been
"the right thing", contrary to strlcpy. My "boring" persistence at warning
other programmers about strncpy is a pedagogical move : so many "savvy"
regulars on c.l.c seem unable to grasp the concept of "error prone" and "too
easy to misuse".

Bullshit. Would you like a compiler warning when incrementing a pointer
too in case the programmer forgets to keep it pointing to valid memory?

If the compiler can determine that the pointer is incremented beyond the
border of the array, a warning seems appropriate to me. I the pointer is
known to be NULL, a warning is definitely useful:

char *p = NULL;
char *q = p++; /* please tell me this is bogus! */

 

[jacob navia]

Charlie Gordon wrote:
[snip]

I know perfectly well what strncpy does and am
quite capable of using it correctly. In my projects, I have never seen a
single place where its semantics were appropriate. strncpy has never been
"the right thing", contrary to strlcpy. My "boring" persistence at warning
other programmers about strncpy is a pedagogical move : so many "savvy"
regulars on c.l.c seem unable to grasp the concept of "error prone" and "too
easy to misuse".

This is exactly the problem. If an interface is consistently misused
this doesn't mean that all programers are stupid but that is BADLY
DESIGNED!

The C library was designed around 30 years ago and this shows!

 

[David Thompson]

Finally C is similar to C++ with the difference that in C there are no
private members, but normally private variables and functions are named
with the prefix underscore "_", so its very clear.

The second difference is that C has no templates, but I never really
needed it.

Compared to C++, the 'big' points that C does not have are: templates;
exceptions; ANY member accessibility (private or protected) and scoped
(aka nested) types and enums; member functions; static members;
namespaces; inheritance, and (related) polymorphism/dispatching;
overloading (operators or functions), and (related) references; and a
bunch of library stuff (which depend on templates and inheritance).
There are also several minor differences even in what appears to be
the 'common subset', which can getcha if you compile C as C++ or C++
as C without looking, but can easily be avoided or fixed.

Using a prefix underscore to simulate private (or anything else) is a
bad idea; in both C and C++ _many_ identifiers beginning with
underscore are reserved to the implementation. There are some you can
use if you are really careful, and also all maintenance programmers
following you, but it's easier and more robust to just avoid them all.

- formerly david.thompson1 || achar(64) || worldnet.att.net