comp.lang.c - 25 new messages in 5 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* rvalue pointer dereference - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/f153c8b3b4e6d1f7?hl=en
* decoding a declaration - 7 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/259df4a3d0342511?hl=en
* substring finding problem! - 5 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en
* Experiment: functional concepts in C - 8 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
* Motivation of software professionals - 4 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en

==============================================================================
TOPIC: rvalue pointer dereference
http://groups.google.com/group/comp.lang.c/t/f153c8b3b4e6d1f7?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 17 2010 11:50 am
From: Kaz Kylheku

On 2010-02-17, Ted DeLoggio <tdeloggio@gmail.com> wrote:
> I do not understand the meaning of the parentheses used when
> dereferencing the char pointer named "s" in the following program:

A parenthesized expression is a primary expression, having
the highest precedence.

An identifier expression like s is already primary expression.

Parentheses around a primary expression do nothing; they derive a
primary expression from what is already a primary expression,
without changing any aspect of its meaning (such as its type,
whether it is an lvalue, whether it is a constant expression, ...).

==============================================================================
TOPIC: decoding a declaration
http://groups.google.com/group/comp.lang.c/t/259df4a3d0342511?hl=en
==============================================================================

== 1 of 7 ==
Date: Wed, Feb 17 2010 11:46 am
From: t@t.com

Thanks to all who responded with suggestions
about a book, cdecl, coding style, typedef and high spirit attitude.

I will read the suggested books and use cdecl.

Thanks again.

== 2 of 7 ==
Date: Wed, Feb 17 2010 11:46 am
From: t@t.com

Thanks to all who responded with suggestions
about a book, cdecl, coding style, typedef and high spirit attitude.

I will read the suggested books and use cdecl.

Thanks again.

== 3 of 7 ==
Date: Wed, Feb 17 2010 11:46 am
From: t@t.com

Thanks to all who responded with suggestions
about a book, cdecl, coding style, typedef and high spirit attitude.

I will read the suggested books and use cdecl.

Thanks again.

== 4 of 7 ==
Date: Wed, Feb 17 2010 11:53 am
From: t@t.com

Thanks to all who responded with suggestions
about a book, cdecl, coding style, typedef and high spirit attitude.

I will read the suggested books and use cdecl.

Thanks again.

== 5 of 7 ==
Date: Wed, Feb 17 2010 11:53 am
From: t@t.com

Thanks to all who responded with suggestions
about a book, cdecl, coding style, typedef and high spirit attitude.

I will read the suggested books and use cdecl.

Thanks again.

== 6 of 7 ==
Date: Wed, Feb 17 2010 1:25 pm
From: Keith Thompson

t@t.com writes:
> Thanks to all who responded with suggestions
> about a book, cdecl, coding style, typedef and high spirit attitude.
>
> I will read the suggested books and use cdecl.
>
> Thanks again.

You posted the same followup 5 times. Please investigate what caused
that to happen.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 7 of 7 ==
Date: Wed, Feb 17 2010 1:41 pm
From: John Bode

On Feb 16, 3:12 pm, "t" <t...@t.com> wrote:
> I am trying to decode a declaration "void *(*p[]) (void *a, int n)"
>
> Does it mean an array of pointers to a function taking
> two parameters(one a void pointer, another an integer)
> and returning a void pointer?
>

You've got it.

> Or am I missing something? Which would be a good book
> to understand how to decode such declarations?
>

Just about any good C reference should describe declarator syntax in
general, but the way I break it down is to find the leftmost
identifier, then work my way out, remembering that [] and () bind
before * (i.e., *a[] is an array of pointer, not a pointer to an
array):

p -- p
p[] -- is an array
*p[] -- of pointers
(*p[])(void *a, int n) -- to functions taking void *
and int parameters
*(*p[])(void *a, int n) -- returning pointers
void *(*p[])(void *a, int n) -- to void

> Sorry, if my question is naive, but I feel bad and think i should
> improve my skills, if i have doubts
> about my decoding a statement in a language which a lot of high school
> students can
> do easily these days :(

==============================================================================
TOPIC: substring finding problem!
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en
==============================================================================

== 1 of 5 ==
Date: Wed, Feb 17 2010 11:49 am
From: Seebs

On 2010-02-17, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> On Feb 17, 7:16 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> Unless you're expecting to spend most of your programming career working
>> for people who have major obsessive problems with using technology in ways
>> that generally work, because of personal grudges never adequately explained,
>> I would suggest that perhaps what Nilges accepts or doesn't accept should
>> not be a component of any technical decision, ever.

> That's the ad hominem fallacy. It's not a pretentious term for
> "insult" but a common falacy, which is to suppose that an argument is
> wrong because of the person who is making it.

No, it's not an ad hominem fallacy. It's the very well supported view
that what Nilges accepts or doesn't accept should not be a component of any
technical decision. I'm not saying that an argument is wrong because of
the person who is making it. I'm saying that a conclusion should be ignored
(neither accepted nor rejected) based on the person who has offered it.

Which is to say, if you know someone is a clown, knowing his position on an
issue tells you nothing for or against the issue. Now, if he had advanced
an argument, it could be worth discussing that argument, but as long as
we're just talking about his conclusion, it's not an ad hominem fallacy to
suggest disregarding the conclusions reached by someone who is demonstrably
very bad at the topic in question.

> In fact there are good reasons for deprecating string.h.

For some purposes, yes.

For manipulation of sequences of non-NUL chars, terminated by a char, not so
much.

> chars
> effectively have to be octets, whilst often programs need to accept
> non-Latin strings.

True. This is addressed in no small part by the multibyte stuff, which you
would presumably use for multibyte strings.

> Then the functions are all very old, with certain
> weaknesses (no protection from buffer overun in strcpy, an O(N)
> performance for strcat and strlen, an inconvenient interface for
> strcat, const inconsistencies with strchr, very poor functionality
> with strfind and const inconsiencies here too, very serious buffer
> problems with sprintf, an overly difficult interface and buffer
> problems with sscanf, thread problems with strtok and a non-intuitive
> interface.

I'm not aware of "strfind".

While the various interfaces are certainly flawed, consider that the Nilges
alternative is to duplicate the flaws of the interface without even the
benefit of already having been debugged. Or, worse, to just not even come
close.

There are certainly cases where the <string.h> functions are not the right
tool. However, that Nilges argues against it is not an argument either way
in that. His arguments might be an argument either way; his conclusion is
not.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 2 of 5 ==
Date: Wed, Feb 17 2010 12:50 pm
From: Ben Bacarisse

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
<snip>
> In fact there are good reasons for deprecating string.h. chars
> effectively have to be octets, whilst often programs need to accept
> non-Latin strings.

It's easy to switch to wide character versions if you used the
equivalent str* versions. A few macros and you can build versions for
either character type very simply.

> Then the functions are all very old, with certain
> weaknesses (no protection from buffer overun in strcpy, an O(N)
> performance for strcat and strlen, an inconvenient interface for
> strcat, const inconsistencies with strchr, very poor functionality
> with strfind and const inconsiencies here too, very serious buffer
> problems with sprintf, an overly difficult interface and buffer
> problems with sscanf, thread problems with strtok and a non-intuitive
> interface.

Those are arguments for using something better, not arguments for not
using C's string functions. If the "challenge" had been: "use this
improved string library to write replace" or "design a string library
so that replace is easy to write" I for one would have no objection.

The problem is that rejecting what is already there (rather than using
something better) leads to a /more/ complex and buggy solution.

--
Ben.

== 3 of 5 ==
Date: Wed, Feb 17 2010 12:58 pm
From: Kaz Kylheku

On 2010-02-17, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
><snip>
>> In fact there are good reasons for deprecating string.h. chars
>> effectively have to be octets, whilst often programs need to accept
>> non-Latin strings.
>
> It's easy to switch to wide character versions if you used the
> equivalent str* versions.

Just watch out for C99 braindamage!

swprintf has an argument interface similar to the wide character
equivalent of snprintf, but you may be bitten by the gratuitously
different return value convention.

== 4 of 5 ==
Date: Wed, Feb 17 2010 1:14 pm
From: Richard Heathfield

Malcolm McLean wrote:
> On Feb 17, 7:16 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-02-17, fedora <no_m...@invalid.invalid> wrote:
>>
>>> Thanks Ben! I didn't use stdlib functions because i wanted to how
>>> easy/difficult it would be to write my own. also spinoza didn't accept
>>> program that called function in string.h.
>> Unless you're expecting to spend most of your programming career working
>> for people who have major obsessive problems with using technology in ways
>> that generally work, because of personal grudges never adequately explained,
>> I would suggest that perhaps what Nilges accepts or doesn't accept should
>> not be a component of any technical decision, ever.
>>
> That's the ad hominem fallacy. It's not a pretentious term for
> "insult" but a common falacy, which is to suppose that an argument is
> wrong because of the person who is making it.

No, he's not saying that an argument is wrong because Mr Nilges is
making it. He's saying that Mr Nilges's support for an argument is of no
value in determining whether or not the argument is valid. That's very
different.

Here is an example of "ad hominem" argument:

"Mr X says strcpy is dangerous. Mr X doesn't know spit about C.
Therefore strcpy is not dangerous". Poor reasoning.

Here is an example of what Seebs is saying, using the above
(hypothetical) case:

"Mr X says strcpy is dangerous. Mr X doesn't know spit about C.
Therefore X's claim that strcpy is dangerous adds no value to the
argument that strcpy is dangerous. Whether it is or isn't dangerous is
another matter entirely."

That is, he is in effect claiming that it is possible that even someone
who knows little about a subject may know enough about it to make a
correct claim, or may simply make a correct claim by chance. So, moving
back from the abstract to the concrete, he is not dismissing any claim
made by Mr Nilges as being necessarily incorrect. That would be foolish,
not only because it would be an invalid "ad hominem" argument, but also
because Mr Nilges (who is on record as saying that he wishes to cause
maximum damage to this newsgroup) could exploit such a position by
deliberately making claims that are clearly true.

> In fact there are good reasons for deprecating string.h. chars
> effectively have to be octets, whilst often programs need to accept
> non-Latin strings. Then the functions are all very old, with certain
> weaknesses (no protection from buffer overun in strcpy, an O(N)
> performance for strcat and strlen, an inconvenient interface for
> strcat, const inconsistencies with strchr, very poor functionality
> with strfind and const inconsiencies here too, very serious buffer
> problems with sprintf, an overly difficult interface and buffer
> problems with sscanf, thread problems with strtok and a non-intuitive
> interface.

Taking your specific points one at a time:

Whilst it is true that strcpy offers no added protection against buffer
overrun, careful programming overcomes this problem. Thus, strcpy does
not get in the way of the programmer who knows full well that his buffer
is sufficiently large - no performance penalty is imposed.

Yes, strcat and strlen are O(N) - so, where it matters, you remember the
string length, having found it out the first time. These two functions
offer simple solutions to a simple task, and as such are very often a
good solution to the task at hand. Where that is not the case, we have
the option of building more powerful tools. (And yes, I agree that
strcat's interface could be improved; for example, it could return a
pointer to the null terminator rather than to the beginning of the string.)

Again, I must agree that the const inconsistency with strchr is a bit of
a wart. But the input is const purely to constitute a promise that the
function won't write to the input string. The return value is non-const
because strchr would otherwise be a real pain to use. How could it be
done better?

As for strfind, that's not C's problem. Take it up with the vendor.

To my mind, the sprintf function does not have serious buffer problems.
Nevertheless, some people obviously disagree, and C99 provides snprintf
for such people.

The scanf function is basically a mess, and is rarely used correctly. I
am at a loss to understand why it is introduced so early in programming
texts.

The strtok function is of limited use, but there are times when it is
just the ticket. It would be better, however, for it to take a state
pointer. I'm not convinced that its interface is particularly non-intuitive.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 5 of 5 ==
Date: Wed, Feb 17 2010 1:19 pm
From: Walter Banks

Ben Bacarisse wrote:

> Those are arguments for using something better, not arguments for not
> using C's string functions. If the "challenge" had been: "use this
> improved string library to write replace" or "design a string library
> so that replace is easy to write" I for one would have no objection.
>
> The problem is that rejecting what is already there (rather than using
> something better) leads to a /more/ complex and buggy solution.

This whole project thread has been filled how not to engineer software.
Application code specifically avoiding libraries, Not Invented Here,
random design with moving target specifications or no specifications,
ad hoc testing with a dose of 20+ Year old unresolved office battles,
interpersonal rivalry and off topic rants.

As several have stated not the environment that we are used to.

Regards

w..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

==============================================================================
TOPIC: Experiment: functional concepts in C
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
==============================================================================

== 1 of 8 ==
Date: Wed, Feb 17 2010 12:32 pm
From: Kaz Kylheku

On 2010-02-17, Ertugrul Söylemez <es@ertes.de> wrote:
> Kaz Kylheku <kkylheku@gmail.com> wrote:
>
>> On 2010-02-16, Ertugrul Söylemez <es@ertes.de> wrote:
>> > Hyman Rosen <hyrosen@mail.com> wrote:
>> >
>> >> On 2/16/2010 3:42 PM, Ertugrul Söylemez wrote:
>> >> > It is a bug, but some people tolerate it, some don't. What the
>> >> > operating system does here is not called resource management, but
>> >> > fault tolerance. It should be designed not to fail on
>> >> > programming errors.
>> >>
>> >> What a bizarre notion. What happens to the resources of a program
>> >> when the program exits is defined by the operating system. Relying
>> >> on OS-defined behavior in your program is not an error. Performing
>> >> time-wasting activity on abstract grounds of illusory correctness,
>> >> on the other hand, is an error.
>> >
>> > You're showing that you are an irresponsible programmer. C and
>> > Cobol are about the only languages in wide-spread use, which even
>> > allow that kind of carelessness. Modern languages are even designed
>> > to prevent you from being stupid. But obviously you want to be
>> > stupid.
>>
>> What modern languages would those be? I suspect you could not name one
>> such that you are not wrong.
>
> All languages with an automatic garbage collector. There are even
> languages, which implement that "tag stack" I mentioned earlier
> directly, like C# with its 'using' directive.

You're confusing ``storage managed language'' with ``language
which requires all resources to be released when the program
terminates''.

I can think of several storage-managed languages which neglect this
requirement (/and/ do not provide any way for the program to
implement its own cleanup!)

>> > Relying on operating system fault tolerance is wrong and most good
>>
>> It's not fault tolerance but resource management. You are pitifully
>> wrong in your other posting.
>>
>> Relying on this is no more wrong than relying on a TCP/IP stack,
>> graphics display, or DMA transfers.
>
> TCP/IP stack, graphics display and DMA transfers are functionality.
> What you can "resource management" prevents the system from crashing,
> just because some programmers write wrong code. That's not
> functionality, it's fault tolerance.

Yet you advocate garbage collection. Garbage collection can also be
regarded as not storage management, but fault tolerance, which
prevents the system from crashing in the face of ``bad'' programs.

Procewss clean up is a coarsely grained form of garbage collection.
A process has certain private resources (no other process has access
to them). So when a process goes away, those resources become
garbage.

My troll detector is starting to go off at this point;
repeated contradictions like this can only be planted.

== 2 of 8 ==
Date: Wed, Feb 17 2010 12:38 pm
From: ImpalerCore

On Feb 17, 1:53 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-17, Ertugrul Söylemez <e...@ertes.de> wrote:
>
> > What the hell is wrong with freeing resources?  It takes twenty seconds
> > to write the code to do it.  The code itself uses at most one or two
> > seconds to execute and guarantees correctness.
>
> Well, no.
>
> 1.  It doesn't guarantee correctness.  I already provided an example where
> it did not guarantee correctness, because a program could run out of memory
> if it ran long enough, even though at any given point, if it exited, it
> would free everything.
> 2.  It can take a lot more than twenty seconds to write the code to do it.
> 3.  It can take a lot more than one or two seconds to execute, especially
> on slower hardware.
>
> There exist cases where there are good reasons not to do it.  They may be
> specialized cases, they may not be all that common...
>
> Here's the thing.  If you want to argue that it's a good idea, and should be
> assumed as a default strategy and used until someone has a concrete and
> specific reason not to do it, great!  I agree totally.
>
> When you start making blanket assertions, or calling programs which rely on
> a 100% documented and guaranteed aspect of their operating environment
> "incorrect", though, you undermine your position.  The net result is that not
> only are people not persuaded of what you're saying, they're persuaded against
> the general practice of freeing allocated resources, because they conclude
> that the people advocating it are fanatics who don't understand engineering
> tradeoffs.

To me, this argument advocates the practice of not explicitly freeing
allocated resources since

1. Deallocating memory at the 'free' level is slower, and gets worse
the complexity increases.
2. It costs more to code it properly and verify.
3. Many target OS handle this condition out of the box.

Why should using "free" be the default strategy when the OS does it
"better"? Why should I spend hours writing and testing manually
freeing resources at the end of any application, when I can get the
above benefits of letting the OS handle it? (Again, I'm not referring
to avoiding freeing resources at all within the normal run of a
program, just at the end of the application.)

If you started a new project where all the target OS have this
feature, why bother explicitly freeing memory resources at all?

> > Serious programmers won't even argue about this topic.
>
> Does preemptively insulting people for disagreeing with you usually work
> in your culture?  In mine it's often taken to be a sign of lacking persuasive
> arguments.
>
> -s
> --
> Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 3 of 8 ==
Date: Wed, Feb 17 2010 12:41 pm
From: Kaz Kylheku

On 2010-02-17, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-02-17, Ertugrul Söylemez <es@ertes.de> wrote:
>> Serious programmers won't even argue about this topic.
>
> Does preemptively insulting people for disagreeing with you usually work
> in your culture? In mine it's often taken to be a sign of lacking persuasive
> arguments.

Note that ``about this topic'' means either side. This is a
clear ``I am trolling'' signal for the astute readers.

== 4 of 8 ==
Date: Wed, Feb 17 2010 12:55 pm
From: Seebs

On 2010-02-17, ImpalerCore <jadill33@gmail.com> wrote:
> To me, this argument advocates the practice of not explicitly freeing
> allocated resources since

It is intended to advocate the practice of *thinking* about it.

> Why should using "free" be the default strategy when the OS does it
> "better"?

1. It doesn't. For anything which happens more than once during a run,
a memory leak can mean that your program fails from running out of memory
before the OS cleans it up.
2. It is *in general* a good way to make sure you've correctly understood
your design and don't have any fundamental memory-management bugs.

> Why should I spend hours writing and testing manually
> freeing resources at the end of any application, when I can get the
> above benefits of letting the OS handle it? (Again, I'm not referring
> to avoiding freeing resources at all within the normal run of a
> program, just at the end of the application.)

Consistency. If I free things when I'm done with them regardless of
whether I'm done with them for this loop or for this program, my code
will be more consistent and easier to follow.

> If you started a new project where all the target OS have this
> feature, why bother explicitly freeing memory resources at all?

Because the vast majority of my allocations are in processes which occur
repeatedly.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 5 of 8 ==
Date: Wed, Feb 17 2010 12:56 pm
From: Seebs

On 2010-02-17, Kaz Kylheku <kkylheku@gmail.com> wrote:
> On 2010-02-17, Seebs <usenet-nospam@seebs.net> wrote:
>> On 2010-02-17, Ertugrul Söylemez <es@ertes.de> wrote:
>>> Serious programmers won't even argue about this topic.

>> Does preemptively insulting people for disagreeing with you usually work
>> in your culture? In mine it's often taken to be a sign of lacking persuasive
>> arguments.

> Note that ``about this topic'' means either side. This is a
> clear ``I am trolling'' signal for the astute readers.

That could be. With the .de address, I was also thinking it might be that
the choice of preposition wasn't quite idiomatic, since that happens a lot
between German and English.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 6 of 8 ==
Date: Wed, Feb 17 2010 1:23 pm
From: Keith Thompson

Kaz Kylheku <kkylheku@gmail.com> writes:
> On 2010-02-17, Keith Thompson <kst-u@mib.org> wrote:
>> Hyman Rosen <hyrosen@mail.com> writes:
[...]
>>> char *getGlobalFoozleBuffer()
>>> {
>>> static char *buf = calloc(147, 13);
>>> return buf;
>>> }
>>
>> Why is buf static?
>
> Because this is a singleton pattern; each call to this function
> is expected to yield the same object.

I had assumed that calloc() would be called each time
getGlobalFoozleBuffer() is called, and that the above was equivalent
to:

char *getGlobalFoozleBuffer()
{
return calloc(147, 13);
}

But in fact the above isn't even legal in C. The initializer for an
object with static storage duration must be constant (C99 6.7.8p4).

<OT>The rules are are different in C++.</OT>

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 7 of 8 ==
Date: Wed, Feb 17 2010 1:31 pm
From: ike@localhost.claranet.nl (Ike Naar)

In article <JwTen.36395$aU4.17600@newsfe13.iad>,
Hyman Rosen <hyrosen@mail.com> wrote:
>Unless you're very careful, this is an anti-pattern,
>and will cause difficult to diagnose errors for this
>common singleton pattern:
>
> char *getGlobalFoozleBuffer()
> {
> static char *buf = calloc(147, 13);
> return buf;
> }
>
>This is also another example of a sort of memory allocation
>which is not, and need not be, freed by the program before
>it exits.

Your code fragment leaks memory if getGlobalFoozleBuffer() is called
more than once; I thinks this makes more sense:

char *getGlobalFoozleBuffer()
{
static char *buf; /* initially NULL */
if (buf == NULL)
buf = calloc(147, 13);
return buf;
}

== 8 of 8 ==
Date: Wed, Feb 17 2010 1:39 pm
From: ImpalerCore

On Feb 17, 3:55 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-17, ImpalerCore <jadil...@gmail.com> wrote:
>
> > To me, this argument advocates the practice of not explicitly freeing
> > allocated resources since
>
> It is intended to advocate the practice of *thinking* about it.

Well, you've been successful in that aspect.

> > Why should using "free" be the default strategy when the OS does it
> > "better"?
>
> 1.  It doesn't.  For anything which happens more than once during a run,
> a memory leak can mean that your program fails from running out of memory
> before the OS cleans it up.
> 2.  It is *in general* a good way to make sure you've correctly understood
> your design and don't have any fundamental memory-management bugs.

I agree, and I've spent a lot of time trying to verify memory
management correctness, and I still run into little bugs. I just
started testing my library code with an allocator that fails and
returns NULL on some nth iteration, and it has led to several seg
faults and requiring another rethink of my implementation.

> > Why should I spend hours writing and testing manually
> > freeing resources at the end of any application, when I can get the
> > above benefits of letting the OS handle it?  (Again, I'm not referring
> > to avoiding freeing resources at all within the normal run of a
> > program, just at the end of the application.)
>
> Consistency.  If I free things when I'm done with them regardless of
> whether I'm done with them for this loop or for this program, my code
> will be more consistent and easier to follow.
>
> > If you started a new project where all the target OS have this
> > feature, why bother explicitly freeing memory resources at all?
>
> Because the vast majority of my allocations are in processes which occur
> repeatedly.

Do you agree with, as a rule of thumb, that a developer should
implement a manual free of an application to verify correctness, and
if some metric isn't met (shutdown time,lifetime issues), shortcut the
system and let the OS release the resources.

From the tone of some of the other posters, I (probably incorrectly)
perceived that they think that implementing a "manual free" version is
a waste of time given an application with enough complexity.

Best regards,
John D.

> -s
> --
> Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

==============================================================================
TOPIC: Motivation of software professionals
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Feb 17 2010 12:56 pm
From: James Kanze

On Feb 16, 3:33 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-16, James Kanze <james.ka...@gmail.com> wrote:

> > And I tried to use them, and they just didn't stop crashing.
> > Even today, Linux is only gradually approaching the level of the
> > Unixes back then.

> I guess it depends on which unixes, and which Linux. When I
> went from SVR4 Unix to NetBSD, though, I had a LOT less
> downtime.

I've never used NetBSD, but from what I understand, it does
seem like it would have been a lot better than Linux.

Note that the problem is more one of being new. And not having a
decent development process, but that problem was shared by many
commercial OS's as well. Up until the late 1990's, I used Sun
OS 4 professionally. Early Solaris wasn't that great, either.

> > I used vi back then. It didn't have many features, but it was
> > solid. It was also a commercial product. Emacs depended on the
> > version. Some worked, some didn't.

> The version I used (nvi) was nearly-rock-solid. Which is to
> say, I found and reported a bug and it was fixed within a day.
> And I've been using the same version of nvi that I was using
> in 1994 ever since, and I have not encountered a single bug in
> 15 years.

The two aspects are probably connected. Stable software doesn't
change versions that offen.

> >> I used gcc by the mid-90s and it was rock solid, too.
> > G++ was a joke. A real joke until the mid-1990's. It was usual
> > to find more bugs in the compiler than in freshly written code.

> I said gcc, not g++. And while, certainly, it has bugs, so
> has every other compiler I've used. I had less trouble with
> gcc than with sun cc. I used a commercial SVR4 which switched
> to gcc because it was noticably more reliable than the SVR4
> cc.

I believe that gcc was pretty stable by then. But by the early
1990's, we'd moved on the C++. I did one of the compiler
evaluations back then, and I can assure you that g++ was a real
joke.

> > They are for anyone who is open and honest about it. I did
> > compiler evaluations back then, so I know pretty well what I'm
> > talking about. We measured the differences.

> I do not think it is likely that implying that anyone who
> disagrees with you is being dishonest will lead to productive
> discussion. My experiences with free software were apparently
> different from yours -- or perhaps my experiences with
> commercial software were different.

My experiences with commercial software are not universally
positive. But realistically, anytime before the mid-1990's,
most of the free software was simply not acceptable. It didn't
have a good enough process to ensure stability, and was too new
for most of the bugs to have been worked out.

> Whatever the cause, the net result is that by the mid-90s, I
> had a strong preference for free tools and operating systems,
> because they had consistently been more reliable for me.

The turning point was some time in the mid-1990's. When
depending on what you were doing.

--
James Kanze

== 2 of 4 ==
Date: Wed, Feb 17 2010 1:01 pm
From: James Kanze

On Feb 16, 10:26 am, Arved Sandstrom <dces...@hotmail.com> wrote:
> James Kanze wrote:
> > On Feb 14, 4:54 pm, Lew <no...@lewscanon.com> wrote:

[...]
> > And I tried to use them, and they just didn't stop crashing.
> > Even today, Linux is only gradually approaching the level of the
> > Unixes back then.

> [ SNIP ]

> I have to agree with you here. My earliest use of Linux was
> 1993, side by side with IRIX and SunOS. I don't remember
> frequent crashing of Linux but there was no question but that
> the UNIX systems were more stable, more polished and had more
> capability. Granted, everyone back then was throwing Linux on
> old PCs, which probably didn't help, but still...

Today, the problem is that everyone is throwing it on new
PC's:-). Before the drivers for the latest cards are fully
stable. (Other than that, there still seem to be some problems
in XFree, and I've generally had to more or less hack some of
the boot scripts to get them to work.)

With the exception of the problems in XFree, however, I don't
think you can compare them with the commercial offerings.
Solaris always installed like a charm for me, but that was on a
Sun Sparc---the two were literally made for each other, and Sun
made sure that any new Sun hardware would work with Solaris.
Trying to cover generic hardware, including chips that haven't
been invented yet, is a lot more difficult.

--
James Kanze

== 3 of 4 ==
Date: Wed, Feb 17 2010 1:04 pm
From: James Kanze

On Feb 16, 3:28 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-16, James Kanze <james.ka...@gmail.com> wrote:

> > I am. If only because such projects require a larger degree of
> > accountability than free software can offer. I can't see anyone
> > providing free software with contractual penalties for downtime;
> > most of the software I worked on in the 1990's had such
> > penalties.

> I think it may be done occasionally. Certainly, if I had
> contractual penalties for downtime, and my choices were
> Windows or Linux, I'd run free software. :P

I'd use Windows XP before Linux, but frankly... I'd avoid
standard PC's completely: (modern) Solaris on a Sparc, or HP/UX
on HP's PA would be my choices. (Supposing I needed a real
general purpose system. Some of the embedded systems are
probably even more reliable.)

--
James Kanze

== 4 of 4 ==
Date: Wed, Feb 17 2010 1:14 pm
From: James Kanze

On Feb 16, 10:09 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 16 Feb, 03:40, Seebs <usenet-nos...@seebs.net> wrote:

> > On 2010-02-16, James Kanze <james.ka...@gmail.com> wrote:
> > > On Feb 14, 4:56 pm, Seebs <usenet-nos...@seebs.net> wrote:
> > >> On 2010-02-14, James Kanze <james.ka...@gmail.com> wrote:
> > >> > To be really effective, design and code review requires a
> > >> > physical meeting. Depending on the organization of the project,
> > >> > such physical meetings are more or less difficult.

> I've got mixed opinions on this. The real review takes place
> off line. Explanation and discussion of possible solutions (I
> know, a code walthru isn't supposed to consider solutions- a
> daft idea if you ask me [1]) at a meeting.

> Design meeetings can work.

It's always difficult to find the right balance, because people
do vary. What I think is certain is that you do need some time
isolated, to let your ideas jell, and you need some meetings, at
least at either end: brainstorming sessions before really
starting, and code reviews after the code has been written.
Between the two, different people probably have different needs.
A lot of people claim that they're most effective in pair
programming, for example, where as I (and some others I know)
would be much less effective if I couldn't do large parts of the
work more or less in isolation.

--
James Kanze

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en