twitter: comp.lang.c - 26 new messages in 11 topics

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

comp.lang.c@googlegroups.com

Today's topics:

* How should I test for a null pointer? - 9 messages, 8 authors
http://groups.google.com/group/comp.lang.c/t/ac6fdf22358cde1a?hl=en
* Knowing the implementation, are all undefined behaviours become
implementation-defined behaviours? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/4f8b56b26018cf4e?hl=en
* Implementing strstr - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/a3fe05ab352d5774?hl=en
* usage of size_t - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
* Has thought been given given to a cleaned up C? Possibly called C+. - 2
messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
* c99 multidimensional arrays contiguous? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/3a16b9b33cb0cdd0?hl=en
* Idiotic programming style edicts - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
* 16:32 far pointers in OpenWatcom C/C++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/4728dadef590aafe?hl=en
* 2 Challenges for the C Programmer in U... - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/2d55f4e5b7f533b6?hl=en
* Containers: The iterator object - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/662f02788cfa0c97?hl=en
* Public/private in C - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/85a22d944f826cec?hl=en

==============================================================================
TOPIC: How should I test for a null pointer?
http://groups.google.com/group/comp.lang.c/t/ac6fdf22358cde1a?hl=en
==============================================================================

== 1 of 9 ==
Date: Mon, Mar 22 2010 8:51 am
From: Seebs

On 2010-03-22, Keith Thompson <kst-u@mib.org> wrote:
> I read it as "if not ptr" or "if not pointer". I have to mentally
> redefine the usual meaning of "not" for this to make sense. It's not
> a real problem, but personally I prefer "if (ptr == NULL)".

Oddly, that fits my sense of "not", so it doesn't require redefinition to
me. I don't see a cognitive difference between:
x = count(kitties);
if (x) {
}

and
x = ptr_to_kitties();
if (x) {
}

They're both doing something if there were kitties.

-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 9 ==
Date: Mon, Mar 22 2010 8:55 am
From: Julienne Walker

On Mar 22, 11:20 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Mar 22, 11:19 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> > Anand Hariharan <mailto.anand.hariha...@gmail.com> writes:
> > > On Mar 21, 3:08 am, markhob...@hotpop.donottypethisbit.com (Mark
> > > Hobley) wrote:
> > >> How should I test for a null pointer within a C program?
>
> > >> Presumably the following will work:
>
> > > [snip]
>
> > >> if ( !ptr ) { dosomething }
>
> > > My follow-up question to the group is, how do you read the above line
> > > of code in your head (or out loud)?
>
> > > I find "if not non-null pointer" quite awkward.
>
> > FWIW: "if not ptr" where I usually vocalise "ptr" as "pointer".
>
> Why not spell it out as I do consistently in my "convoluted" code
> after my pre-Szymonyi Hungarian?

Why spell it out when the abbreviation is commonly known? In the case
of a subjective and supremely trivial matter, it's best to simply let
people do what they want and focus on more important issues. Pick your
battles unless you have nothing better to do than fight for fun.

For questions like the OP's, the best you can do is collect a number
of personal opinions and reach no conclusion. As such, I'll add to the
noise with my preference of being explicit when the object isn't
strictly boolean:

if ( ptr == NULL ) { /* ... */ }

With "ptr" as a generic placeholder for a more informative name. For
boolean objects it's a different matter:

if ( !done && is_valid ) { /* ... */ }

== 3 of 9 ==
Date: Mon, Mar 22 2010 9:20 am
From: Anand Hariharan

On Mar 22, 10:29 am, Keith Thompson <ks...@mib.org> wrote:
> Anand Hariharan <mailto.anand.hariha...@gmail.com> writes:
> > On Mar 21, 3:08 am, markhob...@hotpop.donottypethisbit.com (Mark
> > Hobley) wrote:
> >> How should I test for a null pointer within a C program?
>
> >> Presumably the following will work:
>
> > [snip]
>
> >> if ( !ptr ) { dosomething }
>
> > My follow-up question to the group is, how do you read the above line
> > of code in your head (or out loud)?
>
> > I find "if not non-null pointer" quite awkward.
>
> I read it as "if not ptr" or "if not pointer". I have to mentally
> redefine the usual meaning of "not" for this to make sense. It's not
> a real problem, but personally I prefer "if (ptr == NULL)".
>

