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

R

Richard

Mark McIntyre said:
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.

lol. Unbelievable. You have a lot in common with another poster. Legends
in your own lunchtime.
 
R

Richard Heathfield

Malcolm McLean said:
"Richard Weeks" <[email protected]> wrote in message
For the edification a programmer (myself) with varying degrees of skill,
what exactly are strncpy's "woes?"
/*
Evil, buggy code. Don't do this at home kids.
*/

char buff[32];

strncpy(buff, argv[1], 32);
printf("Your string was %s\n", buff);

So if you use it wrongly, you get bad results? Well, if that's an
illustration of strncpy's woes, here is an illustration of printf's woes
(which, again, kids should not try at home):

char *p;
printf("If you use printf wrongly, you can get bad results: %s\n", p);

Does that mean we should drop printf from the standard library?
 
T

Tor Rustad

Richard said:
Tor Rustad said:


The first mistake I found is in the first sentence: "length-bounded string
functions such as strncpy()". Finding other mistakes is left as an
exercise for the reader.

Now, you are being childish. It's prototype is in <string.h>, it's name
has "str" prefix. FYI, it is *not*:

Synopsis

#include <array.h>
char *arraycpy(char *a, const char *a_or_s);

but rather

Synopsis

#include <string.h>
char *strncpy(char *s1, const char *s2, size_t n);

we talk about, and every man page I can remember would start their API
doc, with something like "NAME strcpy, strncpy - copy a string".
 
F

Flash Gordon

Tor Rustad wrote, On 04/10/07 01:07:
The problem isn't that I can't imagine such a usage, but that this use
case is rather a typical programming *fault*. So, I deliberately put the
assert() in there, to catch it.

For the special case you describe, I would rather write something like:

n = sprintf(dest, "%.*s", max, src);

I would not because you are needlessly calling a more complex function.
I would also consider it to be a micro-*de*optimisation, i.e. using
something that looks like it will be less efficient for no good reason
(well, no reason that is good to me) although in practice the overall
impact on the program will probably be negligible.

In short, I would use the function that does exactly what I want,
nothing more and nothing less, rather than using some other function.
 
R

Richard Heathfield

Tor Rustad said:
Now, you are being childish.

Well, obviously I disagree. Let me explain why.
It's prototype is in <string.h>,

So are those of memcpy, memmove, memcmp, memchr, and memset, which are not
it's name has "str" prefix.

So does strncmp, which is not a string processing function either. So the
prefix str is not sufficient to qualify a function as being a "string
function".

Furthermore, there are several functions that require strings as input but
which do not start "str" - *printf, *scanf, atoi, atod, atol, perror,
fopen, to name but a few. These aren't what we might normally think of as
"string functions", but they do at least require strings as input.

strncpy does *not* require even one string as input. It is therefore
somewhat difficult to see how we can justify calling it a "string
function", despite its (badly-chosen) name.

and every man page I can remember would start their API
doc, with something like "NAME strcpy, strncpy - copy a string".

Man pages aren't normative, though. The C Standard does not require the
caller to provide a string to any of strncpy's parameters. It does explain
what will happen if s2 /is/ a string that is shorter than the value passed
in the third parameter, but it doesn't require s2 to be a string. (I have
checked the C99 Standard, and it's doesn't differ from C89 in this
respect.)

Your position is common and understandable, but I don't consider it to be
correct. I am putting forward a position that I do consider to be correct.
Of course you are free to disagree with me, just as I am free to disagree
with you, but using epithets like "childish" in this context does not
advance the debate in a helpful way.
 
J

jacob navia

Richard said:
Tor Rustad said:
Now, you are being childish.

Well, obviously I disagree. Let me explain why.
[snip]
and every man page I can remember would start their API
doc, with something like "NAME strcpy, strncpy - copy a string".

Man pages aren't normative, though.

There are people that quote the standard at each sentence
but do not actually read it.

H. is arguing that strncmp is not a string comparison function.
Can you imagine such nonsense?

Paragraph 7.21 of the standard is named

"String handling <string.h>"

In that section we have the subsection

<quote>
7.21.4: Comparison functions
The sign of a nonzero value returned by the comparison functions memcmp,
strcmp, and strncmp is determined by the sign of the difference between
the values of the first pair of characters (both interpreted as unsigned
char) that differ in the objects being compared
<end quote>

You read correctly Mr H?

"comparison functions ... strncmp" !!!
 
R

Richard Heathfield

jacob navia said:

There are people that quote the standard at each sentence
but do not actually read it.

I have read the parts of the Standard that relate to the point I am making.
H. is arguing that strncmp is not a string comparison function.

That's right. It *can* compare strings, but then so can memcmp, and I don't
hear anyone arguing that that's a string function.

Can you imagine such nonsense?

As is the case whenever you accuse me of writing nonsense, on reflection it
turns out not to be nonsense. (Would that the reverse were true!) Let's
look at the facts, shall we? Here is the definition of strncmp:

4.11.4.4 The strncmp function

Synopsis

#include <string.h>
int strncmp(const char *s1, const char *s2, size_t n);

Description

The strncmp function compares not more than n characters
(characters that follow a null character are not compared) from the
array pointed to by s1 to the array pointed to by s2 .

Returns

The strncmp function returns an integer greater than, equal to, or
less than zero, according as the possibly null-terminated array
pointed to by s1 is greater than, equal to, or less than the possibly
null-terminated array pointed to by s2 .

That's from C89. The C99 text is identical except that it has "accordingly"
rather than "according". As you can see, the Standard does not insist that
you pass strings to strncmp. The following code is strictly conforming:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(void)
{
char foo[4] = "abcd";
char bar[4] = "abcd";
return strncmp(foo, bar, 4) && EXIT_FAILURE;
}

There are no strings in this program. Neither foo nor bar is a string. And
yet strncmp is required to deal with them correctly. In this case, the
program must return 0. If we were to hack either foo or bar to contain
some different sequence of four characters, the program must return
EXIT_FAILURE. Had we tried the same trick with strcmp (which *is* a string
function), the behaviour would have been undefined.

Yes, you can pass strings to strncmp. You can pass strings to memcmp, too,
but that doesn't make memcmp a string function. You can pass strings to
printf, but that doesn't make printf a string function.
Paragraph 7.21 of the standard is named

"String handling <string.h>"

And yet it contains prototypes for mem*, which are not string handling
functions. So the mere appearance of a function declaration in string.h is
not sufficient to qualify it as a string handling function, as I have
already explained, but which you unaccountably appear to have missed.
In that section we have the subsection

<quote>
7.21.4: Comparison functions
The sign of a nonzero value returned by the comparison functions memcmp,
strcmp, and strncmp is determined by the sign of the difference between
the values of the first pair of characters (both interpreted as unsigned
char) that differ in the objects being compared
<end quote>

You read correctly Mr H?

Yes. Nothing in the above paragraph mentions strings. Furthermore, in that
paragraph strncmp is placed in the same category as memcmp, which is not a
string handling function.

This really is very simple.
"comparison functions ... strncmp" !!!

Yes, I agree that it's a comparison function. So what?
 
R

Richard Heathfield

Richard Heathfield said:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(void)
{
char foo[4] = "abcd";
char bar[4] = "abcd";
return strncmp(foo, bar, 4) && EXIT_FAILURE;
}

There are no strings in this program.

Er, unless you count the string literals whose first four characters are
used to initialise foo and bar respectively. But they are only used for
initialising the foo and bar arrays, and take no further part in the
proceedings.
 
L

Lion

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?

Well.I also stands alone among my classmates. Just because only few
persons here use C++, and others use Java or .NET, and then say C++
and C is bad because points bother them, and not much people give
contributes on C and C++. Like Java, you can use various class denoted
by people all around the world. But I say they are wrong, only because
they know little. There are so many site and orgonize work on these,
but there news seldom involve these, then they say C or C++ fall
behind the world. I just laugh at them.
 
J

Joe Mayo

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?

Thanks very much for your responses.
Note: You are correct by saying procedural programming and not
functional programming. I thought functional = procedural programming. :)

But the correct term is procedural programming.
I think I will prefer C anyway, because it has a simpler syntax and less
internal keywords to learn than C++. I prefer easy solutions.
 
J

Joe Mayo

jacob said:
...
No abstraction, low level, dangerous procedures like strncpy
> ...

What is dangerous on strncpy?
Is strcpy not much more dangerous than strncpy?
 
S

santosh

Joe said:
What is dangerous on strncpy?
Is strcpy not much more dangerous than strncpy?

Both are dangerous only when misused. In addition strncpy has a possibly
misleading name, which is really what , I suspect, jacob was referring to.
 
C

Chris Dollin

Joe said:
I think I will prefer C anyway, because it has a simpler syntax and less
internal keywords to learn than C++. I prefer easy solutions.

"simpler syntax and less [1] internal keywords" doesn't (necessarily) mean
"easier", which IMAO is more to do with how well things compose and
co-operate that it is to do with the size of the syntax.

Of course a cumbersome syntax can doom a straightforward idea, but no-
one would /ever/ do that in a modern programming language.

[1] /fewer/.
 
R

Richard

santosh said:
Both are dangerous only when misused. In addition strncpy has a possibly
misleading name, which is really what , I suspect, jacob was referring
to.

The reply above is valid for ANY form of C programming.

i=i++

can be potentially lethal too if you dont know what you are doing.

For gods sake, leave strncpy alone. It does what it is documented to do.

strtok and gets are the ones to diss.
 
A

Al Balmer

I don't consider truncation a feature at all,

Truncation is what it does with overlength sources. That's what it's
for.
but rather way to
implement run-time recovery.

Then why an assert? What's wrong with just returning the length of the
source, allowing the user to check whether it's longer than the size
copied? As I understand it, that's what the conventional
implementation does.
 
S

santosh

jacob said:
Richard said:
jacob navia said:
H. is arguing that strncmp is not a string comparison function.
Heathfield
That's right. [snip]

Yes, I agree that it's a comparison function. So what?

OK. I give up.

Are you really saying you don't know the difference between a comparison
function and string comparison function?

The crucial difference between strcmp and strncmp is that the former _needs_
it's arguments to be null-terminated strings while the latter doesn't.
There is a crucial difference between an array of characters, (which
needn't, but could be, a string), and a string.
 
J

jacob navia

santosh said:
jacob said:
Richard said:
jacob navia said:
H. is arguing that strncmp is not a string comparison function. Heathfield
That's right. [snip]

Yes, I agree that it's a comparison function. So what?
OK. I give up.

Are you really saying you don't know the difference between a comparison
function and string comparison function?

The crucial difference between strcmp and strncmp is that the former _needs_
it's arguments to be null-terminated strings while the latter doesn't.
There is a crucial difference between an array of characters, (which
needn't, but could be, a string), and a string.

Look:

1) The standard names EXPLICITELY strncmp a "comparison functions" in
the section String handling.
2) strncmp starts with the prefix "str"
3) Contrary to memcmp, strncmp will STOP the comparison at a zero byte,
i.e. it has STRING SEMANTICS!

But you go on telling that it is not a string comparison function. Ask
any programmer:

Santosh: Good Morning Sir. I am Santosh and I am
making a poll about string functions. Just a single
question: "Strncmp is a string comparison function or not"?

and see what answers you get.

This is so ridiculous that I just can't believe it. Heathfield can say
anything here and there will be always people that follow his stuff.
 
R

Richard Heathfield

jacob navia said:

1) The standard names EXPLICITELY strncmp a "comparison functions" in
the section String handling.

Right. It also lists memcmp in the same paragraph. Does that make memcmp a
string function? Of course not. THEREFORE (as I have already explained at
2) strncmp starts with the prefix "str"

So does strncpy, which is not a string function. THEREFORE, starting with
the prefix "str" is not sufficient to qualify a function as being a
"string function".
3) Contrary to memcmp, strncmp will STOP the comparison at a zero byte,
i.e. it has STRING SEMANTICS!

It is indeed true that *if* you pass a string to strncmp, it will honour
the terminator. Similarly, if you pass a string to printf, it will honour
the terminator. We know that printf is not a string function. Therefore,
honouring the terminator is not sufficient to make a function a "string
function". A string function, surely, is *at the very least* a function
that requires at least one of its inputs to be a string (and even that is
not enough to disqualify printf from being a string function).
This is so ridiculous that I just can't believe it.

You can lead a horse to water, but you can't make it drink.
Heathfield can say
anything here and there will be always people that follow his stuff.

You might want to ask yourself why it is that people are more willing to
believe me than they are to believe you. Think hard about 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