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

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

comp.lang.c@googlegroups.com

Today's topics:

* Substrings and so on - 9 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/2e9f3f2a5244b8a2?hl=en
* problems with logic operations within loops - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/9228b4a6f1c5f9e3?hl=en
* What is on topic here - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/a91a80117d377f7f?hl=en
* The undefinedness of a common expression. - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/bdae87d399a9442e?hl=en
* A tool that suggests optimized logic for a piece of code/module/function - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/8dc0c7e3c216aa24?hl=en
* Experiment: functional concepts in C - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en

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

== 1 of 9 ==
Date: Tues, Jan 26 2010 9:00 am
From: Eric Sosman

On 1/26/2010 11:14 AM, Vicent wrote:
> [...]
> I've chosen C++, because I need to program some algorithms and I think
> it is a good choice for that purpose.
>
> So, my problem is about how to read files in C++, I think.

Perhaps the kind people on the comp.lang.c++ forum
would be better able to assist you with that language.
Since the I/O features of C++ differ quite a lot from
those of C, and since I/O is what you're interested in ...

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

== 2 of 9 ==
Date: Tues, Jan 26 2010 9:02 am
From: Vicent

On 26 ene, 15:20, la...@ludens.elte.hu (Ersek, Laszlo) wrote:
> In article <f393377f-5123-4c26-8d19-d6e05eee0...@36g2000yqu.googlegroups.com>, Vicent <vgi...@gmail.com> writes:

> For C++, I guess you'd look first at std::string and std:iostream.

Thank you! That's a point to start.

> Google them, or obtain a draft or an actual edition of the ISO C++
> standard (ISO/IEC 14882). A draft might be available at the C++
> Standards Committee's site:
>
> http://www.open-std.org/jtc1/sc22/wg21/
>
> Chapter 21, Strings library
> Chapter 27, Input/output library

That's a great link!! Thanks.

> The Qt or Boost libraries may prove helpful as well.
>
> http://doc.trolltech.com/4.6-snapshot/qstring.htmlhttp://www.boost.org/doc/libs/1_41_0/libs/libraries.htm#String
>

Good links, also. :-)

> For C: don't start with it. Low-level string manipulation is one of the
> most error-prone tasks in general, leading to countless security
> vulnerabilities.

OK. Everyone tells me to avoid using C-strings, so...

>
> > I've read some tutorials that deal with the standard C I/O and string
> > (string.h) libraries, but specially when managing strings, I am a bit
> > lost: Are there methods or functions to get substrings from a string,
> > or to take "spaces" ("blanks") away (a typical "wrap" function)??
>
> (That would be a typical "trim" function I guess.)

Yes, yes, sorry, I meant "trim", not "wrap". I miss those simple
"trim" functions at Visual Basic and PL/SQL Oracle...

> In my opinion, the
> "string interface" provided by standard C (or by versions of the Single
> Unix Specification) are much lower-level than you'd need; definitiely
> not for a beginner with higher abstraction needs. I suggest you switch
> to another language supporting high-level string manipulation (Perl,
> Python, Ruby etc) or grab a strings library. A discussion on them
> occurred on Reddit some time ago; several libraries were mentioned:
>
> http://www.reddit.com/r/programming/comments/abh76/what_string_type_s...
>
> When posting to that topic, I stumbled upon the following comparison
> page:
>
> http://www.and.org/vstr/comparison
>

OK, that's all very interesting. I see that other people had the same
problem before me!

> > About reading data from a text file, I think this is called "parsing".
> > Is there any "parsing" library???
>
> Especially in relation to parsing: don't start writing parsers in C. If
> you must, stick to whole-line input (with bounded length) and regular
> expressions. One such regex library is PCRE:
>
> http://www.pcre.org/
>
> But the Single Unix Specification defines a regex facility too.
>
> http://www.opengroup.org/onlinepubs/007908775/xsh/regex.h.html
>
> If you insist on consuming lines of arbitrary length, consider the
> getline() GNU libc extension.
>
> http://www.gnu.org/s/libc/manual/html_node/Line-Input.html#Line-Input
>
> Localized low-level text processing (put very crudely: anything
> non-ASCII) requires even more caution, so don't start with that either.
> Some C and C++ libraries should support it transparently, though.

What I exactly need to do is the following:

While there are still new lines:
(1) Get one line from a given text file.
(2) In that line, detect a "first" part and a "second part", which are
separated by a "=" symbol.
(3) Take away the possible "blanks" (like a "trim" function would do)
from those parts.
(4) Detect which variable in my program is being referred by the
"first part".
(5) Translate the second part (it is still a "string") into a number.

- About #1 : It can be done by means of standard I/O C libraries. I
guess that there are also ways to do it with C++ libraries.

- About #2 : It would be as simple as: detecting the position of "="
and then get two substrings. I don't understand why this step is so
difficult to perform in C!!!! I mean: there IS a C standard function
for getting the position of a character (it is "strchr"), but not a
function for substring (unless it is a substring that starts at
position 1, which can be done with "strncpy_s"). Is it easier at C++??

- About #3 : I would only need an equivalent of VB's "trim"
function... Is there anything like that at C++?

- About #4 : I can do this by using a "case" or an "if" statement. No
problem at all with this step, provided that "first part" has been
successfully extracted and trimmed.

- About #5 : I hope that a proper casting statement will be enough.

So, do you think that C++ std::string and std:iostream classes are
the right choice for me??

Thank you in advance for your feed-back!!!

--
Vicent

== 3 of 9 ==
Date: Tues, Jan 26 2010 9:23 am
From: Lorenzo Villari

On 26 Jan 2010 15:20:07 +0100
lacos@ludens.elte.hu (Ersek, Laszlo) wrote:

>
> For C: don't start with it. Low-level string manipulation is one of
> the most error-prone tasks in general, leading to countless security
> vulnerabilities.
>

I thought that was comp.lang.c...

== 4 of 9 ==
Date: Tues, Jan 26 2010 10:04 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <20100126182310.7d14676c@kubuntu>, Lorenzo Villari <vlllnz@tiscali.it> writes:
> On 26 Jan 2010 15:20:07 +0100
> lacos@ludens.elte.hu (Ersek, Laszlo) wrote:
>
>>
>> For C: don't start with it. Low-level string manipulation is one of
>> the most error-prone tasks in general, leading to countless security
>> vulnerabilities.
>>
>
> I thought that was comp.lang.c...

Please elaborate.

Thanks,
lacos

== 5 of 9 ==
Date: Tues, Jan 26 2010 10:10 am
From: Lorenzo Villari

On 26 Jan 2010 19:04:22 +0100
lacos@ludens.elte.hu (Ersek, Laszlo) wrote:

>
> Please elaborate.
>
> Thanks,
> lacos

C is not perfect I know that, but saying "C: don't start with it" in a
newsgroup with this name, it sounds a bit strange to me. That's all.

== 6 of 9 ==
Date: Tues, Jan 26 2010 10:25 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <4bd734c0-8413-4c4b-9773-a8182fc9972d@g29g2000yqe.googlegroups.com>, Vicent <vginer@gmail.com> writes:

> (5) Translate the second part (it is still a "string") into a number.
>
> - About #5 : I hope that a proper casting statement will be enough.

Please read an introductory book or tutorial on C, preferably one not
contradicting the ISO C standard(s). I hope others will name such works.
Reddit had a similar discussion recently. I obviously can't vouch for
the pieces of advice given there.

http://www.reddit.com/r/programming/comments/au1fg/dear_proggit_what_book_would_you_recommend_for_a/

> So, do you think that C++ std::string and std:iostream classes are
> the right choice for me??

I don't know. For the stated purpose, in (not standard) C I'd likely use
fgets() with a 32,767 byte buffer, then call regexec() in order to
identify the trimmed parts via parenthesized subexpressions, then call
strtol() to convert the decimal sequence to a long int.

Cheers,
lacos

== 7 of 9 ==
Date: Tues, Jan 26 2010 10:39 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <20100126191040.35310081@kubuntu>, Lorenzo Villari <vlllnz@tiscali.it> writes:
> On 26 Jan 2010 19:04:22 +0100
> lacos@ludens.elte.hu (Ersek, Laszlo) wrote:
>
>>
>> Please elaborate.
>>
>> Thanks,
>> lacos
>
> C is not perfect I know that, but saying "C: don't start with it" in a
> newsgroup with this name, it sounds a bit strange to me. That's all.

Thanks for answering.

I love C (even though most of the time this love is unrequited). I
didn't intend to point out C's perceived "shortcomings" -- I hope not to
have an ego that big. I tried to signal that C (and especially
manipulation of character arrays for parsing purposes) might not be the
best choice for the *original poster*, following completely from what I
perceived to be the OP's understanding of C.

Someone advising against me operating a sawbench would be completely
justified. A sawbench is a wonderful tool. It's not the sawbench, it's
me. I should start with introductory woodworking lessons first.

(Yes, I just compared C to a sawbench, please forgive me. And for the
record, I can "operate" a hand saw.)

Cheers,
lacos

== 8 of 9 ==
Date: Tues, Jan 26 2010 10:41 am
From: santosh

Vicent wrote:
[...]

> What I exactly need to do is the following:
>
> While there are still new lines:
> (1) Get one line from a given text file.
> (2) In that line, detect a "first" part and a "second part", which are
> separated by a "=" symbol.
> (3) Take away the possible "blanks" (like a "trim" function would do)
> from those parts.
> (4) Detect which variable in my program is being referred by the
> "first part".
> (5) Translate the second part (it is still a "string") into a number.
>
> - About #1 : It can be done by means of standard I/O C libraries. I
> guess that there are also ways to do it with C++ libraries.

Yes. For C, fgets() is the obvious choice, but if you want to read in
lines of arbitrary length, then you might have to write your own
function which uses dynamically allocated memory.

> - About #2 : It would be as simple as: detecting the position of "="
> and then get two substrings. I don't understand why this step is so
> difficult to perform in C!!!! I mean: there IS a C standard function
> for getting the position of a character (it is "strchr"), but not a
> function for substring (unless it is a substring that starts at
> position 1, which can be done with "strncpy_s"). Is it easier at C++??

Your point #2 is not clear. Do you simply need to locate the first
occurence of a '=' character? For that purpose strchr() would be fine.

[...]

> - About #5 : I hope that a proper casting statement will be enough.

Atleast for C, no. Casting is not appropriate. Depending on what type
of number the "string" represents (i.e., integer or real), you'll want
to use one of the strto*() family of functions, like strtol() strtoul
() & strtod() to name three.

Here's a good online reference to Standard C library functions (among
others):

<http://www.dinkumware.com/manuals/>

[...]

== 9 of 9 ==
Date: Tues, Jan 26 2010 10:47 am
From: santosh

Ersek, Laszlo wrote:
> In article <4bd734c0-8413-4c4b-9773-a8182fc9972d@g29g2000yqe.googlegroups.com>, Vicent <vginer@gmail.com> writes:
>
> > (5) Translate the second part (it is still a "string") into a number.
> >
> > - About #5 : I hope that a proper casting statement will be enough.
>
> Please read an introductory book or tutorial on C, preferably one not
> contradicting the ISO C standard(s). I hope others will name such works.
[...]

One online tutorial for complete beginners might be the one by Steve
Summit:

<http://www.eskimo.com/~scs/cclass/cclass.html>

Since Mr. Summit was apparently involved in the standardisation
process of C90, one might trust his tutorial not to contradict
Standard C. :-)

[...]

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

== 1 of 6 ==
Date: Tues, Jan 26 2010 9:02 am
From: Andrew Poelstra

On 2010-01-26, Tom St Denis <tom@iahu.ca> wrote:
> On Jan 26, 10:53 am, Andrew Poelstra <apoels...@localhost.localdomain>
> wrote:
>> On 2010-01-26, Tom St Denis <t...@iahu.ca> wrote:
>>
>> > On Jan 26, 10:40 am, Andrew Poelstra <apoels...@localhost.localdomain>
>> > wrote:
>> >> You can't use // comments in most C compilers today, and even
>> >> if you could you shouldn't on Usenet because they wrap around
>> >> like this and then nobody can compile your code.
>>
>> > Um what?  // are standard in C99 aren't they?  GCC certainly will
>> > accept them except when in -ansi mode.  Though yes, it's good to use /
>> > * */ instead, mostly for backwards compatibility but also to avoid
>> > wrapping.
>>
>> > Tom
>>
>> They are standard in C99, but gcc is not standard in C99 mode ;)
>>
>> (It is close enough for most purposes, though. I perhaps should
>>  have been clearer.)
>
> My point is GCC [and other compilers] silently accepted // by
> default. You can only get gcc to whine about it when you enter ANSI
> mode [e.g. C89/C90].
>

I (implicitly) meant that in default mode, gcc is not a C
compiler. (Rather a "GNU-C" compiler, which is a slightly
different beast.)

My bad - I try to word things to avoid these discussions,
since anyone who cares has in all likelihood heard them a
thousand times before.

> Though the rest of your point stands, C developers should use /**/ by
> default.
>
> Tom

== 2 of 6 ==
Date: Tues, Jan 26 2010 9:02 am
From: Richard Heathfield

Richard Bos wrote:
> Andrew Poelstra <apoelstra@localhost.localdomain> wrote:
>
>
>>> to[i] = from[i+1]; // if there is white space copy
>>> the next value
>> You can't use // comments in most C compilers today,
>
> Wrong

Wrong.

> (and it was wrong in many cases even before C99 made them
> official), but...

No, in C99 you can use them - but only six people have a C99 compiler.
In other implementations, you have to invoke the compiler in a
non-conforming mode in order to use them. If we accept as C something
that a compiler can only accept in non-conforming mode, we can
cheerfully accept Fortran as C, which is not something I'm prepared to do.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 3 of 6 ==
Date: Tues, Jan 26 2010 9:20 am
From: jacob navia

Richard Heathfield a écrit :
>
> Yes. Most C compilers, however, are not C99 compilers.
>

This is yet another lie. Please name one compiler that doesn't
accept // comments by default.

And no, putting gcc in pedantic mode doesn't count.

This is standard C, and it is widely implemented. I bet you can't
even name one compiler that doesn't accept those comments.

== 4 of 6 ==
Date: Tues, Jan 26 2010 9:51 am
From: Keith Thompson

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

Accepting // comments doesn't make a C compiler a C99 compiler.
If Richard posted anything untrue, it wasn't in the text that
you quoted.

You need to stop throwing the word "lie" around.

[...]

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 5 of 6 ==
Date: Tues, Jan 26 2010 9:55 am
From: Rob Kendrick

On Tue, 26 Jan 2010 18:20:07 +0100
jacob navia <jacob@nospam.org> wrote:

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

It is not a lie if you include the context you must have accidentally
snipped and not read. :)

> This is standard C, and it is widely implemented. I bet you can't
> even name one compiler that doesn't accept those comments.

The Norcroft/Codemist-based compiler I am occasionally forced to use
doesn't.

B.

== 6 of 6 ==
Date: Tues, Jan 26 2010 10:32 am
From: Richard Heathfield

jacob navia wrote:
> Richard Heathfield a écrit :
>>
>> Yes. Most C compilers, however, are not C99 compilers.
>>
>
> This is yet another lie.

No, it isn't. Please don't use the word "lie" when what you really mean
is "something Jacob Navia doesn't agree with".

> Please name one compiler that doesn't
> accept // comments by default.

Any compiler invoked in C90 conforming mode is required to issue a
diagnostic message when translating a translation unit containing at
least one syntax error or constraint violation. Since // comments are
always a syntax error in C90 (pathological cases excepted), all
C90-conforming compilers are required to object to // comments.

> And no, putting gcc in pedantic mode doesn't count.

If you don't invoke the compiler in conforming mode, it isn't required
to conform.

> This is standard C, and it is widely implemented. I bet you can't
> even name one compiler that doesn't accept those comments.

If by "accept" you mean "fail to issue a diagnostic message for", then
no C90-conforming implementations accept them. I will win the bet by
naming Borland C.

#include <stdio.h>

int main(void)
{
// get a diagnostic message
puts("Hello, diagnostic message.");
return 0;
}

When I compile this in conforming mode, I get this output:

Error E2188 scratch.c 5: Expression syntax in function main
*** 1 errors in Compile ***

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

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

== 1 of 4 ==
Date: Tues, Jan 26 2010 9:02 am
From: "osmium"

"Charlton Wilbur" wrote:

>>>>>> "A" == Albert <albert.xtheunknown0@gmail.com> writes:
>
> A> Suppose the OP is called A and any replier B. If A posts a
> A> *topic* that B thinks should be in another newsgroup, B *can*
> A> tell A that he doesn't like that and can (optionally) suggest a
> A> more appropriate newsgroup.
>
> A> This way, everyone gets ideas about where stuff should be posted
> A> given the year, month, who are "regulars" at a certain point of
> A> time, etc.
>
> And what happens then is that C, D, and E answer A's question, but only
> C gets it right; B points out that D and E got it wrong, and suggests
> the other newsgroup again; F and G snipe at B. Then H responds with
> seven posts of pseudopsychological babble (which just about everyone
> ignores), and I comes in a week later to claim that B has an
> autism-spectrum disorder.

I think you've got it!

== 2 of 4 ==
Date: Tues, Jan 26 2010 9:08 am
From: cri@tiac.net (Richard Harter)

On Sat, 23 Jan 2010 09:22:30 +0100, jacob navia
<jacob@nospam.org> wrote:

>This group is about building C progreams
>and the C language in general.

Neither you, nor Heathfield, nor Thompson, nor Twink, nor anyone
else has the authority to define what is topical for the group.
All you or any one else can do is express your views on what you
feel is topical.

All too many in this group write as though topicality were well
defined in some charter and that they were the duly appointed
proctors designated to correct those who stray from topicality.

If Heathfield (poor Richard, he is the ceremonial goat in these
arguments) is at fault in this manner, so are you.

That said, my view is that C is a family of languages with a
number of dialects, e.g., C89, C99, K&R I C, Gnu C, and even
Navia C. All are potentially discussable. Similarly issues
related to actually implementing C are potentially discussable.

There is a major caveat: They may be discussable but this group
usually is not a good choice for discussing them. Comp.lang.c
usuallly is not a good choice for discussing issues associated
with particular dialects, particular tools, or particular
environments - interest and expertise are likely to be spotty.
Usually there are other groups that are more appropriate.

For those those self appointed proctors who insist on redirecting
people to other groups may I suggest the following wording:

Comp.lang.c probably isn't the best group for your query;
xxxx.xxxx may be a better choice. I suggest that you try
posting there.

Give your inner grandfather a rest.


>
>This includes (but is not limited to)
>
>o linking problems
>o debugging problems
>o makefile problems related to the building of a c program
>o compiling and compiler related questions

But you see, for the most part these issues are problematic; they
are tangential to the C language.

In my view, the principal utility of this group lies in
illuminating programming issues associated with the C language.
For example, the C standards say nothing about threads. Some
persons claim that threads are therefore off topic. I disagree.
Particular implementations may well be best discussed elsewhere,
but the issues of using C in a threaded environment is on point.

>
>Most of the people that argue otherwise and want to restrict
>the scope of this group are part of a small self proclaimed
>group that thinks it can restrict the scope of this group
>to C89.

Jacob, you have the nasty habit of misrepresenting the positions
and opinions of others. The above paragraph is twaddle.

>
>If you look at their recent posting history you will see that
>they are the principal originators of completely off topic
>conversations here (the endless spinoza111 threads are a proof
>of that).
>
>To avoid clutter I will not answer any of their answers, if any.

Excellent. I commend your thoughtfulness in this matter. Make
it a habit.

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

== 3 of 4 ==
Date: Tues, Jan 26 2010 9:17 am
From: Richard Heathfield

Richard Harter wrote:

> All too many in this group write as though topicality were well
> defined in some charter and that they were the duly appointed
> proctors designated to correct those who stray from topicality.

Right.

> If Heathfield (poor Richard, he is the ceremonial goat in these
> arguments) is at fault in this manner, so are you.

If I am the ceremonial topicality scapegoat, it's based on a
misconception (apparently quite widely held). I actually think the
topicality of this group is too restrictive, and have said so on any
number of occasions.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 4 of 4 ==
Date: Tues, Jan 26 2010 9:33 am
From: Keith Thompson

cri@tiac.net (Richard Harter) writes:
[...]
> For those those self appointed proctors who insist on redirecting
> people to other groups may I suggest the following wording:
>
> Comp.lang.c probably isn't the best group for your query;
> xxxx.xxxx may be a better choice. I suggest that you try
> posting there.
[...]

Most of the time, that's just what I do. Naturally, I get flamed
for it.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

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

== 1 of 3 ==
Date: Tues, Jan 26 2010 7:48 am
From: lawrence.jones@siemens.com

In comp.std.c "Andr? Gillibert" <MetaEntropyRemoveThis@gmail.com> wrote:
>
> I was curious enough to test existing practice.
>
> #include <stdio.h>
> volatile int x,y;
> int main(void) {
> printf("hello");
> x=y=0;
> printf("hello");
> }
>
> (The printf statements are useful as delimiters around the relevant compiled
> code).
>
> GCC on GNU/Linux/i386 fetches y, in both C99 and C++98 modes.
> TCC on GNU/Linux/i386 doesn't fetch y.
>
> Consequently, existing behavior differs between C99 implementations. I think
> that's bad. It may be due to the ambiguous/defective standard wording, or a
> GCC bug, perhaps because GCC uses the same back-end for C and C++.

I maintain that you deserve whatever behavior you get when you write
code like that. Instead of the compound assignment, you should be
explicit about the behavior you want. Either:

y = 0;
x = 0;

or:

y = 0;
x = y;
--
Larry Jones

What better way to spend one's freedom than eating chocolate
cereal and watching cartoons! -- Calvin

== 2 of 3 ==
Date: Tues, Jan 26 2010 9:29 am
From: "Christopher Dearlove"

"Andr� Gillibert" <MetaEntropyRemoveThis@gmail.com> wrote in message
news:hjn5pk$q9l$1@news.eternal-september.org...
>
> "Christopher Dearlove" <chris.dearlove@baesystems.com> a �crit dans le
> message de news: 4b5f0acf$1_1@glkas0286.greenlnk.net...
>> "Andr� Gillibert" <MetaEntropyRemoveThis@gmail.com> wrote in message
>> news:hjmq99$jrv$1@news.eternal-september.org...
>>>
>>> "Wojtek Lerch" <wojtek_l@yahoo.ca> a �crit dans le message de news:
>>> 7s5sgeFjbkU1@mid.individual.net...
>>>> Andr� Gillibert wrote:
>>>>> Note that this is different from C++ where assignments are lvalues
>>>>> which makes
>>>>>
>>>>> int a,b,c=0;
>>>>> a=b=c;
>>>>>
>>>>> Well-defined in C but undefined in C++ (I think it's a C++ standard
>>>>> defect but fortunately not a C defect).
>>>>
>>>> It's undefined in C++? Why?
>>>>
>>> This has even been mentioned in a C++ DR (DR #222).
>>> From http://std.dkuug.dk/JTC1/SC22/WG21/docs/cwg_active.html#222:
>>>> One could argue that as the C++ standard currently stands, the effect
>>>> of x = y = 0; is undefined. The reason is that it both fetches and
>>>> stores the value of y, and does not fetch the value of y in order to
>>>> compute its new value.
>>
>> It's a long way from "One could argue" in 1999 to "undefined in C++"
>> in 2010, given that there's been a standard update in 2003 where had
>> it been seriously thought there was a problem it could have been fixed.
>> (I'm referring to the non-volatile case.)
>
> That's undefined in C++03, but, the new sequencing rules introduced in
> 2008 (Oxford) fix this issue. C++1x will include these new rules.

Clearly no one thought the undefinedness was more than a theoretical issue
for non-volatiles even in 2003. It's still a jump from "One could argue" to
your unqualified assertion that it is undefined.

== 3 of 3 ==
Date: Tues, Jan 26 2010 9:31 am
From: "Christopher Dearlove"

"André Gillibert" <MetaEntropyRemoveThis@gmail.com> wrote in message
news:hjn6pr$459$1@news.eternal-september.org...
>
> "Wojtek Lerch" <wojtek_l@yahoo.ca> a écrit dans le message de news:
>> I think you'll agree that people who write things like x=y=0 expect the
>> *new* value of y to be stored in x, not the old value --
>
> But, a C++03 implementation might give the old value....

Is this anything more than speculation? Is there any evidence of any C++
compiler actually not doing what everyone expects? (Reminder, this is
the non-volatile case.)

==============================================================================
TOPIC: A tool that suggests optimized logic for a piece of code/module/
function
http://groups.google.com/group/comp.lang.c/t/8dc0c7e3c216aa24?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 9:22 am
From: karthikbalaguru

On Jan 26, 3:51 pm, Josef Moellers <josef.moell...@ts.fujitsu.com>
wrote:
> karthikbalaguru wrote:
> > My query is 'A tool that suggests
> > optimized logic for a piece of
> > code/module/function' . I am
>
> Define "optimized"!
>
> Optimized for speed, optimized for memory requirement, optimized to
> handle extreme situations, optimized to handle easy situations?
>

Exactly !
The tool should support
for memory based optimization
that greatly helps in memory/
cost constraint systems,
speed based optimization that
greatly decides the performance
in certain projects, perfect
algorithm/logic required for a
particular scenario, and other
optimization techniques applicable.
It should probably have an option
that could decide the type of
optimization required for the user
for the particular module. May
be there can be an option called
'general optimization' that would
apply all optimization techniques
to a certain level only in a
balanced manner.

If the user is particular about
certain particular optimization,
Once the type of optimization
is got as input from the user,
even the level of optimization can
be got from the user by having
some flags/options for defining
different levels of optimization .

It could also tell the bottlenecks
in the code and that would greatly
help in optimizing the right piece
of code. Maybe a profiler should
also be part of it. The tool can
also display graphs that could
give comparitive analysis of
speed improvement vs memory
usage vs various levels of various
kinds of optimization techniques.

It can also suggest the best
possible number of threads
required, message queues
required for a particular
logic and define that logic.
It can remove off redundant
threads, interrupts or timers
etc and add if required for
an efficient logic that it
could suggest to the user.

Maybe, it can also suggest
various processors and the
relative performance w.r.t
memory, speed and cost
for those .
It could also suggest if
we need to go in for a
multicore and if so , it
can suggest the number
of cores and the kind of
processor !

Karthik Balaguru

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

== 1 of 2 ==
Date: Tues, Jan 26 2010 10:38 am
From: Ian Collins

Michael Foukarakis wrote:
> On Jan 26, 10:04 am, jacob navia <ja...@nospam.org> wrote:
>> gwowen a écrit :
>
>>> In many circumstances
>>> a smart pointer is preferable to GC, as it gives a programmer greater
>>> control over deterministic destruction (RAII works a lot better on
>>> managing mutexes than GC, for example -- lock()/unlock() cares about
>>> timing in a way malloc()/free() doesn't).
>> That could be done in C if we had operator overloading, something I have
>> been trying to promote for years.
>
> Operator overloading and lots of preprocessor tricks, correct?

Operator overloading and constructors/destructors, which are additions
that Jacob has vehemently opposed in the past. Smart pointers and RAII
in general can't work without them. Even with preprocessor tricks, RAII
can't be done in C.

--
Ian Collins

== 2 of 2 ==
Date: Tues, Jan 26 2010 10:46 am
From: Ian Collins

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

As they say on the BBC, other distributions with a garbage collector are
available. The Boehm GC has been used on many platforms. It is
distributed with Sun Studio for example.

I don't see other platforms actively promoting it like you do, perhaps
they should? It can be a very useful diagnostic tool as well as a
collector.

--
Ian Collins

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

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