I suppose that sounds very similar to "if naught pointer" or "if
nought pointer" which is close enough to the actual semantics?

== 4 of 9 ==
Date: Mon, Mar 22 2010 9:24 am
From: Dr Malcolm McLean

On 22 Mar, 15:55, Julienne Walker <happyfro...@hotmail.com> wrote:
>
> Why spell it out when the abbreviation is commonly known?
>
Quite a few coding standrards say that "ptr" is an unacceptable name
for a pointer.

Now imagine you want to do, the following, write a qsort() replacement
that passes a pointer to the comparision function (as well as the two
data pointers), in order to allow for context-dependent comparisions
without using a global.
I'd write that as

void qsort2(void *data, int N, size_t s, int (*compfunc)(const void
*e1, const void *e2, void *ptr), void *ptr);

However "ptr" is banned. So "pointer" is an acceptable substitute.

== 5 of 9 ==
Date: Mon, Mar 22 2010 9:35 am
From: Ben Pfaff

Dr Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> Quite a few coding standrards say that "ptr" is an unacceptable name
> for a pointer.
[...]
> However "ptr" is banned. So "pointer" is an acceptable substitute.

It's hard for me to imagine why "ptr" would be banned and not
"pointer". It's quite clear that "ptr" stands for "pointer" and
it is a few characters shorter.
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman

== 6 of 9 ==
Date: Mon, Mar 22 2010 9:55 am
From: Stephen Sprunk

On 22 Mar 2010 09:46, Nick Keighley wrote:
> On 21 Mar, 18:43, Nick <3-nos...@temporary-address.org.uk> wrote:
>> Hamiral <hami...@hamham.com> writes:
>>> Mark Hobley wrote:
>>>> How should I test for a null pointer within a C program?
>>
>>>> Presumably the following will work:
>>
>>>> if ( ptr == NULL ) { dosomething }
>>>> if ( !ptr ) { dosomething }
>>
>>> if(!ptr) is very common, and everybody should undestand it.
>>> But I personnally prefer being the most clear I can, so I always use
>>> if(ptr == NULL) -- and in general I never use if(!anything)

The "if (ptr == NULL)" construction looks excessively verbose to me,
though I wouldn't bother changing it if I ran across it--unless the
project style guide said it was wrong, of course. I always write "if
(!ptr)" myself, and I've never had anyone reject it in a code review;
even if one doesn't like that form, one has to admit it's idiomatic.

>>> Using NULL shows a bit more that you're dealing with pointers.

True, but IMHO the pointer-ness of the variable should be obvious from
either naming or context; if not, you need more than little tricks like
that to fix the code.

>> ! works well in some constructions:
>>
>> "if(!done)", for example, reads as "if not done".
>
> I'm fine with using booleans this way, just not pointers
>
> if (!ptr), doesn't read as "if not pointer". I suppose I could read
> it as "if null-pointer"

I actually do pronounce "if (!ptr)" as "if not pointer"; I've seen the
construction so many thousands of times it makes sense to me when said
that way. Such is the power of following common idioms.

One could also read it as "if not valid pointer", but that's not
technically correct since ptr could be indeterminate, i.e. neither valid
nor null. Boolean operators tend to generate such false dichotomies all
over the place.

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

== 7 of 9 ==
Date: Mon, Mar 22 2010 10:16 am
From: William Ahern

Hamiral <hamiral@hamham.com> wrote:
> Nick wrote:
> > Hamiral <hamiral@hamham.com> writes:
> >
> >> Mark Hobley wrote:
> >>> How should I test for a null pointer within a C program?
> >>>
> >>> Presumably the following will work:
> >>>
> >>> if ( ptr == NULL ) { dosomething }
> >>> if ( !ptr ) { dosomething }
> >> if(!ptr) is very common, and everybody should undestand it.
> >> But I personnally prefer being the most clear I can, so I always use
> >> if(ptr == NULL) -- and in general I never use if(!anything)
> >> Using NULL shows a bit more that you're dealing with pointers.
> >
> > ! works well in some constructions:
> >
> > "if(!done)", for example, reads as "if not done".

> Of course, I never test booleans like if(somebool == TRUE)...
> I thought that was evident enough that people doing this just didn't
> understand boolean expressions ;)

But as pointed out elsethread (ptr) is equivalent to (ptr != 0), which is a
boolean expression. An if statement condition is a boolean expression by
definition.

I'll sometimes use (ptr == NULL) or like, but not because `ptr' is a
pointer; rather because `ptr' is a pointer _and_ it's a distinction that for
some exceptional reason should be highlighted. But in general it doesn't
need to be highlighted. In both the literal and practical context of an if
condition the semantic is boolean anyhow. Object types don't usually matter.

OTOH, I'll make use of all three idioms for integral zero--0, 0x00, and
'\0'--because my code often mixes use of zero-terminated and binary strings,
and I personally appreciate the subtle signaling when bouncing around
different areas of my projects. So, I'm not averse to certain coding
affectations. I just don't think the alternatives are more clear than plain
0. To the contrary, they sometimes give me pause, which is one of the effects
I want. If I don't want that effect, I don't do that.

== 8 of 9 ==
Date: Mon, Mar 22 2010 11:36 am
From: Seebs

On 2010-03-22, Julienne Walker <happyfrosty@hotmail.com> wrote:
> On Mar 22, 11:20 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>> Why not spell it out as I do consistently in my "convoluted" code
>> after my pre-Szymonyi Hungarian?

(I just had to quote that, because WTF. "Hungarian" is known as that
because it was named after Szymonyi.)

> Why spell it out when the abbreviation is commonly known?

Significantly:

* Human readers make more mistakes on longer words.
* Abbreviations help people read quickly and accurately.

So there's a lot to be said for picking consistent abbreviations.
The loop index "i" is not just some kind of short-cut; it improves
reliability and legibility of code.

> In the case
> of a subjective and supremely trivial matter, it's best to simply let
> people do what they want and focus on more important issues. Pick your
> battles unless you have nothing better to do than fight for fun.

Consider to whom you were responding.

== 9 of 9 ==
Date: Mon, Mar 22 2010 12:09 pm
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <slrnhqfe90.bht.usenet-nospam@guild.seebs.net>, Seebs <usenet-nospam@seebs.net> writes:
> On 2010-03-22, Julienne Walker <happyfrosty@hotmail.com> wrote:
>> On Mar 22, 11:20 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
>>> Why not spell it out as I do consistently in my "convoluted" code
>>> after my pre-Szymonyi Hungarian?
>
> (I just had to quote that, because WTF. "Hungarian" is known as that
> because it was named after Szymonyi.)

(Hungarian guy here.) That's actually "Simonyi". It's pronounced
"scimogni" if you read Italian, or "shimonyi" in English, the "ny" being
pronounced like in Banyan VINES.

http://en.wikipedia.org/wiki/Charles_Simonyi
http://en.wikipedia.org/wiki/Hungarian_ny

lacos
(on topic as usual)

==============================================================================
TOPIC: Knowing the implementation, are all undefined behaviours become
implementation-defined behaviours?
http://groups.google.com/group/comp.lang.c/t/4f8b56b26018cf4e?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Mar 22 2010 9:01 am
From: Seebs

On 2010-03-22, Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> wrote:
> Just for the record it wasn't my intention to make such an allegation.
> Perhaps a prediction that you would reach a new conclusion upon
> consideration of new facts.

Ahh, fair enough. I may or may not. I'm still waffling.

> I have to admit I don't like spurious warnings either. However there
> are (at least) two different modes for acting on warning messages, and
> I think that difference may be relevant here. One mode I might call
> "lint like", where the warnings are taken as informational. The other
> mode is (for lack of a better term) "-Werror like", where warnings
> cause compilation to fail. I almost always use -Werror (and use lint
> only rarely).

In the stuff I have to keep building reliably for our build system, I use
-Werror during development, and then disable it for release. We end up
with a lot of code that has to be compiled by an unpredictable variety of
customer compilers, whereupon it becomes essentially impossible to
avoid SOME version of gcc yielding warnings.

> Of course this means the set of warnings reported must
> be at least somewhat selective, since there certainly are warning
> conditions that are more about style than substance. I find it helps
> to have the -Werror warnings that are reported be conservative (ie,
> possibly false positives, but never false negatives), for two reasons.
> One, if the compiler has a hard time figuring it out, people sometimes
> do also, and even if I can see that a warning isn't strictly necessary
> I don't want to assume all my co-workers can also (and also vice
> versa).

For something like -Wuninitialized (or however they spell it), I am not
at all confident that there exists a way to be certain of never missing
such a case short of printing the message unconditionally.

In the case of something like the "optimize out null pointer tests when
they're irrelevant", it gets fussier. That said, Code Sourcery gave us
a really good example of a reason for which doing that silently might be
desireable.

> Two, like it or not, when routinely using -Werror to identify
> and fail on certain warning conditions, people tend not to think so
> much about those particular conditions, expecting the compiler to
> catch their oversights. So it seems better to have warning conditions
> be "hard" rather than "soft", with the understanding that we're
> talking about using -Werror and that the set of warnings being tested
> is not everything but a specifically chosen set. So at the end of
> day I still grumble to myself about spurious warnings, but I think
> it's better for overall quality and productivity to suffer these
> once in a while to get the benefits of having hard-edged warning
> conditions.

You know, thinking about this, it occurs to me that there's probably a key
difference between your workflow and mine.

I'm usually looking at cases where people have a large pool of open source
software to compile. They either don't want to change it, or are prohibited
by some term in some policy somewhere from changing it. They want it to
compile without hassle. They are not looking to fix the code; they're okay
with taking the risk that something will blow up, in many cases, but they
still want to compile it without failures or spurious warnings.

For an extreme example, we had people who were (for reasons I never quite
understood) committed to using an old version of openssh which relied on
calling function pointers through the wrong interfaces. On PPC, gcc smacked
this behavior down hard... So the ultimate customer requirement was:
* This MUST NOT produce a warning/diagnostic.
* It's fine if the resulting code segfaults instantly.

(Why? Because it was in a segment of code they didn't use.)

>> Ahh! I see. I think we were talking about two separate kinds of cases.
>> One is warnings about possibly-uninitialized values, where I favor gcc's
>> policy of trying for the most accurate warnings it can, even though this
>> means it sometimes omits a warning.

> Right, I was talking about a different situation, and that was
> probably the most important point of what I was saying.

Yup.

>> I would not object in the least to a warning flag that, say, requests warnings
>> whenever gcc optimizes a test out because it's concluded that a pointer is
>> dereferenced, and therefore non-null. I would even think it should probably
>> be on by default, because honestly, I can't think of a case where I would
>> intentionally write code subject to such an optimization.

> I probably could construct such cases if I put my mind to it,
> perhaps even "natural" ones (I'm thinking macro calls here),
> but I agree, nine times out of ten it's just bad thinking.

Macro calls and inlined functions. The latter is the case that I think
makes it particularly persuasive -- you don't want to get warnings for
that.

And I don't think the optimization occurs at a level where it can tell
you whether there's macros or inlined functions involved.

> It certainly seems so. As predicted, I thought you
> would see my point, once you saw my point. :)

The first rule of tautology club is the first rule of tautology club.

==============================================================================
TOPIC: Implementing strstr
http://groups.google.com/group/comp.lang.c/t/a3fe05ab352d5774?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Mar 22 2010 9:10 am
From: Colonel Harlan Sanders

On Mon, 22 Mar 2010 08:27:35 -0700 (PDT), spinoza1111
<spinoza1111@yahoo.com> wrote:

>Yeah, guys who looked like Herb Schildt (who's a big hairy guy,
>photographed on a motorcycle in his first book) used to give guys like
>Dweebach swirlies, noogies, and Indian burns, and guys like Dweebach
>have been nursing the hurt ever since. And confronting their bullying
>is NOT itself bullying.

So, now you're characterizing your hero Schildt as a bully, as part
of your increasingly ridiculous campaign to ... ah, yes, preserve
Schildt's good name.

You've disappeared up your own anus completely now. Good riddance.

== 2 of 3 ==
Date: Mon, Mar 22 2010 9:23 am
From: spinoza1111

On Mar 23, 12:10 am, Colonel Harlan Sanders <Har...@kfc.com> wrote:
> On Mon, 22 Mar 2010 08:27:35 -0700 (PDT),spinoza1111
>
> <spinoza1...@yahoo.com> wrote:
> >Yeah, guys who looked like Herb Schildt (who's a big hairy guy,
> >photographed on a motorcycle in his first book) used to give guys like
> >Dweebach swirlies, noogies, and Indian burns, and guys like Dweebach
> >have been nursing the hurt ever since. And confronting their bullying
> >is NOT itself bullying.
>
> So, now you're characterizing your hero Schildt as a bully, as part
> of your increasingly ridiculous campaign to ... ah, yes, preserve
> Schildt's good name.
>
> You've disappeared up your own anus completely now. Good riddance.

Learn to read. I didn't say that Schildt bullied Dweebach. I said,
Rufus, that perhaps guys who looked like Schildt (a big hairy guy)
bullied Dweebach when he was widdle and he's been nursing the hurt at
heart.

Colonel Harlan Sanders
Ist ein anders
He can't read
A clue doth he need.

And at this point, having shown patience and collegiality with
Dweebach, I will indeed make a joke out of his patronym. I attempted
to contact him politely last January; he said he deleted the mail
unread. He has called me a moron and insane, which causes thugs and
genuinely insane people like you and Bill Reid to post. OK, gloves
off.

== 3 of 3 ==
Date: Mon, Mar 22 2010 11:39 am
From: Seebs

On 2010-03-22, Colonel Harlan Sanders <Harlan@kfc.com> wrote:
> On Mon, 22 Mar 2010 08:27:35 -0700 (PDT), spinoza1111
><spinoza1111@yahoo.com> wrote:
>>Yeah, guys who looked like Herb Schildt (who's a big hairy guy,
>>photographed on a motorcycle in his first book) used to give guys like
>>Dweebach swirlies, noogies, and Indian burns, and guys like Dweebach
>>have been nursing the hurt ever since. And confronting their bullying
>>is NOT itself bullying.

> So, now you're characterizing your hero Schildt as a bully, as part
> of your increasingly ridiculous campaign to ... ah, yes, preserve
> Schildt's good name.

This is getting surreal.

The beautiful thing is that Nilges doesn't seem to realize that if,
in fact, Schildt was a bully, and people were confronting the bully by
accurately pointing out flaws in his work this would, by Nilges' own
statements, NOT be a kind of bullying.

It's weird. You sometimes almost get the impression he believes that the
stuff he makes up has some kind of external referent. I think that, as
he imagines things that make him feel victorious, he just sort of assumes
them to be true, rather than imagined. Very weird.

==============================================================================
TOPIC: usage of size_t
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Mar 22 2010 9:16 am
From: pete

Tim Rentsch wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> On 2 Mar, 23:52, Tim Rentsch <t...@x-alumni2.alumni.caltech.edu>
>> wrote:
>>> Why not just this:
>>>
>>> for(i=N-1; i != -1; i--)
>>>
>>> which works for any integer type, either signed or
>>> unsigned, whose conversion rank is at least that of int.
>>>
>> i is an unsigned type, and we're terminating the loop when it doesn't
>> equal -1.
>>
>> Anyone who doesn't know C like the back of his hand will curse you for
>> writing code like that.
>
> They won't curse me, because I don't write such code. Among
> other things, it transgresses the warning criteria for comparing
> signed and unsigned operands. My point was that it is more
> robust, in terms of possible changes in type, to omit the cast
> and compare against just -1.
>
> A better way to write the condition is 'i + 1 != 0', which avoids
> both the signed/unsigned comparison warning and the above criticism
> about loop termination. Furthermore, on writing this for loop as
>
> for(i=N-1; i + 1 != 0; i--)
>
> it is immediately obvious that it could be rewritten as
>
> i = N;
> while(--i + 1 != 0)
>
> or more simply just as
>
> i = N;
> while(i-- != 0)
>
> which is how it should have been written in the first
> place.

That's my preferred way to write that also.

--
pete

== 2 of 2 ==
Date: Mon, Mar 22 2010 10:25 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <kfnr5ncs7x4.fsf@x-alumni2.alumni.caltech.edu>,
Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:

> In particular, _computing_ an out-of-range value in a signed
> type is undefined behavior, but _converting_ an out-of-range
> value to a signed type is implmentation-defined behavior
> (or an ID signal as you mention).

Thanks!
lacos

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Mar 22 2010 9:18 am
From: Dag-Erling Smørgrav

Richard Delorme <abulmo@nospam.fr> writes:
> Everything is already upside down: Modern C compilers uses precompiled
> header and does inter-procedural optimization during the linkage.

No. Precompiled headers are not object files, they're in a format
developed for, and used exclusively by, the parser. Link-time
optimization operates on the output of previous stages, not the other
way around. Information still flows from the preprocessor through the
parser, code generator and assembler to the linker. Each stage still
operates either on the output of the stage that precedes it or on the
output from a previous instantiation of the same stage.

DES
--
Dag-Erling Smørgrav - des@des.no
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 2 of 2 ==
Date: Mon, Mar 22 2010 10:23 am
From: "bartc"

"Dag-Erling Smørgrav" <des@des.no> wrote in message
news:clcm-20100322-0002@plethora.net...
> Richard Delorme <abulmo@nospam.fr> writes:
>> Everything is already upside down: Modern C compilers uses precompiled
>> header and does inter-procedural optimization during the linkage.
>
> No. Precompiled headers are not object files, they're in a format
> developed for, and used exclusively by, the parser. Link-time
> optimization operates on the output of previous stages, not the other
> way around. Information still flows from the preprocessor through the
> parser, code generator and assembler to the linker. Each stage still
> operates either on the output of the stage that precedes it or on the
> output from a previous instantiation of the same stage.

These proposals are just to make life easier.

What's your objection to that? That you don't think it can be done? Well
working from object or library files I don't think will work, but there are
other ways.

(At this moment, I'm writing code in a language that, like C, requires all
shared function definitions in a file, to be duplicated as declarations in a
separate header file. It is a complete PITA.)

--
Bartc

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

==============================================================================
TOPIC: c99 multidimensional arrays contiguous?
http://groups.google.com/group/comp.lang.c/t/3a16b9b33cb0cdd0?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Mar 22 2010 9:21 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <87ljdkwyql.fsf@kilospaz.fatphil.org>, Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Seebs <usenet-nospam@seebs.net> writes:
>> On 2010-03-20, Luca Forlizzi <luca.forlizzi@gmail.com> wrote:
>>> On 17 Mar, 23:01, Seebs <usenet-nos...@seebs.net> wrote:
>>>> a is an array of 10 arrays of ints. The integers in each array are
>>>> necessarily contiguous, and the arrays are necessarily contiguous, so
>>>> it's going to point to a region containing 100 integers. If you derive
>>>> a pointer from a, it is a pointer into that whole object.
>>
>>> This conclusion is clear and logical, but is it really deducible from
>>> the standard?
>>
>> Yes.
>>
>> sizeof(<type> [10]) == sizeof(<type>) * 10
>
> I thought that this was loopholed a few months ago. IIRC, All that is
> required explicitly is that (the normative part is to be interpreted
> such that):
> sizeof(<type>[10])/sizeof(<type>) = 10
> where of course division truncates towards zero.
>
>> There's no room for any padding.
>
> less than sizeof(<type>) trailing padding would be permitted, as
> the rounding down would make the division in the example yield
> the correct count.
>
> Of course, this is bizarre; but I suspect that it's available as a
> plugin module for the DS9000.
>
> I'm also sure that within the last 6 months at least one member
> of the C standardisation committee has indicated that what you
> say was the committee's intention (I'm sure Larry was one).

X-News: ludens comp.lang.c.moderated:25727
From: "Clive D. W. Feather" <clive@davros.org>
Subject: Re: [comp.lang.c.moderated] Does "sizeof array" equal "nel * sizeof
Date: Wed, 13 Jan 2010 16:02:02 -0600 (CST)
Message-ID: <clcm-20100113-0006@plethora.net>

X-News: ludens comp.lang.c.moderated:25755
From: "Clive D. W. Feather" <clive@davros.org>
Subject: Re: [comp.lang.c.moderated] Does "sizeof array" equal "nel * sizeof
Date: Wed, 20 Jan 2010 15:26:17 -0600 (CST)
Message-ID: <clcm-20100120-0001@plethora.net>

I think.

lacos

==============================================================================
TOPIC: Idiotic programming style edicts
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Mar 22 2010 10:51 am
From: "Charlie Gibbs"

In article <He-dnW3mZ6obUDjWnZ2dnUVZ8l1i4p2d@bt.com>,
rjh@see.sig.invalid (Richard Heathfield) writes:

> jmfbahciv wrote:
>
>> spinoza1111 wrote:
>>
>>> On Mar 18, 9:19 pm, jmfbahciv <jmfbahciv@aol> wrote:
>>>
><snip>
>>>
>>>> Are you nuts?
>
> He can't be, because he says he isn't, and he should know, right?
>
>>> No, just that rarity: a competent programmer (the best one in this
>>> newsgroup, probably)
>>
>> Now I know you have a 99% reality filter.
>>
>>> who's literate.
>>
>> Wrong. there are more capable people in a.f.c.
>
> There are more capable people in
> alt.2eggs.sausage.beans.tomatoes.2toast.largetea.cheerslove

Have you got anything without Spam in it?

--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

== 2 of 2 ==
Date: Mon, Mar 22 2010 10:34 am
From: StevePratt

idiot programming edict ... mid 1980s ... some PHB read about
"structured programming" and stated that no one was to use GO TO in
COBOL programs.

I get handed a program to debug - it seems that it no longer works -
and they give it to me just to have a "new set of eyes."

I barely glanced at the house keeping routines... PERFORM INIT_READ,
PERFORM REPORT_HEADING, and so on. I do spend a long time following
the code referenced by PERFORM MAIN_LINE. But nothing makes sense.
What I am looking at is NOT what the program is doing...

So I finally have to put some displays in the code and follow
along ...

Turns out that because they can no longer use GO TO, some one replaced
the GO TO INIT_READ with a PERFORM, but control NEVER CAME BACK.
sheesh!

==============================================================================
TOPIC: 16:32 far pointers in OpenWatcom C/C++
http://groups.google.com/group/comp.lang.c/t/4728dadef590aafe?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Mar 22 2010 10:51 am
From: "1022 guy"

Please stop crossposting to alt.sys.pdp10

==============================================================================
TOPIC: 2 Challenges for the C Programmer in U...
http://groups.google.com/group/comp.lang.c/t/2d55f4e5b7f533b6?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Mar 22 2010 10:53 am
From: Branimir Maksimovic

On Sun, 21 Mar 2010 23:29:40 -0700 (PDT)
Chinmay S <2.6kilohertz@gmail.com> wrote:

>
> Here's the Mystery Spiral?? Can U code it in C??...
> http://2600hertz.wordpress.com/2010/03/20/the-mystery-spiral/
>

I remember this had as exercise in high school back in 1986'

Greets

--
http://maxa.homedns.org/

Sometimes online sometimes not

==============================================================================
TOPIC: Containers: The iterator object
http://groups.google.com/group/comp.lang.c/t/662f02788cfa0c97?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Mar 22 2010 11:27 am
From: Ian Collins

On 03/23/10 03:12 AM, Andrew Poelstra wrote:
> On 2010-03-22, Ian Collins<ian-news@hotmail.com> wrote:
>> On 03/22/10 10:44 PM, jacob navia wrote:
>>> Ian Collins a écrit :
>>>> On 03/22/10 10:19 AM, jacob navia wrote:
>>>>> The iterator is still "valid" but will always return NULL. It just
>>>>> doesn't matter.
>>>>
>>>> I though returning NULL indicated that the iterator is at the end of
>>>> the container?
>>>>
>>>
>>> Actually it will call the currently defined error function with the
>>> error "CONTAINER_ERROR_OBJECT_CHANGED". If that function returns (and
>>> doesn't abort the program) the iterator returns NULL.
>>
>> Then I think that's wrong. It is one reason why I said it would be a
>> nightmare defining the operations that do and don't invalidate an iterator.
>>
>
> I think that as far as modifying lists while iterators are active
> goes, you are simply Not Supposed To Do That. Jacob is trying to
> make sure that if you do, something consistent will happen, even
> if that's something potentially confusing.

Fair enough.

--
Ian Collins

== 2 of 2 ==
Date: Mon, Mar 22 2010 11:54 am
From: Andrew Poelstra

On 2010-03-22, Ian Collins <ian-news@hotmail.com> wrote:
> On 03/23/10 03:12 AM, Andrew Poelstra wrote:
>> On 2010-03-22, Ian Collins<ian-news@hotmail.com> wrote:
>>> On 03/22/10 10:44 PM, jacob navia wrote:
>>>> Ian Collins a écrit :
>>>>> On 03/22/10 10:19 AM, jacob navia wrote:
>>>>>> The iterator is still "valid" but will always return NULL. It just
>>>>>> doesn't matter.
>>>>>
>>>>> I though returning NULL indicated that the iterator is at the end of
>>>>> the container?
>>>>>
>>>>
>>>> Actually it will call the currently defined error function with the
>>>> error "CONTAINER_ERROR_OBJECT_CHANGED". If that function returns (and
>>>> doesn't abort the program) the iterator returns NULL.
>>>
>>> Then I think that's wrong. It is one reason why I said it would be a
>>> nightmare defining the operations that do and don't invalidate an iterator.
>>>
>>
>> I think that as far as modifying lists while iterators are active
>> goes, you are simply Not Supposed To Do That. Jacob is trying to
>> make sure that if you do, something consistent will happen, even
>> if that's something potentially confusing.
>
> Fair enough.
>

Having said that, I just realized that since doing this is
(maybe) a programming error, there should be a flag in the
iterator that can be checked with assert().

--
Andrew Poelstra
http://www.wpsoftware.net/andrew

==============================================================================
TOPIC: Public/private in C
http://groups.google.com/group/comp.lang.c/t/85a22d944f826cec?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Mar 22 2010 11:57 am
From: jacob navia

ImpalerCore a écrit :

> Personally I think implementing some public/private separation is
> outside the scope of C. Grafting this OO paradigm into C is purely
> arbitrary at best, confusing and complex at worst. C wants people to
> get their hands dirty, and doesn't do a whole lot to protect them.
>

Well, as you may have noticed, I proposed a common iterator object for
iterating through ANY container in my library. Obviously that object
can't be a SINGLE type, it must be several since it must have the specific
knowledge of each container, AND it must offer a COMMON interface, so user
code is independent of the container.

It is not just "a matter of protecting people from themselves", it is
just that is impossible to make a COMMON type for all container iterators
if each iterator exposes its interface.

The solution is then, to define a common interface with a few
function pointers that is shared by all containers. User code uses that
interface

typedef struct _iterator {
void (*Getnext)(structb_iterator *);
// Some other public function pointers
char private[]; // Document that this is a variable length structure
} Iterator;

In the file of the container implementation (say list.c) I
define

typedef struct tagListIterator {
Iterator it;
// Private fields follow
List *list;
unsigned timestamp;
// etc
} ListIterator;

Now, I can define

static void *GetNext(Iterator *it)
{
ListIterator *li = (ListIterator *)it;

// And now I can use the private fields
// in this implementation.
}

The advantage of this is that I can EXTEND a public structure with private
parts, something similar to simple inheritance in C.

> Again, you say a pure C solution is MUCH better, but I haven't seen a
> really cool use-case that says "Yeah, I want to try it out!".

When you write a library, it is very handy since it allows to present a common
interface for a set of different objects

> If I
> wanted to make something private in C, I'd just give the "private"
> members a hideously long name so that most people will just be annoyed/
> bored to type it out and use the "public" parts ;)
>
> Best regards,
> John D.

It is not so much a "private" vs public stuff but it is a thing of
interfacing different objects of different types through a common interface.

== 2 of 2 ==
Date: Mon, Mar 22 2010 12:06 pm
From: Branimir Maksimovic

On Mon, 22 Mar 2010 19:57:43 +0100
jacob navia <jacob@nospam.org> wrote:

> ImpalerCore a écrit :
>
> > Personally I think implementing some public/private separation is
> > outside the scope of C. Grafting this OO paradigm into C is purely
> > arbitrary at best, confusing and complex at worst. C wants people
> > to get their hands dirty, and doesn't do a whole lot to protect
> > them.
> >
>
> Well, as you may have noticed, I proposed a common iterator object for
> iterating through ANY container in my library. Obviously that object
> can't be a SINGLE type, it must be several since it must have the
> specific knowledge of each container, AND it must offer a COMMON
> interface, so user code is independent of the container.
Well, that's not good. Better implement it through macros as
in c++. Heterogeneous iterators and containers are not
that useful. Os just make macro with specified type for
only one type of container which holds certain type,
and you are set up.
Most powerful feature of C++ are templates (type checked macros).
Just IMO. I looked at java containers and found them not
efficient and useful as C++ one macro based, not inheritance
based. Good thing with C++ iterator is that it mimics pointers,
so generic algorithm can work both on eg vector and plain array.
I suggest that you examine C++ CTL and think in that direction
eg macros.

Greets!

--
http://maxa.homedns.org/

Sometimes online sometimes not

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

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

Monday, March 22, 2010

comp.lang.c - 26 new messages in 11 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts