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

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

comp.lang.c@googlegroups.com

Today's topics:

* Scope of a variable declared in for loop - 8 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/1092f2f493d747d0?hl=en
* usage of size_t - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
* help: gcc compilation difference - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en
* Any exit status without explicitely using return /exit - 5 messages, 5
authors
http://groups.google.com/group/comp.lang.c/t/6e91ccafedde0c25?hl=en
* Efficency and the standard library - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
* "selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers" "
hollywood sexiest scenes" "hollywood blue films" "hollywood movies free
download" on http://sexyandpretty-girls.blogspot.com/ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/c1dd7dc7dd5b6bd1?hl=en
* C99 is widely used! - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/0ba05b02a32efc0a?hl=en
* substring finding problem! - 3 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en

==============================================================================
TOPIC: Scope of a variable declared in for loop
http://groups.google.com/group/comp.lang.c/t/1092f2f493d747d0?hl=en
==============================================================================

== 1 of 8 ==
Date: Wed, Feb 24 2010 1:35 am
From: jacob navia

Keith Thompson a écrit :
> Michael Tsang <miklcct@gmail.com> writes:
>> Kenny McCormack wrote:
> [the usual]
>> C99 is not C?! READ THE STANDARD!
>> According to the standard:
> [snip]
>
> Don't worry about what Kenny says. He's lying.
>
Don't worry about Thomson, he is just obsolete.
He thinks anybody that doesn't agree with the C89 clique here
is lying...

== 2 of 8 ==
Date: Wed, Feb 24 2010 2:54 am
From: jacob navia

Mark Bluemel a �crit :
>
> Thanks for the correction. I should have checked C99, but given its
> absence from my day-to-day existence, I tend to forget about it.

Please abstain from answering nonsense then. Check if you know the
answer, THEN answer.

Thanks in advance.

== 3 of 8 ==
Date: Wed, Feb 24 2010 3:05 am
From: Richard

jacob navia <jacob@spamsink.net> writes:

> Mark Bluemel a écrit :
>>
>> Thanks for the correction. I should have checked C99, but given its
>> absence from my day-to-day existence, I tend to forget about it.
>
> Please abstain from answering nonsense then. Check if you know the
> answer, THEN answer.
>
> Thanks in advance.
>

I cant remember the time I last used a C compiler that didn't support
such declarations.

But then I dont pretend, like Messrs Heathfield and his clan, that my C
code is being ported to some valve based mainframe somewhere in deepest
Elbonia.

I also note, with some distaste, that Heathfield and his clan have now
reduced this group to a bitch session by constantly arguing with this
spinoza character who clearly has the knives out for our resident know
all and bible basher.

The general nastiness and smugness that certain regs exude here is a
rarety in technical groups. So hats off to the clique for managing it.

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

== 4 of 8 ==
Date: Wed, Feb 24 2010 4:13 am
From: gwowen

On Feb 24, 11:05 am, Richard <rgrd...@gmail.com> wrote:

> I cant remember the time I last used a C compiler that didn't support
> such declarations.

Green Hills compiler 424 for ARM9 does not support that extension.
TI's compiler for their Piccolo DSP does not support that extension.

I use both of these these frequently. These compilers are not for
outmoded valve powered mainframes -- ARM9's are pretty much the most
ubiquitous microprocessors in the world. You probably have one or two
about your immediate person.

Do you ever write code for non-desktop machines?

== 5 of 8 ==
Date: Wed, Feb 24 2010 4:16 am
From: Ben Bacarisse

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On 23 Feb, 16:00, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>> On Feb 23, 3:35 pm, vaysagekv <kvvays...@gmail.com> wrote:
<snip>
>> > B)if there is a for loop like below
>>
>> > for(int i=0;int c = getchar();i++);
<snip>
>> Also some
>> people use C++ as what is to all intents and purposes a C compiler
>> with a few differences,
>
> I'm not sure what this is supposed to mean. C99 and C++ have identical
> behaviour as regards defining variables in for loops.
>
>>one being that C++ always allows variables to
>> be declared anywhere.
>
> well, no. C++ doesn't support option B) either.

Sorry but it does. It's off topic so I won't give you all the
quotations but C++ permits a declaration in the condition part of an
'if', 'while', 'for' or 'switch' (but not 'do' of course).

--
Ben.

== 6 of 8 ==
Date: Wed, Feb 24 2010 4:20 am
From: Richard

gwowen <gwowen@gmail.com> writes:

> On Feb 24, 11:05 am, Richard <rgrd...@gmail.com> wrote:
>
>> I cant remember the time I last used a C compiler that didn't support
>> such declarations.
>
> Green Hills compiler 424 for ARM9 does not support that extension.
> TI's compiler for their Piccolo DSP does not support that extension.
>
> I use both of these these frequently. These compilers are not for
> outmoded valve powered mainframes -- ARM9's are pretty much the most
> ubiquitous microprocessors in the world. You probably have one or two
> about your immediate person.
>
> Do you ever write code for non-desktop machines?

Frequently.

But like I said I rarely if ever port to machines that dont support
something as widely used as, say gcc.

The main point remains : its a nice construct and recommended. The more
local a variable declaration the better for all concerned, especially
when dealing with things like loop variables where the end of the loop
means the end of our interest in it.

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

== 7 of 8 ==
Date: Wed, Feb 24 2010 4:34 am
From: jacob navia

gwowen a �crit :
> On Feb 24, 11:05 am, Richard <rgrd...@gmail.com> wrote:
>
>> I cant remember the time I last used a C compiler that didn't support
>> such declarations.
>
> Green Hills compiler 424 for ARM9 does not support that extension.
> TI's compiler for their Piccolo DSP does not support that extension.
>
> I use both of these these frequently. These compilers are not for
> outmoded valve powered mainframes -- ARM9's are pretty much the most
> ubiquitous microprocessors in the world. You probably have one or two
> about your immediate person.
>
> Do you ever write code for non-desktop machines?

You are talking nonse or just LYING

I cite from
http://www.ghs.com/news/20070131_compiler_version5.html
that is the official site of Green Hills Software:

Standards and Reliability

The Green Hills compiler was the first compiler for embedded systems to achieve 100% conformance to
ANSI/ISO standards for C and C++. In addition, the new compiler supports the latest C99
specification and the latest MISRA C standard. The Green Hills compilers are tested against industry
standard validation suites, including Plum Hall, and are also tested against the industry�s most
proven and extensive regression test suite.

That version was out in 2007!!!!

And now you are telling us that "there is no C99 support" in Green Hills
compilers?

== 8 of 8 ==
Date: Wed, Feb 24 2010 4:51 am
From: jacob navia

gwowen a écrit :
> TI's compiler for their Piccolo DSP does not support that extension.
>

The "Piccolo dsp" is not a stand alone processor and must be used with an
ARM7 processor, a product line introduced in 1992, 7 YEARS BEFORE the C
standard was out in 1999. We see here the bad faith of this people when
complaining about C99.

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

== 1 of 2 ==
Date: Wed, Feb 24 2010 1:46 am
From: Nick Keighley

On 23 Feb, 12:43, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
> On Tue, 23 Feb 2010 03:43:39 -0800, gwowen wrote:
> > On Feb 23, 9:50 am, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
>
> >> Why? A comment explaining that neophyte-like code looks that way for a
> >> reason, not because the coder is, in fact a neophyte, would be very
> >> helpful to maintainers.
>
> > Or, alternatively, just drop the assumption that "code that doesn't look
> > like mine is neophyte code".
>
> Again, not "like mine", but "like the vast majority I have seen which was
> produced by skilled C programmers".
>
> If someone is violating common conventions, they either have a reason for
> doing so, or they're simply so unfamiliar with what the rest of the world
> has been doing for the last couple of decades that they may as well be a
> neophyte.
>
> We had one particular coder around here for a while who persisted in
> using such bizarre macros and the like that his code was virtually
> unreadable. Was it good code? Was it safe, reliable, usable code?
>
> Maybe it was, but his choice to make it _appear_ as something else meant
> few cared to bother. If one chooses to make code appear bad or
> amateurish or otherwise undesirable, why blame the reder for rejecting it?

you are comparing oranges with orchards.

count = count + 1;

is not obscure code.

io_x style

#define B {
#define P printf

is obscure code

== 2 of 2 ==
Date: Wed, Feb 24 2010 1:46 am
From: Richard

Richard Heathfield <rjh@see.sig.invalid> writes:

> Nick Keighley wrote:
>> On 22 Feb, 22:29, "Bill Cunningham" <nos...@nspam.invalid> wrote:
>>> "Richard" <rgrd...@gmail.com> wrote in message
>>> news:bnga57-5i8.ln1@news.eternal-september.org...
>>>
>>>> That doesnt wash with me.
>>>> Putting the decrement in the body makes it less clear.
>>>> If a post decrement is too clever for the reader then so is using C.
>>> Use a debugger.
>>
>> no, don't
>> a debugger is not the right tool to learn what C constructs do
>
> I'm *reasonably* sure he was joking - yanking Richard NoName
> MyHammerIsADebuggerAndEveryProblemIsANail Riley's chain a little.

My sirname begins with L. But you SHOULD know that from the email I sent
you.

As it happens, a debugger is PERFECT for seeing how it works. If you dont
realise this then you're a bigger idiot that you appear.

Run the debugger and step the loop keeping an eye on the locals. Set a
breakpoint maybe for the terminal conditions such as i==1 or 0 etc.

If you do not see that as being useful for someone learning C then thank
god you're not in a position to teach anything. While we all realise
you have a very high opinion of your self worth, please dont spread your
own ignorance of how to use such useful tools.

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

==============================================================================
TOPIC: help: gcc compilation difference
http://groups.google.com/group/comp.lang.c/t/c99c680c6b425b26?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 2:00 am
From: Noob

Richard Heathfield wrote:

> -Wall tells gcc to be a tiny bit picky about the code.

For reference.

-Wall enables all the warnings about constructions that some users
consider questionable, and that are easy to avoid (or modify to prevent
the warning), even in conjunction with macros.

Note that some warning flags are not implied by -Wall. Some of them warn
about constructions that users generally do not consider questionable,
but which occasionally you might wish to check for; others warn about
constructions that are necessary or hard to avoid in some cases, and
there is no simple way to modify the code to suppress the warning. Some
of them are enabled by -Wextra but many of them must be enabled
individually.

</quote>

http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

> -Wall is rather less than the bare minimum warning level you need for
> portable C programming with gcc. At the very least, I would use:
>
> -W -Wall -ansi -pedantic

(NB: -W is the older name)

<quote>

-Wextra enables some extra warning flags that are not enabled by -Wall.
(This option used to be called -W. The older name is still supported,
but the newer name is more descriptive.)

</quote>

-ansi is equivalent to -std=c89,
other useful values are c99 and iso9899:199409

http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
http://gcc.gnu.org/onlinedocs/gcc/Standards.html

Regards.

==============================================================================
TOPIC: Any exit status without explicitely using return /exit
http://groups.google.com/group/comp.lang.c/t/6e91ccafedde0c25?hl=en
==============================================================================

== 1 of 5 ==
Date: Wed, Feb 24 2010 2:07 am
From: Igmar Palsenberg

> In my system (which is windows + mingw) it is returning 1,How to make
> it to return 0 or anything else implicitly without explicitly using
> exit/return ?

You don't. That's why the C standard has return / exit. I can't seem to
understand why you don't want to use a return value.

Igmar

== 2 of 5 ==
Date: Wed, Feb 24 2010 2:13 am
From: Debanjan

On Feb 24, 2:02 pm, Keith Thompson <ks...@mib.org> wrote:
> Debanjan <debanjan4...@gmail.com> writes:
> > This actually bugging me from quite sometime now.The question is like
> > this : How to set the the exit status of a program to any value
> > without explicitly using return/exit in gcc ?
>
> [...]
>
> Some equally interesting questions:
>
> How can you add two numbers without using the "+" operator?
>
> How can you call a function without using a function call?
>
> How can you pound a nail without using a hammer?
>
> A more relevant question: Why don't you want to use return or exit?
> That's what they're for.

There are few online coding challenge contest where less the number of
character more the points you earned for example consider this one :
http://www.spoj.pl/SHORTEN/ there are many others actually,you may
argue about using C in such places but why not C ? :)

For the question I asked,I modified it a bit

int f(int n){
return (n>0);
}

int main(){
int n;
while(scanf("%d",&n)&&f(n))
printf("%d\n",n);
}

Now it returns 0 implicitly,but I am unable to draw any firm
conclusion from this,could anybody help to generalize ?

== 3 of 5 ==
Date: Wed, Feb 24 2010 2:23 am
From: santosh

Debanjan <debanjan4you@gmail.com> writes:
[ ... ]

> For the question I asked,I modified it a bit
>
> int f(int n){
> return (n>0);
> }
>
> int main(){
> int n;
> while(scanf("%d",&n)&&f(n))
> printf("%d\n",n);
> }
>
> Now it returns 0 implicitly,but I am unable to draw any firm
> conclusion from this,could anybody help to generalize ?

If you're thinking the call to f() returns 0 from main() implicitly,
then you're not correct. As Jacob said, under C99 omitting an
explicit return from main() returns zero, but not your call to f().
The call to f() can be replaced with n > 0 in the loop condition. And
the problems Ike pointed out still remain.

Don't worry about exit statuses in obfuscated C contests. For
learning C, ignore obfuscated C contests, and just use return/exit.

== 4 of 5 ==
Date: Wed, Feb 24 2010 3:31 am
From: pacman@kosh.dhis.org (Alan Curry)

In article <ddfa57a3-7ec1-4ce9-b595-2ad9e26ee910@b7g2000pro.googlegroups.com>,
Debanjan <debanjan4you@gmail.com> wrote:
|
|int f(int n){
| return (n>0);
| }
|
|int main(){
| int n;
| while(scanf("%d",&n)&&f(n))
| printf("%d\n",n);
| }
|
|Now it returns 0 implicitly,but I am unable to draw any firm
|conclusion from this,could anybody help to generalize ?

Generally the return value you'll get from that program will be whatever
value happened to be left over in the integer return register when the
function reached its end. So it might even vary randomly between runs of the
same compiler, even without changing anything. Don't do that.

If you compile in C99 mode (gcc -std=c99) it'll do the implicit return 0 from
the end of main, consistently.

One of the stupider C99 features, it's not provided unless you ask for it.

--
Alan Curry

== 5 of 5 ==
Date: Wed, Feb 24 2010 4:38 am
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <ln3a0r2eqd.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:
>jacob navia <jacob@spamsink.net> writes:
>[...]
>> Standard C guarantees a return of zero for a main() function that
>> doesn't explicitly assign a return value.
>
>By "Standard C", of course, jacob means C99. In C90, which jacob
>insists on ignoring, the exit status of such a program is undefined.
>(Yes, C99 superseded C90. Yes, C99 is the one and only official
>C standard. We know, jacob, we know.)

This last paragraph is very illustrative of the CLC attitude.
Which is "When you say something lacking in precision in any way, we are
only too eager to point it out, repeatedly, and to pile on to our hearts
content. But when we say something a little sloppy, it's OK because we
run this place. And, further, it is you who are, again, at fault, for
pointing out our lack of precision."

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

== 1 of 4 ==
Date: Wed, Feb 24 2010 2:23 am
From: richard@cogsci.ed.ac.uk (Richard Tobin)

In article <lnfx4r2fpg.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:
>There's no fundamental reason why a compiler can't do as
>much analysis as it likes, perhaps optionally. Much of the analysis
>is necessary for optimization anyway.

The reverse is also true: many useful warnings can only be generated
by doing (the equivalant of) optimisation.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

== 2 of 4 ==
Date: Wed, Feb 24 2010 4:43 am
From: Ben Bacarisse

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On 23 Feb, 20:16, Nick <3-nos...@temporary-address.org.uk> wrote:
<snip>
>> Putting the bug aside, I had experience of people writing C like that
>> around 1990. They'd been on some sort of course in some sort of
>> programming methodology (maybe SSADM, maybe not - it was a long time
>> ago). In this case, they ended up writing something like:
>>
>> a = fgets(buff, SIZE, stdin)
>> while(a) {
>> do_things_with_a;
>> a = fgets(buff, SIZE, stdin);
>>
>> }
>>
>> All perfectly logical, but utterly un-idiomatic and (particularly when
>> things were a bit more complicated) it led you to looking at the two
>> identical lines wondering if they were in any way different.
>
> it's idiomatic in a language that doesn't allow assignment in the
> test. Removing the duplicated line was one reason I liked C!

It may be "idiomatic" but it is not good style in any language. If
you can't put an assignment in the test (because the language does not
allow it) then I think the way to go is an input function:

while (can_get_input(&a))
do_things_with(a);

Is there any language where you are forced to duplicate the input
line?

--
Ben.

== 3 of 4 ==
Date: Wed, Feb 24 2010 4:51 am
From: Willem

Ben Bacarisse wrote:
) It may be "idiomatic" but it is not good style in any language. If
) you can't put an assignment in the test (because the language does not
) allow it) then I think the way to go is an input function:
)
) while (can_get_input(&a))
) do_things_with(a);
)
) Is there any language where you are forced to duplicate the input
) line?

SQL, I think. In cursor fetch loops.

SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

== 4 of 4 ==
Date: Wed, Feb 24 2010 5:05 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <0.b03829bbcb6aa0133e99.20100224124328GMT.87zl2yls7j.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
>
>> On 23 Feb, 20:16, Nick <3-nos...@temporary-address.org.uk> wrote:
> <snip>
>>> Putting the bug aside, I had experience of people writing C like that
>>> around 1990. They'd been on some sort of course in some sort of
>>> programming methodology (maybe SSADM, maybe not - it was a long time
>>> ago). In this case, they ended up writing something like:
>>>
>>> a = fgets(buff, SIZE, stdin)
>>> while(a) {
>>> do_things_with_a;
>>> a = fgets(buff, SIZE, stdin);
>>>
>>> }
>>>
>>> All perfectly logical, but utterly un-idiomatic and (particularly when
>>> things were a bit more complicated) it led you to looking at the two
>>> identical lines wondering if they were in any way different.
>>
>> it's idiomatic in a language that doesn't allow assignment in the
>> test. Removing the duplicated line was one reason I liked C!
>
> It may be "idiomatic" but it is not good style in any language. If
> you can't put an assignment in the test (because the language does not
> allow it) then I think the way to go is an input function:
>
> while (can_get_input(&a))
> do_things_with(a);

Or we could commit a little bit of style massacre:

for (;;) {
char buf[SIZE];

if (0 == fgets(buf, sizeof buf, stdin)) {
break;
}

/* ... */
}

Cheers,
lacos

==============================================================================
TOPIC: "selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies free
download" on http://sexyandpretty-girls.blogspot.com/
http://groups.google.com/group/comp.lang.c/t/c1dd7dc7dd5b6bd1?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 3:29 am
From: Naeem

"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/
"selma blair" "salma hayek" "salma hayek hot" "salma hayek wallpapers"
"hollywood sexiest scenes" "hollywood blue films" "hollywood movies
free download" on http://sexyandpretty-girls.blogspot.com/

==============================================================================
TOPIC: C99 is widely used!
http://groups.google.com/group/comp.lang.c/t/0ba05b02a32efc0a?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 24 2010 4:37 am
From: jacob navia

One of the most often "arguments" against C99 in this group is that
"There is no embedded system support", etc.

A typical message is this one of "gwowen":

That is a typical post. Well, if you care to investigate those claims
a bit you find immediately that they are completely WRONG. I cared to
go to Green Hills Software web site and there I found this statement from
2007:

I cite from

http://www.ghs.com/news/20070131_compiler_version5.html

that is the official site of Green Hills Software:

<quote>
Standards and Reliability

That version was out in 2007!!!!

How can this guy tell us that "there is no C99 support" in Green Hills
compilers?

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

== 1 of 3 ==
Date: Wed, Feb 24 2010 4:46 am
From: spinoza1111

On Feb 23, 10:38 pm, blm...@myrealbox.com <blm...@myrealbox.com>
wrote:
> In article <d520a640-1606-407e-9b7f-b9c75f4d5...@s36g2000prf.googlegroups.com>,
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Feb 15, 8:41 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > > "Stefan Ram" <r...@zedat.fu-berlin.de> wrote in message
>
> > >news:rand-20100215000605@ram.dialup.fu-berlin.de...
>
> [ snip ]
>
> > And note that "using strstr" has its own dangers. IT FINDS OVERLAPPING
> > STRINGS. If you use it to construct a table of replace points you're
> > gonna have an interesting bug-o-rama:
>
> > replace("banana", "ana", "ono")
>
> > IF you restart one position after the find point, and not at its end.
>
> Why would you do that, though? only if you *wanted* to detect
> overlapping strings, and -- if you did detect them, what would
> you do with them? I can't think of any sensible definition of
> "replace" that does anything with overlapping strings [*], so
> when I wrote my first solution to this problem, I of course used
> strstr and of course started scanning for the next match after
> the end of the previous match.
>
> [*] Chris Thomasson's reply to your post points out the ambiguities.
>
> > Moral: don't let the library do your thinking for you.
>
> Mostly I'm replying to this rather old post, though, because it
> seems as good a place as any to attempt a more-or-less formal
> specification of the problem, which I'm not sure we have, and
> which might be interesting. (Apologies if I missed one somewhere.)
>
> Here's my proposed specification, in which "is not a substring of"
> and "concat" have what I hope are obvious meanings, and names
> beginning s_ denote strings:
>
> replace(s_input, s_old, s_new) yields
>
> if s_old is not a substring of s_input
>
> s_input
>
> else
>
> concat(s_input_prefix, s_new, replace(s_input_tail, s_old, s_new))
>
> where s_input_prefix and s_input_tail are such that
>
> s_input = concat(s_input_prefix, s_old, s_input_tail)
>
> and
>
> s_old is not a substring of s_input_prefix
>
> Somewhat more formal than the "scans left to right and ignores
> overlapping strings", though whether it's actually clearer might
> be a matter of opinion.
>
> And then perhaps we could replace the "does not use string.h"
> constraint with something more meaningful [*], though I'm not
> sure what.
>
> [*] My objection to this constraint is that any minimally competent
> programmer should be able to write functions that implement the
> same API, so just avoiding use of the library functions doesn't
> seem to me to make the problem more interesting.
>
> --
> B. L. Massingill
> ObDisclaimer: I don't speak for my employers; they return the favor.

== 2 of 3 ==
Date: Wed, Feb 24 2010 4:57 am
From: spinoza1111

Search me. But that's what the code I was discussing actually did.

> overlapping strings, and -- if you did detect them, what would
> you do with them? I can't think of any sensible definition of
> "replace" that does anything with overlapping strings [*], so

replace(banana, ana, ono) could equal

bonona going left to right without overlap
banono going right to left without overlap
bonono going both ways with overlap

The third case could arise in natural language processing.

Suppose that in some language, the ana sound is transformed into the
ono sound to transform present into past tense (weirder things
happen), and suppose speakers do this to ALL occurences of the three
tones a, voiced n, a. When the sounds are adjacent they are
nonetheless distinct in speech but not in writing.

Now, the response of most garden-variety "break room" programmers is
"that's bullshit, and can never happen". But we know that in
programming, many strange things can happen, and that as Hamlet
admonished Horatio, we must "as a stranger give it welcome". Many more
strange things can happen outside programming, and programmers, even
of the Hooters or break room ilk, better realize this when programming
is used to solve problems.

> when I wrote my first solution to this problem, I of course used
> strstr and of course started scanning for the next match after
> the end of the previous match.
>
> [*] Chris Thomasson's reply to your post points out the ambiguities.
>
> > Moral: don't let the library do your thinking for you.
>
> Mostly I'm replying to this rather old post, though, because it
> seems as good a place as any to attempt a more-or-less formal
> specification of the problem, which I'm not sure we have, and
> which might be interesting. (Apologies if I missed one somewhere.)
>
> Here's my proposed specification, in which "is not a substring of"
> and "concat" have what I hope are obvious meanings, and names
> beginning s_ denote strings:
>
> replace(s_input, s_old, s_new) yields
>
> if s_old is not a substring of s_input
>
> s_input
>
> else
>
> concat(s_input_prefix, s_new, replace(s_input_tail, s_old, s_new))
>
> where s_input_prefix and s_input_tail are such that
>
> s_input = concat(s_input_prefix, s_old, s_input_tail)
>
> and
>
> s_old is not a substring of s_input_prefix

This is fine as long as we understand your concat as NOT specifying
left to right or right to left direction. The bonono problem would
have to be handled by preprocessing (translating banana into banaana,
perhaps using a rule that "vowels" (in the language) can always be
duplicated because their sounds don't break.

>
> Somewhat more formal than the "scans left to right and ignores
> overlapping strings", though whether it's actually clearer might
> be a matter of opinion.
>
> And then perhaps we could replace the "does not use string.h"
> constraint with something more meaningful [*], though I'm not
> sure what.

How about "does not use string.H and gets rid of the Obscene
Excrescence: the use of Nul to terminate a string, thereby creating a
new C that is almost fit for use".

>
> [*] My objection to this constraint is that any minimally competent
> programmer should be able to write functions that implement the
> same API, so just avoiding use of the library functions doesn't
> seem to me to make the problem more interesting.

No. The API locks us into bad thoughts.

>
> --
> B. L. Massingill
> ObDisclaimer: I don't speak for my employers; they return the favor.

== 3 of 3 ==
Date: Wed, Feb 24 2010 5:01 am
From: spinoza1111

On Feb 24, 11:25 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-24, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > Race appears to have little or nothing to do with programming ability,
> > but to say that most Indian programmers are dreadful at programming is
> > perfectly accurate - India is not immune from Sturgeon's Law.
>
> People who have dealt with outsourcing are very likely to have encountered
> a disproportionately bad sample of programmers from some other country.
> I have not known anyone who has had particularly good experiences with
> "cheap offshore coders", and I have oodles of horror stories.

So do most incompetent programmers. The reason being that they are not
only bad at coding, they also do a bad job of problem specification,
and as technically educated people, they know nothing of the culture
of the offshore programmers, apart from racist
stereotyping...including the patronizing admiration for cuisine, which
relegates the people of the land, and cultures that are normally far
older than Europe, to a feminized, subordinate and servant role.

>
> On the other hand, I have a largeish number of Chinese coworkers. They're
> nearly all novice-level or newbie programmers, but they're good people to
> work with -- a huge step up from the outsourcing place we used to use.
>
> I think a big part of the problem is that people are carefully set up to
> fail -- I'm a pretty decent programmer by many standards, and I could not

Not by mine.

> produce adequate code from some of the specs I've seen. Giving these
> tasks to novice programmers who have to do a full day's work without any
> chance to ask for clarification or feedback... Well, I can imagine ways
> this could work poorly.
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

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

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, February 24, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts