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

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

comp.lang.c@googlegroups.com

Today's topics:

* Experiment: functional concepts in C - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
* The C FAQ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/b75c0ae09abf3345?hl=en
* Efficency and the standard library - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
* OLE - link or embed? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/2ac616c404485234?hl=en

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

== 1 of 1 ==
Date: Thurs, Feb 18 2010 11:17 pm
From: Ertugrul Söylemez

Seebs <usenet-nospam@seebs.net> wrote:

> On 2010-02-16, Ertugrul Söylemez <es@ertes.de> 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.
>
> But it's not necessarily a programming error to let the operating
> system deallocate resources. It'd be a programming error if that were
> contrary to the documented behavior of the OS. Otherwise, it may well
> be intentional and well-considered.

I think, if it's intentional and well-considered, the compiler should
optimize it away. The compiler is a much safer layer for such
optimizations. If the call to 'free' is placed before a 'return' in the
main function and the main function is not called recursively, just
ignore the call (if it's safe to ignore on the target platform).

I don't know to what extent compilers like GCC implement such
optimizations. Probably to none at all. The problem should be fixed at
the right place. Writing correct code should never be a problem.

> > If a program launches several worker threads and then daemonizes,
> > the operating system generally loses track of the relations.
>
> On unix-like stuff, as long as they are actually *threads*, it usually
> doesn't.

Well, sure, but you still have to kill the threads. The operating
system is not fault tolerant here.

> >> It turns out, though, that marking the few megabytes a process used
> >> to have as "no longer in use" is much, much, cheaper than having
> >> the process try to walk through a ton of complicated data
> >> structures.
>
> > In times, where you measure processor cycles in GHz and available
> > memory in GiB and where the complexity of applications gets huge,
> > it's very dangerous to go with program exiting (!) performance. In
> > general you will prefer correctness and predictability over a
> > slightly faster process exit.
>
> I'm not convinced. There are a lot of programs which are, by design,
> run EXTREMELY often.

Of course, but you don't expect those programs to allocate millions of
blocks anyway. If they do, they can't run that often anyway. =)

> > Remember we're not talking about in-program performance here. We
> > are talking about program shutdown. Also even walking a data
> > structure with millions of branches takes less than a second on
> > today's machines.
>
> I do a lot of work on a build system. In the course of a single run
> of the build system, there are programs that get run upwards of a
> hundred thousand times. (Say, the shell.) In that case, I think it
> makes a great deal of sense to think very carefully about performance
> of startup and exit.

That's a good point. I agree that there can be places, where it's
appropriate not to free memory, but that shouldn't be decided by
application programmers, but by compiler programmers. Then it would use
the semantics of the operating system without having to write wrong
code.

> Which is why it's useful to know what the operating system's designed
> semantics are. One could easily imagine an operating system where a
> particular device could only accept full-block writes of, say, 512
> bytes. However, we don't then say that it is a "programming error" to
> ever write to any device except in 512-byte blocks...

That's not the same thing. Not freeing memory doesn't change the
program's behaviour semantically.

Greets
Ertugrul

--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/

==============================================================================
TOPIC: The C FAQ
http://groups.google.com/group/comp.lang.c/t/b75c0ae09abf3345?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 11:23 pm
From: Nick <3-nospam@temporary-address.org.uk>

jacob navia <jacob@spamsink.net> writes:

> Seebs a écrit :
>> On 2010-02-12, jacob navia <jacob@nospam.org> wrote:
>>> Linux is even more fragmented that the different Unix flavors at that time.
>>
>> I wrote a hunk of code which has one meaningful #ifdef in it, which is
>> working on every Linux system we know of currently available.
>
> First bet:
>
> It doesn't use any GUI
>
> Second bet:
>
> It doesn't use any sound/video/multimedia
>
> Third bet:
>
> It doesn't use any graphics, or mouse
>
> Obviously, THEN... it is portable. But it would be portable to
> Mac/windows/whatever too without much pain.

So what. Apart from a few specialist niche programs like operating
systems and web browsers nobody needs to use old-fashioned things like
that any more. That's all last millennium stuff.

How much GUI, sound or mouse interaction do you think the programmers of
recent hits like Facebook or Twitter have had to do, eh?

Nick, only half tongue in cheek.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

==============================================================================
TOPIC: Efficency and the standard library
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 18 2010 11:24 pm
From: spinoza1111

On Feb 19, 12:23 am, Julienne Walker <happyfro...@hotmail.com> wrote:
> On Feb 18, 10:51 am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
> > <snip>
>
> We'll have to agree to disagree then. Your technical points are valid
> in context, but your personality poisons any chance of having a good
> debate with you. Any technical discussion inevitably devolves into
> veiled insults, condescension, attacks on "corporate behavior",
> attacks on individuals, enabling your crusade against Richard
> Heathfield, and poetry when you have nothing useful left to say (in my
> opinion).

Good poetry, too. I taught myself how since I teach creative writing,
from the Norton Anthology and John Lennard's The Poetry Handbook. It
comes in handy in these newsgroups since like my programming skills,
nobody can even come close:

There is a fine Lady named Julienne
Who feels not a little frustracienne
Owing to spinoza's replies:
They make her give vent to Sighs,
That discombobulated Lady, named Julienne

Julienne, in civil discourse, it is not an insult to demur. In the
corporation, for a very good reason that low-level people in
corporations (which all data processing people are) are almost never
given resources by the CEO class to do what needs to be done, a
Leninist rule is applied that cuts civil discourse and demurral off at
arbitrary times. It is understandable that this results in a general
wound, and wounded spirits.

But I simply refuse to acknowledge that here, where no corporate
Leninism need cut off discussion unless people have internalized
corporate slavery, it is insulting to maintain a position with vigor.

What's insulting are people like Richard Heathfield who can't read
code and seizes upon trivia such as malloc.h in order to waste my
time, while enabling bullying. Or Keith Thompson, a zany, who thinks
he can count my errors while not reading my posts, in his sleep as it
were. Or Peter Seebach, who calls me, an Apress colleague of his, a
"moron" to third parties in a way that would get him punched out in a
social event by a real man.

The cowardice of these people is matched by their narcissism in which
they make the stupidest possible errors while expecting forgiveness,
while creating here a permanent record of uncalled for attacks on
professional credibility.

So no, dear lady, I am not insulting you.
>
> Honestly, I'm tired of talking to a brick wall. Let me know when
> you're ready to take me seriously and we may actually be able to chat
> in a civil manner.
>
> > And don't presume even to say that I've "insulted" your gender. That
> > is an utter falsehood. I have not patronized nor talked down to you in
> > the slightest. I am instead arguing for a position: that only an
> > incompetent would have presented a linked list that copies
> > unpredictable data into the nodes. This has nothing to do with gender.
>
> You're in no position to tell me not to defend myself when I feel I'm
> being "bullied" by a "thug", since you're so adamant about taking that
> right for yourself at every turn.

If questioning your conclusions politely and urbanely is bullying you,
then you have a strange definition of bullying. If you were my
supervisor and ordered me to use Richard's technique for creating a
linked list, I'd air my objections briefly, and then do it your way.
But here I am under no such obligation.

== 2 of 2 ==
Date: Thurs, Feb 18 2010 11:48 pm
From: Malcolm McLean

On Feb 19, 9:24 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
>What's insulting are people like Richard Heathfield who can't read
>code and seizes upon trivia such as malloc.h in order to waste my
>time, while enabling bullying.
>
So I write code using malloc.h. As it turns out, my compiler uses
alloc.h. It takes all of a second to hit the backspace and delete the
"m".
But what happens when we shop the code. It refuses to compile. So
someone who knows C edits it. But that means its got to go into a
different version. Then it hops to machine that takes malloc.h. So its
now in version 3.
The someone finds a bug with the code. He thinks, "obviously, this is
version 3, whilst we were shipped version 1. So let's test the code
with version 1." So he digs out version 1, recompiles, same bug. OK,
the bug was in the original version. As a matter of routine he diffs
the code. Version 1 and version 3 are identical. So maybe what he
thought was version 3 wasn't the real version 3. So he's on the phone,
talking to a guy who left the company who made the original version 2,
trying to find out what went on.
Eventually it will be sorted. But that's the sort of thing that
happens when you have tiny glitches in code.

==============================================================================
TOPIC: OLE - link or embed?
http://groups.google.com/group/comp.lang.c/t/2ac616c404485234?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 11:36 pm
From: Malcolm McLean

On Feb 19, 6:10 am, ImpalerCore <jadil...@gmail.com> wrote:
> I'm not completely opposed to calling it vector, but at the moment I think
> that array is a better name.
>
A vector is a 1d array
A matrix is a 2d array
An array is a N-dimensional array (including a vector or a matrix).

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

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