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: decoding a declaration
http://groups.google.com/group/comp.lang.c/t/259df4a3d0342511?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Mar 3 2010 11:34 pm
From: David Thompson

On Tue, 16 Feb 2010 21:28:25 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

> "t" <t@t.com> writes:
>
> > 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?
>
> Yup. That's it.
>
> > Or am I missing something? Which would be a good book
> > to understand how to decode such declarations?
>
> I don't know of a book, but you seem to have the hang of it. You read
> inside out from the name (respecting brackets), moving left in
> preference to moving right.
>
Other way; array and function to the right must be taken before
pointer (or C++ reference) to the left.
Overridden by en_GB brackets = en_US parentheses, to be clear.

== 2 of 4 ==
Date: Thurs, Mar 4 2010 1:16 am
From: ram@zedat.fu-berlin.de (Stefan Ram)

David Thompson <dave.thompson2@verizon.net> writes:
>Other way; array and function to the right must be taken before
>pointer (or C++ reference) to the left.

Yes, and these are just the same precedence rules as for
expressions. Therefore, earlier in this thread, I suggested
mentally translating it to an assertion about the type of an
expression. Someone who already knows the precedence rules
for expressions, does not have to learn any additional
precendence rule for declarations.

When people learn latin or french, they learn literally
several ten thousands words and declension rules, so it
might not be asked too much that a C programmer learns
the priorities of one or two dozens of operators.

== 3 of 4 ==
Date: Thurs, Mar 4 2010 5:12 am
From: Ben Bacarisse

David Thompson <dave.thompson2@verizon.net> writes:

> On Tue, 16 Feb 2010 21:28:25 +0000, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>> "t" <t@t.com> writes:
>>
>> > 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?
>>
>> Yup. That's it.
>>
>> > Or am I missing something? Which would be a good book
>> > to understand how to decode such declarations?
>>
>> I don't know of a book, but you seem to have the hang of it. You read
>> inside out from the name (respecting brackets), moving left in
>> preference to moving right.
>>
> Other way;

Would you believe I get left and right confused? Extraordinary but
true. I usually pause and check multiple times when I write either
but even then this can happen. I don't confuse the /directions/ its
is their, to me, arbitrary names that cause the trouble!

--
Ben.

== 4 of 4 ==
Date: Thurs, Mar 4 2010 5:28 am
From: ram@zedat.fu-berlin.de (Stefan Ram)

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>is their, to me, arbitrary names that cause the trouble!

The names are not arbitrary.

Look at the word »Left«.

The »L« of »Left« is a horizontal rule (bar), like »_«.

But which side of the rule is left?

There's a vertical mark on the /left/ side of the rule: »L«.

And, where in the word »Left« is the »L« located?

On the /left/ side of the word.

And what happens, when you write »left« and »right« in
alphabetical order?

left right

When you then read this, the word »left« is left and
the word »right« is right.

So it all comes out right. (Even in this sentence, the
word »right« is in the rightmost position.)

==============================================================================
TOPIC: fixing compile warnings
http://groups.google.com/group/comp.lang.c/t/41e53e9bb82de6ec?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 4 2010 1:05 am
From: ike@localhost.claranet.nl (Ike Naar)

In article <b58c4b16-78cd-422d-ae74-139f7798c926@p3g2000pra.googlegroups.com>,
deadpickle <deadpickle@gmail.com> wrote:
>Thanks for the reply.
>Now I get a segfault. Is there a way to print the line causing the
>segfault (aka traceback in fortran)?
>
> [snip]
>
>#include "ogr_api.h"
>#include "ogr_srs_api.h"
>#include "stdio.h"
>int main()
>{
> //~ variable declaration
> char *source, *target;
> [snip]
> OSRNewSpatialReference(target);

This is not correct; target is uninitialized and has an
indeterminate value; here your program goes off the rails.
Read the documentation for the OSRNewSpatialReference(target) function;
My guess is that the above statement should be

target = OSRNewSpatialReference(NULL);

==============================================================================
TOPIC: ¤¤¤ 2010 Prada handbags get low price wholesale (http://www.rijing-
trade.com) <paypal payment>
http://groups.google.com/group/comp.lang.c/t/fde11df0163253e6?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 4 2010 1:25 am
From: "www.fjrjtrade.com"

Cheap wholesale handbags

Cheap wholesale purse

Cheap wholesale Prada handbag

cheap wholesale Prada purse

Cheap wholesale AAA True Leather handbag and purse

Cheap wholesale AAA True Leather Prada handbag

http://www.rijing-trade.com

==============================================================================
TOPIC: LV GUCCI Umbrella Bedsheet Cheap Wholesale from www.vipchinatrade.com
http://groups.google.com/group/comp.lang.c/t/a4a17d11e757adbd?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 4 2010 1:35 am
From: yoyo

LV Umbrella,Gucci Umbrella :
http://www.vipchinatrade.com/category.php?id=2122

LV Bedsheet, 6 sets, Gucci bedsheet:
http://www.vipchinatrade.com/category.php?id=2121

wholesale free shipping, paypal payment, 100% cotton for bedsheet

website: http://www.vipchinatrade.com

==============================================================================
TOPIC: Is there a better way to achieve this ?
http://groups.google.com/group/comp.lang.c/t/dd4de60290d2834a?hl=en
==============================================================================

== 1 of 9 ==
Date: Thurs, Mar 4 2010 5:18 am
From: Ben Bacarisse

James Dow Allen <jdallen2000@yahoo.com> writes:

> On Mar 4, 8:01 am, "christian.bau" <christian....@cbau.wanadoo.co.uk>
> wrote:
>> Addition of unsigned numbers is well-defined by the C Standard for any
>> input values; if the mathematical sum of a and b is greater than
>> UINT_MAX then the result is the mathematical sum (a + b - (UINT_MAX +
>> 1)), which can easily be shown to be less than b in all cases (and
>> also less than a).
>
> I've not worked on a one's-complement machine since before there
> was a C language, but I wonder how they work here. Perhaps
> UINT_MAX on such a machine is *two* less than a power-of-two,
> rather than *one* less, which would impact the cute number-of-bits
> extractor discussed here a year ago. :-(

I don't see the issue. All machines that run standard C must use the
same pure binary representation for unsigned ints. The different
signed reps. have no obvious connection to the problem. Is there a
hardware issue you know of to do with implementing full-width pure
binary unsigned ints on a 1's complement system?

Also, unsigned into must be able to hold all the positive values of
signed ints so, if there is an issue, the two-bits shorter solution
is not available.

<snip>
--
Ben.

== 2 of 9 ==
Date: Thurs, Mar 4 2010 5:19 am
From: pete

James Dow Allen wrote:

> I've not worked on a one's-complement machine since before there
> was a C language, but I wonder how they work here. Perhaps
> UINT_MAX on such a machine is *two* less than a power-of-two,
> rather than *one* less, which would impact the cute number-of-bits
> extractor discussed here a year ago. :-(

No.
(UINT_MAX + 1 == 0) is true
regardless of how negative integers are represented.

--
pete

== 3 of 9 ==
Date: Thurs, Mar 4 2010 5:19 am
From: Eric Sosman

On 3/4/2010 12:28 AM, James Dow Allen wrote:
> On Mar 4, 8:01 am, "christian.bau"<christian....@cbau.wanadoo.co.uk>
> wrote:
>> Addition of unsigned numbers is well-defined by the C Standard for any
>> input values; if the mathematical sum of a and b is greater than
>> UINT_MAX then the result is the mathematical sum (a + b - (UINT_MAX +
>> 1)), which can easily be shown to be less than b in all cases (and
>> also less than a).
>
> I've not worked on a one's-complement machine since before there
> was a C language, but I wonder how they work here. Perhaps
> UINT_MAX on such a machine is *two* less than a power-of-two,
> rather than *one* less, which would impact the cute number-of-bits
> extractor discussed here a year ago. :-(

Yes, I see the smiley, but I'm not sure how much of the
paragraph it applies to. Just in case: *unsigned* integers
do not use two's complement, or ones' complement, or signed
magnitude, all of which are schemes for encoding negative
values. Since unsigned integers cannot have negative values,
the question of how to represent them never arises.

An unsigned integer is represented by some number of value
bits and some number of padding bits (often none at all). The
maximum value is encoded by setting all the value bits to one,
hence that value is necessarily one less than a power of two.
It cannot be two less than a power of two, not never.

We return you now to the usual jesting and hijinks.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 4 of 9 ==
Date: Thurs, Mar 4 2010 6:37 am
From: James Dow Allen

On Mar 4, 8:19 pm, pete <pfil...@mindspring.com> wrote:
> James Dow Allen wrote:
> > I've not worked on a one's-complement machine since before there
> > was a C language, but I wonder how they work here. Perhaps
> > UINT_MAX on such a machine is *two* less than a power-of-two,
> > rather than *one* less, which would impact the cute number-of-bits
> > extractor discussed here a year ago. :-(
>
> No.
> (UINT_MAX + 1 == 0) is true
> regardless of how negative integers are represented.

I see three responses implying I'm nuts. I wonder if they're
from three people who've never worked with 1's-complement
machines.

Just to be clear, on the one and only one's-complement
machine I've used, there was no special opcode(s) for
*unsigned* integers. And, (pretending for simplicity
that that machine had 16-bit ints) when you added 0xFFFE
to 0x0001 the result was 0x0000. (If you added 0xffff
and 0x0001 the result was 0x0001.) AFAIK there would only
be two conceivable ways to implement a C compiler
on that machine: EITHER make UINT_MAX == 0xfffe OR
every unsigned arithmetic op would require a special
sequence involving tests and multiple machine ops.

I'm guessing the former, but that this got overlooked
in the subthread from a year ago: "Is {U,}{INT,LONG}_MAX
always 1 less than a power-of-two?"

Too bad Dik is no longer with us. Obviously he knew
this stuff like an eagle knows how to fly.

Am I wrong? Is there such a thing as 1's-complement
where 0xffff is *not* "negative zero"?

Note that, if my guess is correct, Pete's response
> No.
> (UINT_MAX + 1 == 0) is true
> regardless of how negative integers are represented.
becomes correct if we simply replace "No." with "Yes."

James Dow Allen

== 5 of 9 ==
Date: Thurs, Mar 4 2010 7:11 am
From: pete

James Dow Allen wrote:
>
> On Mar 4, 8:19 pm, pete <pfil...@mindspring.com> wrote:
> > James Dow Allen wrote:
> > > I've not worked on a one's-complement machine since before there
> > > was a C language, but I wonder how they work here. Perhaps
> > > UINT_MAX on such a machine is *two* less than a power-of-two,
> > > rather than *one* less, which would impact the cute number-of-bits
> > > extractor discussed here a year ago. :-(
> >
> > No.
> > (UINT_MAX + 1 == 0) is true
> > regardless of how negative integers are represented.
>
> I see three responses implying I'm nuts.

ISO/IEC 9899:1999 (E)
6.2.5 Types
9
A computation involving unsigned operands can never overflow,
because a result that cannot be represented by the resulting
unsigned integer type is reduced modulo the number that is
one greater than the largest value
that can be represented by the resulting type.

--
pete

== 6 of 9 ==
Date: Thurs, Mar 4 2010 7:15 am
From: James Dow Allen

On Mar 4, 9:37 pm, James Dow Allen <jdallen2...@yahoo.com> wrote:
> Just to be clear, on the one and only one's-complement
> machine I've used, there was no special opcode(s) for
> *unsigned* integers. And, (pretending for simplicity
> that that machine had 16-bit ints) when you added 0xFFFE
> to 0x0001 the result was 0x0000....

The machine I speak of is the CDC-6{4,5,6}00 with 60-bit
words. Actually, there was another set of opcodes
called "Double Precision Floating Point" opcodes, but which
could also be used for, effectively, unsigned arithmetic.
I *think* only 48-bit results (plus a carry bit) could be
developed. Could C for that machine possibly have had
60-bit signed longs and 48-bit unsigned ints?

Ben and Eric are each correct well over 99% of the time,
so I'm probably going to end up embarrassed by my
outburst. :-(
I'll blame it all on creeping senility: Obviously I wasn't
that stupid 1 year ago, or I would have brought this up
in the "MAX always one less than power-of-two" thread. :-)

James

== 7 of 9 ==
Date: Thurs, Mar 4 2010 7:43 am
From: James Dow Allen

On Mar 4, 10:11 pm, pete <pfil...@mindspring.com> wrote:
> James Dow Allen wrote:
> > > No.
> > > (UINT_MAX + 1 == 0) is true
> > > regardless of how negative integers are represented.
>
> > I see three responses implying I'm nuts.
>
> ISO/IEC 9899:1999 (E)
> 6.2.5 Types
> 9
> A computation involving unsigned operands can never overflow,
> because a result that cannot be represented by the resulting
> unsigned integer type is reduced modulo the number that is
> one greater than the largest value
> that can be represented by the resulting type.

Yes. Everything you've written is compatible with BOTH
possibilities I've raised except for the single word "No"
in your first response which becomes "Yes" in the peculiar
variation I've outlined. (Note that the "modulo"
you mention would then be *1 less than a power-of-two*!)

If my perspective is still unclear, know this: I'm far
more interested in the behaviour of the C compiler on a
Real Machine with 1's-complement arithmetic than
I am in the specific diction of an ISO document.

As I imply in my recent post, I'm starting to guess the
CDC 6{4,5,6}00 used 48-bit unsigned ints that behaved
as normal 2's-complement integers behave, and special
coding for unsigned longs, if any, of some larger size.

James

== 8 of 9 ==
Date: Thurs, Mar 4 2010 7:59 am
From: Tim Rentsch

James Dow Allen <jdallen2000@yahoo.com> writes:

> On Mar 4, 8:19 pm, pete <pfil...@mindspring.com> wrote:
>> James Dow Allen wrote:
>> > I've not worked on a one's-complement machine since before there
>> > was a C language, but I wonder how they work here. Perhaps
>> > UINT_MAX on such a machine is *two* less than a power-of-two,
>> > rather than *one* less, which would impact the cute number-of-bits
>> > extractor discussed here a year ago. :-(
>>
>> No.
>> (UINT_MAX + 1 == 0) is true
>> regardless of how negative integers are represented.
>
> I see three responses implying I'm nuts. I wonder if they're
> from three people who've never worked with 1's-complement
> machines.
>
> Just to be clear, on the one and only one's-complement
> machine I've used, there was no special opcode(s) for
> *unsigned* integers. And, (pretending for simplicity
> that that machine had 16-bit ints) when you added 0xFFFE
> to 0x0001 the result was 0x0000. (If you added 0xffff
> and 0x0001 the result was 0x0001.) AFAIK there would only
> be two conceivable ways to implement a C compiler
> on that machine: EITHER make UINT_MAX == 0xfffe OR
> every unsigned arithmetic op would require a special
> sequence involving tests and multiple machine ops.

That doesn't matter, because the Standard requires
unsigned types with N value bits to represent all
values between 0 and 2**N - 1.

> I'm guessing the former, but that this got overlooked
> in the subthread from a year ago: "Is {U,}{INT,LONG}_MAX
> always 1 less than a power-of-two?"

Yes.

(Honesty in advertsing: some people have argued that
the signed maximums INT_MAX or LONG_MAX don't have to
be one less than a power of two. I disagree. However,
about the unsigned types the Standard is quite clear,
and as far as I know there is no disagreement there.)

== 9 of 9 ==
Date: Thurs, Mar 4 2010 8:09 am
From: Eric Sosman

On 3/4/2010 9:37 AM, James Dow Allen wrote:
> On Mar 4, 8:19 pm, pete<pfil...@mindspring.com> wrote:
>> James Dow Allen wrote:
>>> I've not worked on a one's-complement machine since before there
>>> was a C language, but I wonder how they work here. Perhaps
>>> UINT_MAX on such a machine is *two* less than a power-of-two,
>>> rather than *one* less, which would impact the cute number-of-bits
>>> extractor discussed here a year ago. :-(
>>
>> No.
>> (UINT_MAX + 1 == 0) is true
>> regardless of how negative integers are represented.
>
> I see three responses implying I'm nuts. I wonder if they're
> from three people who've never worked with 1's-complement
> machines.

(1) Not "nuts," just "mistaken." (2) I've worked with a
ones' complement machine, although only briefly and not in C.

> Just to be clear, on the one and only one's-complement
> machine I've used, there was no special opcode(s) for
> *unsigned* integers. And, (pretending for simplicity
> that that machine had 16-bit ints) when you added 0xFFFE
> to 0x0001 the result was 0x0000. (If you added 0xffff
> and 0x0001 the result was 0x0001.) AFAIK there would only
> be two conceivable ways to implement a C compiler
> on that machine: EITHER make UINT_MAX == 0xfffe OR
> every unsigned arithmetic op would require a special
> sequence involving tests and multiple machine ops.

6.2.6.2p1: "For unsigned integer types [...] objects of
that type shall be capable of representing values from 0 to
2^N - 1 using a pure binary representation [...]"

An implementation might need to jump through hoops to
make this happen on unfriendly hardware, just as implementations
on word-addressed machines must jump through hoops to use
pointers to smaller-than-word types. That's the implementation's
problem, and the implementation's duty.

> I'm guessing the former, but that this got overlooked
> in the subthread from a year ago: "Is {U,}{INT,LONG}_MAX
> always 1 less than a power-of-two?"
>
> Too bad Dik is no longer with us. Obviously he knew
> this stuff like an eagle knows how to fly.
>
> Am I wrong? Is there such a thing as 1's-complement
> where 0xffff is *not* "negative zero"?

There could be a machine for which that bit pattern would
be a trap representation (for a signed integer), with no value
at all. If it's not a trap, though, it's negative zero on a
ones' complement machine.

... which makes no nevermind for *unsigned* types, which
do not encode a sign at all, not with any of the schemes that
are used for signed integers, nor with any other scheme.

--
Eric Sosman
esosman@ieee-dot-org.invalid

==============================================================================
TOPIC: Stylistic questions on UNIX C coding.
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
==============================================================================

== 1 of 6 ==
Date: Thurs, Mar 4 2010 6:02 am
From: Vladimir Jovic

Keith Thompson wrote:
> Vladimir Jovic <vladaspams@gmail.com> writes:
>> Scott Lurndal wrote:
>>> I personally place the condition operator at the front, as
>>> William does, but nested.
>>>
>>> if ((pointer1 != NULL)
>>> && (pointer1->field7 == 0x152)) {
>>> return;
>>> }
>> if ( ( pointer1 =! NULL )
>> && ( pointer1->field7 = 0x152 ) ) {
>> return;
>> }
>>
>> ops && ops
>
> if ( pointer1 != NULL &&
> pointer1->field7 == 0x152 )
> {
> return;
> }
>
> I put the opening brace on the same line as the "if" if it fits.
> If it doesn't, I put it on a line by itself, so it doesn't get lost.
> It's probably not entirely consistent, but it works well for me.
>
> Note that I also dropped some extraneous parentheses. Too many
> parentheses can be as confusing as too few, and I think it's
> sufficiently obvious that "==" and "!=" bind more tightly than "&&".
> The alignment of the subexpressions helps.
>
> I do not suggest that my style is the only correct one.
>

Yes, you missed the point. I prefer this way :

if ( NULL != pointer1 &&
0x152 == pointer1->field7 )
{
return;
}

Can save you some debugging time :)

== 2 of 6 ==
Date: Thurs, Mar 4 2010 6:25 am
From: Casper H.S. Dik

Vladimir Jovic <vladaspams@gmail.com> writes:

>Yes, you missed the point. I prefer this way :

>if ( NULL != pointer1 &&
> 0x152 == pointer1->field7 )
> {
> return;
> }

>Can save you some debugging time :)

But it makes the code much more difficult to read.

You're not testing that NULL now has a different value or that
0x152 has a different value.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

== 3 of 6 ==
Date: Thurs, Mar 4 2010 6:40 am
From: Richard

Vladimir Jovic <vladaspams@gmail.com> writes:

>
> Yes, you missed the point. I prefer this way :
>
> if ( NULL != pointer1 &&
> 0x152 == pointer1->field7 )
> {
> return;
> }
>
> Can save you some debugging time :)
>

I congratulate you : it has everything that sucks in pseudo styling.

1) unnecessary waste of vertical screen usage
2) horrible "Non english" comparisons.

When discussing vars in computing it is normal to discuss the variables
b name.

You dont say "if pi is larger than p".You say "if p is larger than
pi". You're style is nothing more than fancy for fancy's sake IMO.

> if (pointer1 && pointer1->field7==0x152)
> return;

Is less code and more readable and doesnt use any clever clogs
reversals.

--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

== 4 of 6 ==
Date: Thurs, Mar 4 2010 7:52 am
From: John Gordon

In <oct467-nu6.ln1@news.eternal-september.org> Richard <rgrdev_@gmail.com> writes:

> When discussing vars in computing it is normal to discuss the variables
> b name.

> You dont say "if pi is larger than p".You say "if p is larger than
> pi". You're style is nothing more than fancy for fancy's sake IMO.

No, it does actually do something: it will throw a compile error if you
mistype == as =.

To demonstrate, imagine that you intended to type this:

if (x == 7)

But you mistakenly typed this:

if (x = 7)

This is legal code but will not behave in the way you intended.

But if you had typed it this way:

if (7 = x)

The compiler will throw an error.

--
John Gordon A is for Amy, who fell down the stairs
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

== 5 of 6 ==
Date: Thurs, Mar 4 2010 8:06 am
From: Casper H.S. Dik

John Gordon <gordon@panix.com> writes:

>To demonstrate, imagine that you intended to type this:

> if (x == 7)

>But you mistakenly typed this:

> if (x = 7)

>This is legal code but will not behave in the way you intended.

>But if you had typed it this way:

> if (7 = x)

>The compiler will throw an error.

But leaves you with unreadable code.

You are using the wrong tools; proper tools will detect this.

lint:

(4) warning: assignment operator "=" found where "==" was expected

and gcc:

foo.c:4: warning: suggest parentheses around assignment used as truth value

== 6 of 6 ==
Date: Thurs, Mar 4 2010 8:11 am
From: ImpalerCore

On Mar 4, 10:52 am, John Gordon <gor...@panix.com> wrote:
> In <oct467-nu6....@news.eternal-september.org> Richard <rgrd...@gmail.com> writes:
>
> > When discussing vars in computing it is normal to discuss the variables
> > b name.
> > You dont say "if pi is larger than p".You say "if p is larger than
> > pi". You're style is nothing more than fancy for fancy's sake IMO.
>
> No, it does actually do something: it will throw a compile error if you
> mistype == as =.
>
> To demonstrate, imagine that you intended to type this:
>
> if (x == 7)
>
> But you mistakenly typed this:
>
> if (x = 7)
>
> This is legal code but will not behave in the way you intended.
>
> But if you had typed it this way:
>
> if (7 = x)
>
> The compiler will throw an error.

I prefer readability over a marginal technique to reduce bugs.
English is meant to be read left to right, and is how I prefer to read
code, not the Yoda style '7 == x'. If the potential bug really causes
you grief, maybe pass a flag that makes the compiler flag 'x = 7' as
warnings?

> --
> John Gordon A is for Amy, who fell down the stairs
> gor...@panix.com B is for Basil, assaulted by bears
> -- Edward Gorey, "The Gashlycrumb Tinies"

==============================================================================
TOPIC: Mommy, Where Do Standards Come From?
http://groups.google.com/group/comp.lang.c/t/2ee9317b397797a0?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 4 2010 8:04 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

http://pl.atyp.us/wordpress/?p=2719

Please share your thoughts, if you care.

Thank you,
lacos

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

== 1 of 1 ==
Date: Thurs, Mar 4 2010 8:10 am
From: Tim Rentsch

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

> On 2010-03-02, Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> wrote:
>> Certainly that seems to be the expectation, but I don't
>> think it's required or necessarily guaranteed. I'm
>> pretty sure a conforming implementation could have
>> SIZE_MAX == 65535 but still allow
>>
>> char too_big[ 100000 ];
>>
>> for example. And that's only one way of getting a buffer of
>> more than SIZE_MAX bytes.
>
> I can't see how. If it does that, what does it give you for sizeof(too_big)?

It can because there is no syntax error and no constraint
violation. Probably the declaration itself is already undefined
behavior, but assuming it isn't, doing 'sizeof too_big' would
yield a value that the result type can't represent, which is to
say an exceptional condition, in other words undefined behavior.
Since any program containing such a declaration can never be
strictly conforming, the undefined behavior gives the
implementation license to define the behavior however it wants;
for example, the expression 'sizeof too_big' could be 100000,
despite that value being too large for a size_t variable to
contain.

==============================================================================
TOPIC: operator overloading ==
http://groups.google.com/group/comp.lang.c/t/e872bdd42d831744?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 4 2010 8:16 am
From: A

Hi,
I am writing a "vector" class. I know about the STL but I prefer to
use this as I use this to create a "matrix" class later. I read that
using the inbuilt STL to create a matrix is not the best way to do it.

At the moment, the class "vec" looks like this.
template <class T>
class vec {
private:
int length;
T *v;
public:
vec();
explicit vec(int n);
vec(const T &a, int n);
vec(const T *a, int n);
vec(const vec &cpy);
vec & operator=(const vec &equate);
vec & operator=(const T &a);
inline T & operator[](const int i);
inline const T & operator[](const int i) const;
inline int size() const;
~vec();
};

Now, I want to overload the operator == in this way. It should accept
a value (type T) say "val", and check through all the entries of this
vector say "v1" and return another vector of type bool, which has
"false" where v1 != val and "true" where v1 == val. I managed to write
it this way...

member function:
vec<bool> operator==(const T &a) const;

the code definition is:
template <class T>
vec<bool> operator==(const T &a) const {
vec<bool> tmp(false,length);
for(int i=0; i<length; i++) {
if(v[i] == a) {
tmp[i] = true;
}
}
return tmp;
}

This works great, but I would like to return the reference instead of
the whole vector and would like to know how to do it. I am unable to
make use of the "this" pointer as I am returning a "local vector". I
would appreciate any help with this. thank you!

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

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

Thursday, March 4, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts