Re: OT: Language War (Re: "C" Manual)
On Fri, 04 Jan 2002 14:28:46 -0500, dman wrote:
>On Thu, Jan 03, 2002 at 09:39:09PM -0600, Gary Turner wrote:
>| On Thu, 03 Jan 2002 17:34:00 -0600 (CST), Richard Cobbe wrote:
>| >
>| >Lo, on Thursday, January 3, Erik Steffl did write:
>| >
>| >> what's the difference? the point is you can assign almost anything to
>| >> anything, and yet there is no segfault - i.e. the strength of types has
>| >> nothing (sort of) to do with segfaults... the resource allocation is
>| >> crucial...
>| >
>| >Type safety (plus dynamic allocation) implies advanced memory
>| >management. The converse is not true: you can slap Boehm's conservative
>| >GC onto a C++ program, but you can still get segmentation faults:
>| >
>| > char str[] = { 'b', 'a', 'd', ' ', 's', 't', 'r', 'i', 'n', 'g' };
>| > // note the lack of a terminating '\0'!
>| > cout << str;
>| >
>|
>| >No allocation issues involved. As Ben Collins pointed out elsewhere in
>| >this thread (bit of a tree-shaped thread, isn't it?), this won't
>| >necessarily cause a segfault, but it can. It's also a violation of
>| >type-safety: cout expects a null-terminated string, and as far as the
>| >compiler is concerned, str fits this. However, there's no runtime check
>| >in the output routine to verify that this is, in fact, the case. Ooops.
>|
>| Neophyte that I am, I feel like I'm bringing a knife to this gunfight.
>| This example looks to be a cheat, in that you've defined an array and
>| then treated it as a string (legal). Had you defined a string, it would
>| be null terminated and index addressable.
>
>He did define a string. In C++ there are 3 ways of defining a string
>(in C there are 2). There is "char[]", "char*" and "std::string".
Isn't 'char*' redundant, since an array var is a pointer by definition?
If I'm showing my ignorance again, I apologize.
>The latter is the best way because it provides the most protection.
>
I disagree. He defined an array of characters, just as
int a[] = 1,2,3;
is an array of integers.
To define a string he should say
char a[] = "bad string";
or
char a[11];
Either of these forms would give him a properly terminated 'string'.
Without the terminating \0, string functions will go merrily gonzo.
>
>| The fact that you *can* screw up doesn't mean you have to.
>
>True, but when choosing a language for a given project, wouldn't you
>rather use one that gives you fewer guns to shoot yourself with? I
>know I would :-). (this is not to say that C is not a good language,
>but it does have its place)
>
Isn't that true of any tool? But you choose the language you think will
best serve your needs (and that could come down to strictly legacy). It
is still the writer's responsibility to honor the function's
expectations and create the necessary error checking routines before
they shoot the wheels off.
>
>| >Therefore, I claim that type safety is a more fundamental concept than
>| >resource mangement.
>|
>| Is there a difference? Again, my ignorance knows no bounds. Doesn't
search for: knowing replace with: knows ^^^^^(couldn't stand the
bad grammar ;p )
>| the type define the required allocation?
>
>A given type will have certain allocation requirments (ie size, which
>is why a C++ class can't contain a non-pointer to a not-yet-defined
>class or to a class that contains the current class).
>
>| In the example above, is it a type, or allocation error if the
>| *programmer* decides to access str[10]? (If I counted right, that's
>| the next byte after the array bloc.)
>
>I think that would be an allocation error since it is illegal to
>access memory outside the allocated bounds.
>
It would be nice if c/c++ included array bounds checking, but since it
doesn't, the programmer *must* check and control it himself. The array
is properly allocated. It is the programmer who decided to go into
unmapped territory. If only Picard would release...
>-D
gt
Yes I fear I am living beyond my mental means--Nash
Reply to: