twitter: comp.lang.c - 25 new messages in 9 topics

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

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: The undefinedness of a common expression.
http://groups.google.com/group/comp.lang.c/t/bdae87d399a9442e?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 27 2010 7:20 am
From: Daniel Giaimo

On 1/26/2010 10:31 PM, Wojtek Lerch wrote:
> "André Gillibert" <MetaEntropy.removeThis@gmail.com> wrote in message
> news:20100127005703.4fe03ef3@fixlaptop.gillibert.homelinux.net...
>> "Wojtek Lerch" <wojtek_l@yahoo.ca> wrote:
>> > <lawrence.jones@siemens.com> wrote in message
>> > news:nff337-gj5.ln1@jones.homeip.net...
>> > > I maintain that you deserve whatever behavior you get when you write
>> > > code like that.
>> >
>> > Why? Becuase the C standard is unclear on what that code does?
>>
>> Yes, if x and y are volatile, the C standard is unclear and existing
>> implementations differ.
>
> And whose fault is that -- the programmer's or the standard's?
>

The programmer's. It is the programmer's job to do things the way the
standard specifies. If a programmer attempts to do something that the
standard is unclear on, then it is the programmer's fault if it
doesn't work the way they expect it to.

--
Dan Giaimo

== 2 of 2 ==
Date: Wed, Jan 27 2010 7:50 am
From: jameskuyper

Wojtek Lerch wrote:
> "André Gillibert" <MetaEntropy.removeThis@gmail.com> wrote in message
> news:20100127005703.4fe03ef3@fixlaptop.gillibert.homelinux.net...
> > "Wojtek Lerch" <wojtek_l@yahoo.ca> wrote:
> > > <lawrence.jones@siemens.com> wrote in message
> > > news:nff337-gj5.ln1@jones.homeip.net...
> > > > I maintain that you deserve whatever behavior you get when you write
> > > > code like that.
> > >
> > > Why? Becuase the C standard is unclear on what that code does?
> >
> > Yes, if x and y are volatile, the C standard is unclear and existing
> > implementations differ.
>
> And whose fault is that -- the programmer's or the standard's?

Both. The standard should not be unclear, and programmers should avoid
writing code that depends upon the precise interpretation of parts of
the standard that are not clear.

==============================================================================
TOPIC: Data relocation (pointer subtraction undefined except within array)
http://groups.google.com/group/comp.lang.c/t/d1b6ec1667df6385?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Jan 27 2010 7:27 am
From: chrisbazley@bigfoot.com

On Dec 31 2009, 4:21 pm, "bartc" <ba...@freeuk.com> wrote:
> <chrisbaz...@bigfoot.com> wrote in message
>
> news:65628adf-f383-414c-a26f-4cc76ccd3f4d@j19g2000yqk.googlegroups.com...
> > Hello,
>
> > I wasted a lot of time yesterday writing some code which manages a
> > collection of strings within a single heap block allocated by a
> > function similar to 'malloc'. A separate array of structs includes
> > members which point to the start of each string. My intention is to
> > replace existing (working) code where each string is held in a
> > separate heap block, to reduce a high turnover of blocks.
>
> > When replacing existing strings with longer strings, or adding strings
> > to the collection, the heap block containing the strings must be
> > extended using a function like 'realloc'. However, 'realloc' may move
> > the base address of the block, which invalidates the pointers to the
> > start of each string. I don't really want to replace all my 'char *'
> > members with 'ptrdiff_t' (offset from start of heap block containing
> > strings) because of the loss of type-safety and additional cost of
> > accessing the strings.
>
> > I thought I could solve my problem by adding a relocation offset to
> > each pointer immediately after calling 'realloc', derived by
> > subtracting the old from the new address of the heap block. However,
> > turning to the appendix of my copy of Kernighan & Ritchie, I
> > discovered - to my dismay - that the result of subtracting one pointer
> > from another is undefined unless both point to objects within the same
> > array.
>
> If you allocate a single block with malloc(), that is effectively a single
> array. It doesn't matter if you then choose to divide it into multiple
> arrays.

I think you misunderstood my problem. I was not doing arithmetic
between pointers to objects within a single block; I was trying to
relocate pointers so that they point to the new location of objects
within a block that has been moved by 'realloc'.

--
Christopher Bazley

== 2 of 3 ==
Date: Wed, Jan 27 2010 8:02 am
From: chrisbazley@bigfoot.com

On Dec 31 2009, 5:04 pm, Eric Sosman <esos...@ieee-dot-org.invalid>
wrote:
> On 12/31/2009 8:52 AM, chrisbaz...@bigfoot.com wrote:
>
> > Hello,
>
> > I wasted a lot of time yesterday writing some code which manages a
> > collection of strings within a single heap block allocated by a
> > function similar to 'malloc'. A separate array of structs includes
> > members which point to the start of each string. My intention is to
> > replace existing (working) code where each string is held in a
> > separate heap block, to reduce a high turnover of blocks.
> >[...]
>
> Others have discussed the problems of after-the-fact
> readjustment of pointers. May I suggest that you might not
> need it?
>
> If the goal is to reduce overhead by holding many small
> strings in one big block, perhaps you could consider allocating
> a second big block when the first is full, leaving the first in
> place and still holding its unmoved strings. If the blocks are
> "large" compared to the per-block overhead, you'd waste only a
> small amount of space -- and you'd completely avoid the dangers
> of pointer-fiddling.
>
> Maybe the data structure you're using isn't amenable to
> this -- but it might be worth a thought or two.

It sounds as though you are suggesting a linked list of large buffers,
each holding multiple strings. Unfortunately I don't think that would
suit my needs because strings are often replaced by other strings of
different length, or deleted entirely. I don't think I would be happy
with memory usage increasing with each modification of one of my
objects-with-associated-strings, even if all that memory could be
recovered (by walking the linked list) upon deletion of the object.

--
Christopher Bazley

== 3 of 3 ==
Date: Wed, Jan 27 2010 10:03 am
From: chrisbazley@bigfoot.com

Thanks to everyone who posted replies (especially Ben, Peter and
Eric); you helped me to organise my thoughts and eventually arrive at
a solution. I feel like I owe an explanation of how I solved my
problem, so here it is...

On Dec 31 2009, 4:19 pm, Seebs <usenet-nos...@seebs.net> wrote:
[snip]
> The two things you might run into are:
>
> 1. Systems in which loading an invalid pointer into an address register
> can page fault even if you don't try to dereference it.

Ah, I wouldn't have thought of that! I am used to the ARM
architecture, where all registers (except the program counter) are
general purpose; the CPU can't tell whether a value is a pointer or
not until it is used as the base address in a load or store
instruction.

> 2. Systems in which pointers to different objects may be in different
> memory regions such that subtraction doesn't work as expected.

Like the BBC Master Series microcomputer, where additional memory (so-
called 'sideways RAM') was paged into the memory map between 0x8000
and 0xC000 in 16 KB chunks.

> Suggestion: If you can handle the overhead, then malloc-copy-adjust-free
> rather than using realloc. In practice, if realloc is changing addresses,
> it MUST be possible to malloc, copy, and then free. However, I am sure
> that if you tried hard enough, you could find some implementation somewhere
> on which there existed M and N such that allocating M bytes and reallocing
> to N succeeded, but trying to allocate M and N bytes simultaneously would
> fail.
>
> I wouldn't worry about it. The canonical thing to do is indeed to do
> the copy/adjust phase yourself in cases like this.

This is closest to the solution that I eventually adopted.

My original idea of shuffling strings around the buffer when a string
is deleted or replaced turned into a nightmare (which is why my
initial implementation was to put each string in a separate heap
block). A single call through my API allows several elements of an
array to be modified in an atomic operation. The strings associated
with some elements may grow, and those associated with others may
shrink. It's basically a sliding heap, but more complex because of the
need for atomicity!

Before any strings could be moved, I needed to calculate the 'peak'
memory usage for the edit about to happen. This may be greater than
the final string buffer requirement, if short strings are replaced by
long strings before short strings are replaced by long strings. I also
felt that I should periodically minimise the string buffer size (e.g.
when in a quiescent state). Every time the string buffer was resized,
I would have needed to traverse the array, relocating every string
pointers.

In the end, I decided that the pain of maintaining my own sliding heap
within a single block just wasn't worth it. Without the guarantee of
contiguous address space from a fixed base address, resizing the
string buffer would likely require its entire content to be copied
(whether implicitly by 'realloc' or explicitly by 'memcpy'). Although
likely to be quicker than copying strings piecemeal using 'strcpy',
that is offset by the fact that some of the strings will be destined
for the scrapheap anyway.

Before editing the array of structs, I now sum the expected change in
string buffer requirement for each array element (e.g. -3 when
replacing "ladder" with "car") and add it to the current buffer size.
This allows me to calculate the required string buffer size without
traversing the whole array twice (unless every element is to be
modified).

I then allocate a new string buffer of exactly the right size and
traverse the array of structs from the beginning, copying each string
from the old buffer to the new buffer, or else replacing it. Rather
than relocating pointers, I get fresh pointers returned from 'strcpy'.
Lastly, I free the old string buffer. Thus, the buffer is never longer
than it needs to be and each edit operation requires only one
'malloc'/'free'.

My performance tests show speed changes of 27% to 27923% relative to
the previous strategy of allocating a separate heap block for each
string!

> Or! You could use ptrdiff_t offsets internally, and provide an API which
> yields a pointer for a given object. This could be as simple as
> #define STR(x) (global_base + x->offset)

Unfortunately, I'm wedded to the idea of using the same struct type on
both sides of an API. The client passes a pointer to an array of this
type, each element of which may contain one or more string pointers.
Internally, my module makes a deep copy of each struct and bundles it
with some internal data.

Requiring the client to pass a string buffer pointer and specify
strings as ptrdiff_t offsets within that buffer would make using my
API more painful. Alternatively, I could store ptrdiff_t value(s) as
part of the internal data associated with each struct, but it would be
messy to keep that synchronised with the struct type definition.

Cheers,
--
Christopher Bazley

==============================================================================
TOPIC: problems with logic operations within loops
http://groups.google.com/group/comp.lang.c/t/9228b4a6f1c5f9e3?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Jan 27 2010 7:30 am
From: "Joachim Schmitz"

jacob navia wrote:
> Richard Heathfield a écrit :
>>
>> Yes. Most C compilers, however, are not C99 compilers.
>>
>
> This is yet another lie. Please name one compiler that doesn't
> accept // comments by default.

c89 on NonStop Kernel. And no, there is no c99 nor c95 available on that
platform.

There is, however, a switch to enable C++ style
comments, -Wallow_cpluplus_comments
There is also a switch -Wc99lite to ebable some, but by far not all c99
features.

> And no, putting gcc in pedantic mode doesn't count.
>
> This is standard C, and it is widely implemented. I bet you can't
> even name one compiler that doesn't accept those comments.

Bet lost.

Bye, Jojo

== 2 of 3 ==
Date: Wed, Jan 27 2010 7:51 am
From: jacob navia

Joachim Schmitz a écrit :
> jacob navia wrote:
>> Richard Heathfield a écrit :
>>>
>>> Yes. Most C compilers, however, are not C99 compilers.
>>>
>>
>> This is yet another lie. Please name one compiler that doesn't
>> accept // comments by default.
>
> c89 on NonStop Kernel. And no, there is no c99 nor c95 available on that
> platform.
>
> There is, however, a switch to enable C++ style comments,
> -Wallow_cpluplus_comments
> There is also a switch -Wc99lite to ebable some, but by far not all c99
> features.
>

Well, you see?

// comments are an universal feature in all C compilers, please let's stop
this stupidity. It is the most widely used C99 feature.

== 3 of 3 ==
Date: Wed, Jan 27 2010 9:41 am
From: Richard Heathfield

jacob navia wrote:

<snip>

> // comments are an universal feature in all C compilers,

Clearly not. You have already been shown some examples.

> please let's stop this stupidity.

Be my guest.

> It is the most widely used C99 feature.

Possibly, but that's not the point.

--
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

==============================================================================
TOPIC: What happened to TR 18037: Embedded C?
http://groups.google.com/group/comp.lang.c/t/b25c577790b4707b?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 27 2010 8:02 am
From: Philipp Klaus Krause

Walter Banks schrieb:
>
> Philipp Klaus Krause wrote:
>
>>> The latest draft is N1275 fall 2007
>> Do you know why the _Accum types only have 4 integral bits? Most
>> implementations of fixed-point math I've seen rather tends toward having
>> more integral than fractional bits or are at least balanced.
>
> There is quite a bit of implementation flexibility to support
> both hardware and application requirements. Support for
> processors with a MAC is typically the _Accum size is
> MAC accumulator size sometimes rounded up to a byte size.
>
> For embedded systems implementations and non MAC based
> processors, most implementations, the accum is either the fract
> size plus a byte or double the fract size.
>
> One of the appendix's in 18037 covers some of the issues
> for selecting the implementation accum size. There is a strong
> suggestion that the fract size and the fract size of the accum
> be the same but the integral part of the accum is quite flexible.

And even that appendix has at least 8 integral bits for every type of
fixed-point number.
So far I've only seen two real-world fixed-point implementations: a
s15.16 in the pic backends of sdcc and a s9.6 one I wrote myself (I
needed at least 9 integral bits and wanted to myximize precision under
that condition).

Philipp

== 2 of 2 ==
Date: Wed, Jan 27 2010 8:44 am
From: Walter Banks

Philipp Klaus Krause wrote:

> Walter Banks schrieb:
> > One of the appendix's in 18037 covers some of the issues
> > for selecting the implementation accum size. There is a strong
> > suggestion that the fract size and the fract size of the accum
> > be the same but the integral part of the accum is quite flexible.
>
> And even that appendix has at least 8 integral bits for every type of
> fixed-point number.
> So far I've only seen two real-world fixed-point implementations: a
> s15.16 in the pic backends of sdcc and a s9.6 one I wrote myself (I
> needed at least 9 integral bits and wanted to myximize precision under
> that condition).

I use 8:16 a lot in many embedded systems projects on 8 bit
micros and when the integral part needs to be larger than 8 bits
generally switch to an int. I store a lot of application constants
in fixed point.

The engine controllers use a 24bit processor with fractional math
capability that we use 24:24 accums.

Regards,

Walter..
--
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 4 ==
Date: Wed, Jan 27 2010 8:42 am
From: Robert Latest

jacob navia wrote:
> There is option (c), that lcc-win proposes: use the garbage collector!
> This allows to write overloaded operators that allocate memory for
> new constructs without having any memory leaks in temporary expressions.

And your point is...?

If you need a certain functionality in a C program, you have several
options:

1) Link against a third-party library that implements what you need
2) Implement it yourself
3) Switch to a different language that has the feature built-in
4) Invent a C-like language that has the desired features and write
a full-fledged implementation
5) Convince the Standard Committee to have the desired functionality
in the next release of the C Standard

You seem to be hell-bent on options 4) and 5) while ordinary mortals are
perfectly happy with 1) thru 3).

So again, what's your point?

robert

== 2 of 4 ==
Date: Wed, Jan 27 2010 8:46 am
From: Robert Latest

["Followup-To:" header set to comp.lang.c.]
jacob navia wrote:

> lcc-win proposes a garbage collector in its standard distribution.
> All the problems above are solved with a gc

Why insist on "lcc-win" when the garbage collector can be linked into
any C program on any hosted implementation?

robert

== 3 of 4 ==
Date: Wed, Jan 27 2010 9:13 am
From: jacob navia

Robert Latest a écrit :
> ["Followup-To:" header set to comp.lang.c.]
> jacob navia wrote:
>
>> lcc-win proposes a garbage collector in its standard distribution.
>> All the problems above are solved with a gc
>
> Why insist on "lcc-win" when the garbage collector can be linked into
> any C program on any hosted implementation?
>
> robert

Because I am the author of that software. I recompiled the work of
Mr Boehm's with lcc-win in 2003 and added it to the standard distribution in 2004.

As far as I know, it was the only C compiler that included a GC in the
standard distribution at that time. I have been promoting the use of a
GC in this group since several years, since I consider it a very good solution
(but not a panacea) in many situations, for instance in this case: functional
style programming.

There are maybe other ports of the collector under windows, but they
are tied to cygwin, as far as I know. The collector compiled with lcc-win
can be used (since it is a dll) with other runtimes, watcom/microsoft, whatever.

Those are some of the reasons I mention my work here.

== 4 of 4 ==
Date: Wed, Jan 27 2010 9:16 am
From: jacob navia

