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

A

Al Balmer

You mean "procedural". Functional programming is what lisp does.

You may be right about what he meant, but let's not forget that
"functional" is a standard English word, and "functional way" may not
refer to functional programming.
 
T

Tor Rustad

Al said:
[...]
Just don't use this stinking function, use strlcpy or equivalent instead,
when appropriate.

Not available on any implementation I currently use.

Same here, but I even so used these OpenBSD interfaces since year
2000... go figure.

Use strncpy when
appropriate. When it's not, I would rather write my own function than
use strlcpy, which has different implementations on different
platforms, leading to bad assumptions by programmers, among other
problems.

Shouldn't be a problem for the implementations you use! :)

Even GCC decided not to add it :)

Did you follow the GNU discussion back then? IIRC, the main argument
against it, was that few C programmers, demanded these functions and
that rolling your own would be easy.

Things are different now, hasn't even Gwyn put forward a safe
replacement for gets()? Also we have, TR 24731 "Part I: Bounds-checking
interfaces", recommending all those *_s functions.
 
C

Charlie Gordon

Al Balmer said:
Not available on any implementation I currently use. Use strncpy when
appropriate. When it's not, I would rather write my own function than
use strlcpy, which has different implementations on different
platforms, leading to bad assumptions by programmers, among other
problems. Even GCC decided not to add it :)

I agree with you. That's what I meant by "or equivalent". I have my own
implementation as well.
strlcpy was not included in the GLIBC, because they are non-believers: there
are many instances of strncpy in the GLIBC, most of which are wrong and
could have been fixed with strlcpy.

It's a shame the committee would not define a proper library function for
limited string copy and concatenation, so everybody can safely rely on a
standardized, well defined API. A revamped stream and string parsing API
would also have helped more than VLAs.
 
J

J. J. Farrell

Richard Heathfield wrote:

Nonsense. Since he doesn't read the answers I write, he misunderstands
everything from misquoted posts.

The original poster says:

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.

Then, Mr Mark Bluemel answers:

Try bathing occasionally...

Why this insult?

What insult?
No reason. I object to that and send a message saying to Mr Bluemel that
being nasty just doesn't cut it.

Of course it doesn't, but where was he being nasty? This was obviously
a joke.
 
J

jacob navia

Charlie said:
I agree with you. That's what I meant by "or equivalent". I have my own
implementation as well.
strlcpy was not included in the GLIBC, because they are non-believers: there
are many instances of strncpy in the GLIBC, most of which are wrong and
could have been fixed with strlcpy.

It's a shame the committee would not define a proper library function for
limited string copy and concatenation, so everybody can safely rely on a
standardized, well defined API. A revamped stream and string parsing API
would also have helped more than VLAs.

One doesn't hinder the other. VLAs are useful, and they do not disable
a correct limited string copy function! Both features have nothing
to do with each other.

The basic problem in the library is that even the zero terminated
string library is lacking such fundamental features like a replacement
for strncpy!

Since it is the only portable function there, it will go on being used
with bad consequences. Of course I am not speaking about clc regulars
that never make mistakes or "don't need" strncpy. I am speaking about
the run of the mill programmers like me, that do make mistakes and that
would like to think and do something more exiting when programming
than taking care of this STUPID details!

Yeah I know. Change the language, C is for people that are unable to see
beyond this details etc etc.

No!

It is not true. We *could* write a well designed string copy function
with a maximum limitation if we wanted. As many people have pointed out,
each one has written those... BUT

Why then it is not possible to put it in the standard document?

It could take the place of gets or other functions of the same style!
 
J

jacob navia

J. J. Farrell said:
What insult?


Of course it doesn't, but where was he being nasty? This was obviously
a joke.


Of course!

How FUNNY!

So you approve that when somebody asks a perfectly valid question
(or even a bad question who cares) the "regulars" in c.l.c have the
right to laugh at him and recommend him to "take a bath".

This is one of the basic tenants of group cohesion here: to laugh at the
beginner is used in all groups to solidify group cohesion against the
new participants, at the expense of the new ones that are
perceived as weaker and isolated.

Please do not answer any more. Just take a bath pal.
Even your emails stink.
 
R

Richard Heathfield

Charlie Gordon said:

there are many instances of strncpy in the GLIBC, most of which are wrong

I'm all for fixing incorrect usages of strncpy, but it's not strncpy's
fault if it's misused.

It's a shame the committee would not define a proper library function for
limited string copy and concatenation,

Perhaps - but that is not what strncpy is for.
 
R

Richard Heathfield

jacob navia said:
Of course!

How FUNNY!

So you approve that when somebody asks a perfectly valid question
(or even a bad question who cares) the "regulars" in c.l.c have the
right to laugh at him and recommend him to "take a bath".

Nobody was laughing *at* him. It was just a joke. Not a terribly good one,
I'll grant you, but that's all it was.
This is one of the basic tenants of group cohesion here: to laugh at the
beginner

I don't laugh at beginners. I *would* laugh at your Usenet articles,
though, if I were the kind of person to laugh at tragedy.
 
A

Al Balmer

Al said:
[...]


Even GCC decided not to add it :)

Did you follow the GNU discussion back then? IIRC, the main argument
against it, was that few C programmers, demanded these functions and
that rolling your own would be easy.

Only sporadically, since I didn't have any strong feelings either way.
I remember claims that there was no evidence that they made things
safer, despite their long history in BSD, and that it's better for
programmers to be aware of how long their strings are, rather than
having to check whether data was truncated. I certainly agree with the
last, since programmers who can't properly handle strings are probably
among those who never check return values :)
Things are different now, hasn't even Gwyn put forward a safe
replacement for gets()? Also we have, TR 24731 "Part I: Bounds-checking
interfaces", recommending all those *_s functions.

A little while ago, I was asked to enhance a Windows program I wrote a
few years ago. An upgrade to the latest Visual Studio was required, as
well. One of our regular Windows programmers was happy to tell me how
to turn off the warnings about not using the *_s functions <G>.
 
D

Default User

Joe said:
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've worked on large projects in both languages. Far more important are
(not in any particular order), good sensible processes, clear vision of
what the project is supposed to accomplish, and competent software
engineers doing the work.




Brian
 
M

Martin Ambuhl

jacob said:
And then, the Ambuhlance steps in (he always does) saying that
(of course) *I* am the culprit ans starts sending insults...

Thank you for proving to all those who had not seen it before that you
are petty, paranoid, nasty, and generally to be avoided. I have been
among the leaders in praising your efforts with lcc-win32. That I
object to your off-topic postings and your snotty, sneering attitude
seems to have given you license to engage in childish sniping. Enjoy
yourself. Indeed, you are the culprit. Go back and read your own
over-reactions, paranoid delusions, and uncalled-for insults to others.
 
M

Mark McIntyre

I don't think that in general my postings in this group are about
insulting people or being nasty. If I have given that impression, I'm
rather disappointed.

Don't worry, they aren't and they don't.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
M

Mark McIntyre

Then, Mr Mark Bluemel answers:

Why this insult?

Its not an insult, its a joke. Your inability to detect them is on a
part with your inability to enter into friendly conversations and your
propensity to launch into verbal diatribes at the slightest pretext.
Just keep me in your killfile.

Dream on.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
M

Mark McIntyre

So you approve that when somebody asks a perfectly valid question
(or even a bad question who cares) the "regulars" in c.l.c have the
right to laugh at him and recommend him to "take a bath".

*sigh*

Try turning off your paranoia occasionally?
Please do not answer any more. Just take a bath pal.
Even your emails stink.

Talk about offensive and nasty.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
M

Mark McIntyre

Of course!

How FUNNY!

So you approve that when somebody asks a perfectly valid question
(or even a bad question who cares) the "regulars" in c.l.c have the
right to laugh at him and recommend him to "take a bath".

This is one of the basic tenants of group cohesion here: to laugh at the
beginner is used in all groups to solidify group cohesion against the
new participants, at the expense of the new ones that are
perceived as weaker and isolated.

Please do not answer any more. Just take a bath pal.
Even your emails stink.

Reading this and other posts made recently, I am reminded strongly of
some of the comment we got some years ago from the likes of Karl the
Chair and Bill. If my interpretation is correct and of course it may
be wildly wrong in which case I unreservedly apologise for any
distress and so forth, it would be unfair to respond as the poster may
not be entirely responsible. I'm therefore sticking JN into my
killfile indefinitely, and will deal similarly with any thread that
seems to be affected. This troubles me as I do still feel his
erroneous posts need correction. Undoubtedly however there will be
others who carry on that battle.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
J

jacob navia

Mark said:
*sigh*

Try turning off your paranoia occasionally?


Talk about offensive and nasty.

Ahhh but it was a JOKE!

Jut a JOKE!

You didn't find it FUNNY?
 
K

Keith Thompson

Ben Pfaff said:
There is occasionally a good reason to use strncpy(). However:

* Using strncpy() into a large buffer can be very inefficient.
strncpy() always writes to every byte in the destination
buffer, which can waste a lot of time if the destination
buffer is much longer than the source string.

* If the source string is longer than the size of the
destination buffer, then strncpy() doesn't write a
terminating null. So a call to strncpy() must be followed
by explicitly writing a null terminator at the end of the
destination buffer in most cases.

If strncpy() didn't write a null terminator, it usually means that not
all of the source string was copied. Just writing a null terminator
is probably the best thing to do sometimes, but often this should be
treated as an error and handled in some arbitrarily complex manner.

If strncpy() *does* copy the entire source string but doesn't write a
null terminator, then there isn't room to write one anyway (unless you
overwrite the last character of the string).

Of course, if there wasn't room in the target array to hold the source
string, it's not strcnpy()'s fault; you'll have to deal with it no
matter what you use.
 
K

Keith Thompson

Richard Heathfield said:
Ben Pfaff said:


Right. I'm aware of the issues that are raised by misuse of strncpy - but
hey, any function can be misused. That doesn't necessarily make it a bad
function.

It's not a bad function. It's a decent function, useful in some
unusual circumstances, with a bad name.
 
K

Keith Thompson

Al Balmer said:
[...]
Just don't use this stinking function, use strlcpy or equivalent instead,
when appropriate.

Not available on any implementation I currently use. Use strncpy when
appropriate. When it's not, I would rather write my own function than
use strlcpy, which has different implementations on different
platforms, leading to bad assumptions by programmers, among other
problems. Even GCC decided not to add it :)

<SOMEWHAT_OT>
Quibble: gcc doesn't provide (most of) the C library. I think you
mean that glibc doesn't provide it.
</SOMEWHAT_OT>
 
K

Keith Thompson

jacob navia said:
Yes, this is true. Hence my efforts to improve this part of C. But
many people here believe that the only possible string type is just
those zero terminated buffers!
[...]

Will you *please* stop making that false claim?

Zero-terminated buffers are the only string format provided by
standard C. (In C, the term "string" refers to a data format, not to
a data type.) It's straightforward to provide C code that implements
other string formats and/or types, and many people have done so. I
don't recall anybody here ever objecting to that.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top