A newbie's code

[Kelsey Bjarnason]

[snips]

I particularly loathe their use of "memset" for initialising arrays:

float array1[56];
int *array2[56];

memset(array1,0,sizeof array1);
memset(array2,0,sizeof array2);

Not only is it stupid, it's non-portable too.

Actually, it's perfectly portable, just needs to be commented properly:

/* Fills array with patent nonsense, quite possibly causing a trap and a
system crash if you forget to put proper values in */
memset(array1,0,sizeof array1);

See? Perfectly portable.

 

[Frederick Gotham]

ena8t8si posted:

Try this... it prints the following on my system:
[...]

I hope you realize that my courtesy in posting
the previous results doesn't carry either an
obligation or an interest to run random benchmarks.

Well Wup Dee Do Da Day! If you don't want to respond then don't respond -- I
didn't hold a gun to your head.

 

[ena8t8si]

If you don't want to respond then don't respond [...]

Please rest assured, in the future I won't.

 

[Herbert Rosenau]

[snips]

I particularly loathe their use of "memset" for initialising arrays:

float array1[56];
int *array2[56];

memset(array1,0,sizeof array1);
memset(array2,0,sizeof array2);

Not only is it stupid, it's non-portable too.

Actually, it's perfectly portable, just needs to be commented properly:

It's NOT portable. The standard does not guarantee that all bits in
int or float or pointer equals to 0 are not an trap reresentation.
Filling a variable with one type does not mean that another type is
equal to. So filling an array of pointers with an array of bytes are
not guarateed that they are noways a guilty pointer. filling a float
with multple 0 bytes are not a guarantee that each float is regulary a
float 0.0.

/* Fills array with patent nonsense, quite possibly causing a trap and a
system crash if you forget to put proper values in */
memset(array1,0,sizeof array1);

See? Perfectly portable.

Solong you means that UB is perfectly portable: yes. But that is wat
you does with filling single bytes in multiple byte values. That it
works on your mashine says nothing as UB allows anything thinkable.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Michael Mair]

ena8t8si posted:

Try this... it prints the following on my system:
[...]

I hope you realize that my courtesy in posting
the previous results doesn't carry either an
obligation or an interest to run random benchmarks.

Well Wup Dee Do Da Day! If you don't want to respond then don't respond -- I
didn't hold a gun to your head.

*plonk*

-Michael

 

[Richard Bos]

Richard Bos posted:


I worded that poorly. I'll try again.

Let's take a simple function:

void Func(int *const p)
{
assert(p);

*p = 5;
}

In the finished program, it shouldn't make a difference whether NDEBUG is
defined or not, because Func should never be called with a null pointer.

If it IS called with a null pointer, it's not a runtime error, but rather an
error that the programmer made in writing the function which calls Func. (My
use of "compile-time" was misleading.)

If your user gets to see it, it's a runtime error.
If your user gets to see it, it had better be more than just a cryptic
assertion failure.

Richard

 

[Kelsey Bjarnason]

[snips]

It's NOT portable.

Missed the comment, did we?

 

[Keith Thompson]

Chris Dollin posted:

Yes.

If this were acceptable, I'd have "Func" throw an exception.

What do you mean by the words "throw" and "exception"? (Please check
the "Newsgroups:" header before answering that.)

 

[Keith Thompson]

Richard Bos posted:


I was implying that it would be a compile-time programmer error if either
pointer were null, not a runtime error.

(Unclear, but you explained that downthread.)

When you provide somebody with a completed program which you've written, all
programming errors should have been remedied, and the user should notice no
difference whether NDEBUG is defined or not (except of course for a minor
speed difference).

All programming errors should have been remedied? In what universe
can that *ever* be guaranteed? Yes, ideally all software should be
bug-free, but ...

I suggest that assert() calls may be left in production code only to
cover "this can't happen" programming errors. For example, if you're
*sure* that the expression in a switch statement can take on only one
of the values that you've explicitly handled, it might make sense to
have an assert() in a "default:" clause. If there's a logical error
in your program, it's (arguably) better for the assert() to trigger
than for the program to continue executing. The error message, which
will include the file name and line number, won't be particularly
useful to the user, but it should help the developer track down the
bug.

 

[Richard Bos]

I suggest that assert() calls may be left in production code only to
cover "this can't happen" programming errors. For example, if you're
*sure* that the expression in a switch statement can take on only one
of the values that you've explicitly handled, it might make sense to
have an assert() in a "default:" clause. If there's a logical error
in your program, it's (arguably) better for the assert() to trigger
than for the program to continue executing. The error message, which
will include the file name and line number, won't be particularly
useful to the user, but it should help the developer track down the
bug.

You have a better class of user than I do. If mine noticed the assertion
message at all, they'd report it as "Assertion failure... erm...
[nonsensical-and-certainly-incorrect-name].c... oh, and there were some
numbers. No, sorry, I don't know what the numbers were."

Richard

 

[Charlton Wilbur]

The error message, which
will include the file name and line number, won't be particularly
useful to the user, but it should help the developer track down the
bug.

You have a better class of user than I do. If mine noticed the assertion
message at all, they'd report it as "Assertion failure... erm...
[nonsensical-and-certainly-incorrect-name].c... oh, and there were some
numbers. No, sorry, I don't know what the numbers were."

And that in itself is better than "it doesn't work! fix it!"

(I had a user helpfully take a screen shot so he could *show* it
wasn't working, and in the interests of making the email smaller he
cropped the screen shot just enough to eliminate all useful
information. I think they work at it, sometimes.)

Charlton

 

[Kenneth Brody]

The error message, which
will include the file name and line number, won't be particularly
useful to the user, but it should help the developer track down the
bug.

You have a better class of user than I do. If mine noticed the assertion
message at all, they'd report it as "Assertion failure... erm...
[nonsensical-and-certainly-incorrect-name].c... oh, and there were some
numbers. No, sorry, I don't know what the numbers were."

And that in itself is better than "it doesn't work! fix it!"

(I had a user helpfully take a screen shot so he could *show* it
wasn't working, and in the interests of making the email smaller he
cropped the screen shot just enough to eliminate all useful
information. I think they work at it, sometimes.)

Sounds like you have the same clients I've had.

I think I've mentioned here (or maybe it was in a.t-s.r?) about the
person who wanted to know "what does this error mean?" I wish he
had done something "in the interests of making the email smaller",
because he ended up taking a full-screen screen capture (at 1024 by
768 by 24 bits), pasting it (twice!) into an MS-Word document,
saving it in RTF format, and attaching it to an e-mail with BASE64
encoding. The result was a 13MB e-mail, asking what the 100-ish
character message meant, and I still had 28.8K dialup at the time.

As for the "sorry, I don't know what the numbers were", we had
someone posting on a mailing list about the "granular errors" he
would keep getting with our program. Finally, after numerous posts
about "granular errors", without any further description, I finally
asked him flat out "what the heck are 'granular errors'?", and he
finally sent a (text mode -- a whole 2K worth) screen capture. Way
back then, we were using a program called DOS/4GW for running in
32-bit protected mode under MS-DOS, and its equivalent of a *nix
"SEGV" was a large dump of info, including the words "byte granular"
or "page granular" next to the segment registers. So, from half a
screen full of crash information, he picked that word, buried deep
in the middle of the dump, for his description of what happened.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Frederick Gotham]

Keith Thompson posted:

What do you mean by the words "throw" and "exception"? (Please check
the "Newsgroups:" header before answering that.)

Sorry, I make that mistake every once in a while (especially when I have both
newsgroups open in different windows). You should see the abuse I get when I
post "printf" on the other newsgroup ha!

 

[CBFalconer]

Keith Thompson posted:


Sorry, I make that mistake every once in a while (especially when
I have both newsgroups open in different windows). You should see
the abuse I get when I post "printf" on the other newsgroup ha!

Why? That is perfectly standard, as long as you #include <stdio>.

 

[Clark S. Cox III]

Why? That is perfectly standard, as long as you #include <stdio>.

[OT]ITYM <cstdio> [/OT]

 

[Frederick Gotham]

CBFalconer posted:

Why? That is perfectly standard, as long as you #include <stdio>.

Most of the programmers over on comp.lang.c++ are incompetant. They claim
that pointers, null-terminated strings, and arrays are dangerous, and that
things like "vector" and "string" should be used instead. They also claim
that variadic functions are dangerous and should never be used.

It seems the more advanced features you add to a language, the larger the
group of people who will bitch and moan that the "less advanced" features are
dangerous. I just put it down to incompetence.

 

[Ian Collins]

CBFalconer posted:





Most of the programmers over on comp.lang.c++ are incompetant. They claim
that pointers, null-terminated strings, and arrays are dangerous, and that
things like "vector" and "string" should be used instead. They also claim
that variadic functions are dangerous and should never be used.

It seems the more advanced features you add to a language, the larger the
group of people who will bitch and moan that the "less advanced" features are
dangerous. I just put it down to incompetence.

<OT>while others put it down to experience</OT>

 

[CBFalconer]

CBFalconer posted:


Most of the programmers over on comp.lang.c++ are incompetant. They
claim that pointers, null-terminated strings, and arrays are
dangerous, and that things like "vector" and "string" should be used
instead. They also claim that variadic functions are dangerous and
should never be used.

As far as variadic functions are concerned, they are right. There
are C alternatives, but you have to build them yourself. Pointers
and arrays have their own dangers, because of the wild
intermixing. Pascal handles them much better. Null terminated
strings are handleable.

It seems the more advanced features you add to a language, the larger
the group of people who will bitch and moan that the "less advanced"
features are dangerous. I just put it down to incompetence.

That may well be true.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Clark S. Cox III]

CBFalconer posted:


Most of the programmers over on comp.lang.c++ are incompetant. They claim
that pointers, null-terminated strings, and arrays are dangerous

NUL-terminated strings and malloc-allocated arrays *can* be dangerous
for beginners. This is just a matter of different languages providing
different mechanisms for doing similar things.

, and that things like "vector" and "string" should be used instead.

In general, hiding complexity is a good thing; in either language.

They also claim
that variadic functions are dangerous and should never be used.

variadic functions *are* dangerous. Avoiding them is generally a good
idea, even in C.

 

[Bill Pursell]

variadic functions *are* dangerous. Avoiding them is generally a good
idea, even in C.

That's absurd. The very first program anyone learns is:

#include <stdio.h>
int
main(void)
{
printf("Hello, world!\n");
return 0;
}

There are certainly people who will argue that it should
be written with puts instead of printf, but printf is generally
introduced right at the start.

If you mean that people shouldn't write variadic functions
until they know how, I would agree. But simply avoiding
them out of hand would be severely restrictive.