Robert Latest a écrit :
> jacob navia wrote:
>> There is option (c), that lcc-win proposes: use the garbage collector!
>> This allows to write overloaded operators that allocate memory for
>> new constructs without having any memory leaks in temporary expressions.
>
> And your point is...?
>
> If you need a certain functionality in a C program, you have several
> options:
>
> 1) Link against a third-party library that implements what you need
> 2) Implement it yourself
> 3) Switch to a different language that has the feature built-in
> 4) Invent a C-like language that has the desired features and write
> a full-fledged implementation
> 5) Convince the Standard Committee to have the desired functionality
> in the next release of the C Standard
>
> You seem to be hell-bent on options 4) and 5) while ordinary mortals are
> perfectly happy with 1) thru 3).
>
> So again, what's your point?
>
> robert

As you have perfectly seen, Mr "Latest", I am following options (4) and (5).

I am not an ordinary mortal?

I do not think so.

I just suspect that you do not like my work, that's all.

==============================================================================
TOPIC: Substrings and so on
http://groups.google.com/group/comp.lang.c/t/2e9f3f2a5244b8a2?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 27 2010 8:52 am
From: Keith Thompson

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
[...]
> no casting won't help you. Use sscanf() or strtod() (or one of its
> friends)

The problem with using the *scanf() family for numeric conversion is
that the behavior on overflow is undefined. The strto*() functions
don't have this problem.

--
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"

==============================================================================
TOPIC: ๑۩๑۩๑all kinds of brand shoes, t-shirt , handbags for sale by paypal
http://groups.google.com/group/comp.lang.c/t/78b829a63cf68f93?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 27 2010 9:12 am
From: hero

๑۩๑۩๑all kinds of brand shoes, t-shirt , handbags for sale by paypal

we engaged in wholesale 4us shoes, (www.ecyaya.com)
wholesale A&F Jacket, (www.ecyaya.com)(www.ecyaya.com)
adicolor%20man%20shoes,
wholesale Adidas NBA, Adidas 35TH(M), Adidas Y3, Adidas(M),
(www.ecyaya.com)
wholesale AF1 25TH LOW(M&W), AF1 (W), AF1 Fusions AJ9, AF1 Fusions AJ12
(M), AF1 Fusions AJ, AF T-Shirt Women Short, Affliction Jean,
(www.ecyaya.com)
wholesale AirMAX 1, AirMax 87(M), AirMax 89, AirMax 90&360, AirMax 90
(M), AirMax 91, AirMax 95(M), AirMax 97(M), AirMax 360(M), AirMax 2003
(M), AirMax 2009(M), AirMax (95&360), AirMax LTD(M), AirMax TN1(M),
AirMax TN10, AJ2 4 5 6 Fusions(M), AirMax TN10, (www.ecyaya.com)
wholesale AJ3 4 5 6 Fusions(W), AJ3 5 15 Fusions, AJ10 Fusions AJ12,
AJ11 Fusions AJ23, (www.ecyaya.com)
wholesale Amauri Shoes, Armani Belt, (www.ecyaya.com)
wholesale Bape 1HT, BAPE Jean , Bape Colourful, Bape Shoes,
(www.ecyaya.com)
wholesale BBC Jean Man, (www.ecyaya.com)
wholesale Bikkembergs Shoes, (www.ecyaya.com)
wholesale BOSS Belt, (www.ecyaya.com)
wholesale Bureiy Swimming, (www.ecyaya.com)
wholesale Jordan, Nike shox, Nike NZ, (www.ecyaya.com)
wholesale Chanel Belt, Chanel Boots, Chanel Handbags, Chanel Sandal,
Chanel Shoes Women, Chanel Swimming, Chloe Handbags,(www.ecyaya.com)
wholesale Coach Handbag, COACH Sandal,COACH Shoes Man, COACH Shoes
Women, (www.ecyaya.com)
COOGI Jean Man, CROWN HOLDER Jean Man,(www.ecyaya.com)
wholesale D&B Handbag, D&G Belt, D&G Handbags,D&G Jean Man, D&G Shoes
Man Low, D&G Watch, DG T-Shirt Short, (www.ecyaya.com)
wholesale DIESEL Jean Man, Dior Goggle, ECKO T-Shirt, ED Hardy
Handbags, ED HARDY Jean Man, ED Hardy Swimming, ED Hardy T-Shirt Man
Short, (www.ecyaya.com)
wholesale Evisu Jean Man, Fendi Handbag, (www.ecyaya.com)
G-STAR Jean Man, G-STAR T-Shirt Short, (www.ecyaya.com)
wholesale Gucci Goggle, Gucci Handbags, GUCCI Sandal, GUCCI Jean Man,
GUCCI Shoes Man Low, Gucci Swimming, Jordan 1(M), Jordan 3.5, Jordan
4, Jordan 5, Jordan 7, Jordan 8, Jordan 11, Jordan 9, wholesale Jordan
13, Jordan 21, Jordan 24, Jordan DMP, Jordan Six Rings, Jordan Ture,
(www.ecyaya.com)
wholesale Juicy Handbag, (www.ecyaya.com)
wholesale JUST cavalli Jean Man, (www.ecyaya.com)
wholesale Lacoste T-Shirt Man Short, (www.ecyaya.com)
wholesale LEVIS Jean Man, LV Belt, LV Goggle, LV Handbags, LV
Swimming, (www.ecyaya.com)
wholesale M+4 Jean Man, Miu Miu, (www.ecyaya.com)
wholesale Nike RIFT(M), Okley Goggle, (www.ecyaya.com)
wholesale POLO T-Shirt Man Short, (www.ecyaya.com)
wholesale Prada Handbags, PRADA Jean Man, Prada Shoes Man Low, Prada
Watch, (www.ecyaya.com)
wholesale Puma Man Shoes, RMC Jean Man, ROCK Jean Man,
(www.ecyaya.com)
wholesale Shox NZ(M), Shox R2 Man, Shox R3(M), Shox R4(M), Shox R5,
Shox TL3(M), Shox Turob, (www.ecyaya.com)
wholesale Touse Swimming, TR Jean Man, TRUE RELIG Jean Man,
(www.ecyaya.com)
wholesale UGG 30ht 5728, UGG 5825 AAA, UGG Boot 5818, Versace Goggle,
VERSACE Jean Man etc.(www.ecyaya.com)

== 2 of 2 ==
Date: Wed, Jan 27 2010 9:14 am
From: hero

๑۩๑۩๑all kinds of brand shoes, t-shirt , handbags for sale by paypal

==============================================================================
TOPIC: What is on topic here
http://groups.google.com/group/comp.lang.c/t/a91a80117d377f7f?hl=en
==============================================================================

== 1 of 6 ==
Date: Wed, Jan 27 2010 9:40 am
From: Anand Hariharan

On Jan 25, 2:48 pm, Anand Hariharan <mailto.anand.hariha...@gmail.com>
wrote:
> On Jan 23, 1:57 pm, Seebs <usenet-nos...@seebs.net> wrote:
> > There are a handful of common examples of things which are currently
> > generally regarded as being off-topic. I'll review those.
> > 8. make and makefile issues.
> (...)
> > Other people have thoughts on this?
>
> Jacob's wording relating to make was "makefile problems related to the
> building of a c program". I fully support that.
>
> Header file and source code organisation should be (is?) very much
> topical, and 'make' pertaining to C is fundamentally tied to how
> source files depend upon one another.
>

Am replying to my own post to address what Peter and Keith responded.

Idiosyncracies of textual file inclusion by the preprocessor and
forward declarations are very much topical in comp.lang.c. These are
not OS dependent, and such features are indeed present in other
languages. And these are fundamentally related to build and
dependency issues that arise in a project.

A programming language (especially a minimalist one such as C) is
seldom useful in by itself. It is useful in terms of what library
features come with it, what tool-sets facilitate working with it and
the community that uses/supports it. E.g., Perl, for all the flak it
gets for its syntax, would not be the language that it is but for all
these characteristics.

- Anand

== 2 of 6 ==
Date: Wed, Jan 27 2010 10:02 am
From: spinoza1111

On Jan 27, 3:22 am, c...@tiac.net (Richard Harter) wrote:
> On Tue, 26 Jan 2010 17:17:32 +0000, Richard Heathfield
>
> <r...@see.sig.invalid> wrote:
>
> BTW, congratulations on not taking the bait of He Who Barks At
> The Moon. I understand the temptation, but responding to him is
> worse than pointless.

I am not "he who barks at the moon". My name is Edward G. Nilges, and
I've published on computer topics since 1976 including "Build Your
Own .Net Language and Compiler" (Apress, 2004). I've worked for Bell-
Northern Research and Princeton and at the latter I was privileged to
assist John "A Beautiful Mind" Nash. However, I've left the
programming field because it was increasingly dominated by people who
engage in this kind of behavior: talking about people behind their
back...and patting themselves on the back for not "feeding the troll"
when in fact they know goddamn well they are.

How stupid can you get, Harter? I undertook not to interfere with the
above discussion and thanked Heathfield et al. for not responding to
the series of posts on Navia's original topic. I was in fact quite
relieved that they did not, because their responses would show their
usual inabilities at reading comprehension. But now you're trying to
take advantage of this by having your laffs, and you don't realize
that anyone with dignity and self-respect will respond to your shit.

This behavior is both extremely stupid (it's like "searching" for
spinoza1111 in comp.risks postings, each of which has a consistent
form and digests several articles, which wasn't only stupid but also
dishonest) and petty in the office politics register, it seems there
is a type of person who so loves the backstabbing and gossip at the
office that this faggot has to do it online for fun.

Nicholas G. Carr showed in 2003 that "IT Doesn't Matter" any more in
an article in the Harvard Business Review (http://www.nytimes.com/
2003/05/04/business/yourmoney/04TECH.html discusses his results: the
article itself must be purchased). That is, it's a pure cost center,
which must be maintained merely because all other companies "do" IT,
but there is when IT applications mature no reason for its being any
more correct or efficient than the mean, just staffed with
mediocrities guaranteed not to rock the boat and to stab each other in
the back rather than ask for meaningful work.

These Troglodytes, these homunculi, don't program anymore: what's the
point for their companies if there is no competitive advantage?
Instead they find bugs and send them on to somewhat higher, if
absurdly overspecialized, homunculi, or to India where real
programmers paid in rupees do the real work.

So, they have a lot of free time: to reminisce about C89 and to spin
fantasies about the One Great Perfect C in the Sky and the secrets of
the void, like mad monks. And to backstab and disrespect their fellow
men.

Fuck you, asshole.
>
> Richard Harter, c...@tiac.nethttp://home.tiac.net/~cri,http://www.varinoma.com
> Infinity is one of those things that keep philosophers busy when they
> could be more profitably spending their time weeding their garden.

== 3 of 6 ==
Date: Wed, Jan 27 2010 10:06 am
From: spinoza1111

On Jan 27, 3:37 am, Keith Thompson <ks...@mib.org> wrote:
> c...@tiac.net (Richard Harter) writes:
>
> [...]
>
> > Topicality is a fiction. There is no consensus; it is not even
> > clear that the "topicality" represents a majority view. All that
> > can be legitimately said is that the "topicality police" make the
> > most noise.
>
> I disagree; I find that it's the self-proclaimed trolls who make the

And you, Kiki, would do well to abide by George Orwell's essay
"Politics and the English Language": "(i) Never use a metaphor,
simile, or other figure of speech which you are used to seeing in
print." You've seen phrases such as "self-proclaimed philosopher" or
"self-styled intellectual" in print and you've clumsily tried to use
it: but in the most sensible definition, "trolls" are people who post
beliefs that they don't really have in order to "get a rise": these
types of trolls won't say "I'm a troll". Nor will people like me
labeled "trolls" by thugs who can't comprehend sentences of complexity
> small n.

> most noise.
>
> --
> Keith Thompson (The_Other_Keith) ks...@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"

== 4 of 6 ==
Date: Wed, Jan 27 2010 10:08 am
From: spinoza1111

On Jan 27, 5:55 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> Richard Harter wrote:
> > On Tue, 26 Jan 2010 17:17:32 +0000, Richard Heathfield
> > <r...@see.sig.invalid> wrote:
>
> > BTW, congratulations on not taking the bait of He Who Barks At
> > The Moon. I understand the temptation, but responding to him is
> > worse than pointless.
>
> Thank you, not so much for the congratulation as for the understanding.
>
> In other news, still no sign of a writ. Perhaps it got lost in the post.

And there you go. You said you wouldn't "feed the troll" where in your
small mind I'm a "troll" and you've done so. I wouldn't worry. The
Great Writ shall come in good time. No man knoweth the day nor hour.
>
> --
> 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 6 ==
Date: Wed, Jan 27 2010 10:08 am
From: spinoza1111

On Jan 27, 6:30 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> Richard Harter wrote:
> > On Tue, 26 Jan 2010 21:55:10 +0000, Richard Heathfield
> > <r...@see.sig.invalid> wrote:
>
> >> Richard Harter wrote:
> >>> On Tue, 26 Jan 2010 17:17:32 +0000, Richard Heathfield
> >>> <r...@see.sig.invalid> wrote:
>
> >>> BTW, congratulations on not taking the bait of He Who Barks At
> >>> The Moon. I understand the temptation, but responding to him is
> >>> worse than pointless.
> >> Thank you, not so much for the congratulation as for the understanding.
>
> >> In other news, still no sign of a writ. Perhaps it got lost in the post.
>
> > Do you think, perhaps, that the writ was never written?
>
> I think, perhaps, that I have as much reason to believe it was (or will
> be) written as I have reason to believe any other claim of HWBATM.

What an asshole.
>
> --
> 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

== 6 of 6 ==
Date: Wed, Jan 27 2010 10:10 am
From: spinoza1111

On Jan 27, 4:10 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 26 Jan, 16:39, Charlton Wilbur <cwil...@chromatico.net> wrote:
>
>
>
>
>
> > >>>>> "A" == Albert <albert.xtheunkno...@gmail.com> writes:
>
> > A> Suppose the OP is called A and any replier B. If A posts a
> > A> *topic* that B thinks should be in another newsgroup, B *can*
> > A> tell A that he doesn't like that and can (optionally) suggest a
> > A> more appropriate newsgroup.
>
> > A> This way, everyone gets ideas about where stuff should be posted
> > A> given the year, month, who are "regulars" at a certain point of
> > A> time, etc.
>
> > And what happens then is that C, D, and E answer A's question, but only
> > C gets it right; B points out that D and E got it wrong, and suggests
> > the other newsgroup again; F and G snipe at B. Then H responds with
> > seven posts of pseudopsychological babble (which just about everyone
> > ignores), and I comes in a week later to claim that B has an
> > autism-spectrum disorder.
>
> better grammer would be "and I come in a week later..."
>
> When do we start using greek letters?

When we master English orthography?

==============================================================================
TOPIC: Dik Winter
http://groups.google.com/group/comp.lang.c/t/a47de783b183f3e7?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 27 2010 9:41 am
From: spinoza1111

On Jan 10, 7:53 am, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <hib2ph$3f...@news.eternal-september.org>,
>
>
>
>
>
> Richard <rgrd...@gmail.com> wrote:
> >rich...@cogsci.ed.ac.uk (Richard Tobin) writes:
>
> >> In article <hiavjm$ci...@news.eternal-september.org>,
> >> Richard <rgrd...@gmail.com> wrote:
> >>>"Flash Gordon" actually added something else to his "how sad" reply -
> >>>in order to , I couldnt believe it, keep it on topic ...... I was
> >>>shocked even for this group.
>
> >> Give it a rest.
>
> >> -- Richard
>
> >And your point is?
>
> >Thats twice now in a thread about someones untimely and sad demise that
> >the automatons in this group have actually mentioned topicality. Give
> >THAT a rest and then come and talk to me.
>
> As you can see, automatons don't have any human sensitivity.

I expressed my sadness about his passing elsewhere upon hearing of
Dik's passing but this seems the best place for adding my note
belatedly. Dik had many interesting things to say about the history of
Algol and I will miss his contributions very much.

== 2 of 2 ==
Date: Wed, Jan 27 2010 10:01 am
From: santosh

Ben Bacarisse wrote:
> I have just heard the sad news that Dik Winter died on the 28th of
> December, a couple of months before he was due to retire.
> http://www.cwi.nl/en/2009/1044/Dik-Winter
>
> Since he was a frequent poster here, I though you'd all like to know.
> My apologies if posts like this are not appropriate.

Being back to Usenet very recently after a long gap, I'd have missed
this thread altogether, but for a recent post.

Very sad news indeed. Dik Winter's posts, usually rich in historical
details, were always very interesting, being a relative newcomer to
the computing field myself.

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

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

twitter

Wednesday, January 27, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts