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:

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

== 1 of 3 ==
Date: Wed, Feb 17 2010 2:15 am
From: Nick Keighley

On 16 Feb, 23:35, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-16, Ertugrul Söylemez <e...@ertes.de> wrote:

> > That's also the reason I suggest freeing all of the allocated memory
> > before exiting. If you don't, there is a closing tag missing in your
> > program pattern. When you restructure your program, you might
> > accidentally forget that missing closing tag and introduce memory leaks.
> > You know how difficult it can be to find memory leaks, if you ever
> > notice them at all.

if you don't notice them they don't matter!

> I actually have a memory debugger I wrote to find them. As you might expect,
> it couldn't solve the actual problem.

I too have spent many a happy hour hunting memory leaks.

> Because, technically, it wasn't a leak -- when I went through freeing
> everything at the end of program execution, all the allocated space got
> freed. However. During execution, it was possible for a particular object
> to end up with a linked list of unbounded size of allocated things that it
> maintained as internal state, which were neither used nor exposed to any
> other interface, making it very hard to find them -- and since it did free
> them correctly on exit, there was no memory leak.

mine actually were leaks. The memory concerned no longer had any
references to it and wouldn't be freed on shutdown.

Every time a timer was started a tiny little bit of memory went
missing... Over a period of weeks this begins to matter!

== 2 of 3 ==
Date: Wed, Feb 17 2010 2:19 am
From: Nick Keighley

On 17 Feb, 01:13, Richard Heathfield <r...@see.sig.invalid> wrote:
> Kaz Kylheku wrote:
> > ["Followup-To:" header set to comp.lang.c.]
> > On 2010-02-17, Richard Heathfield <r...@see.sig.invalid> wrote:

> >> Suddenly we had a huge maintenance problem on our hands because the
> >> original crew were too lazy to manage memory properly. This cost a
> >> significant amount of time (and therefore money) to fix, because the
> >> knowledge of the right points at which to free up the many and varied
> >> allocations had been discarded, and now had to be reacquired.
>
> > You wasted your time and money only because you didn't think of redirecting
> > the functions to use an alternate malloc-like API which keeps track of the
> > allocations, such that they can be freed with an additional call when func()
> > exits:
>
> It's true that we didn't think of such a scheme. Even if we had, though,
> either we'd have had to visit every malloc and free to replace them with
> the meta-memory-management function calls,

I've done this with a perl script.

> or we'd have had to redefine
> malloc(). The latter would have been unacceptable, I think. The former
> may have saved us a little time, though, if we had thought of it.
>
> But the time saving would have been optimum if the original programmer
> had done his job correctly.

http://en.wikipedia.org/wiki/You_ain't_gonna_need_it

> > The original programmer did the right thing by not wasting time on this
> > problem. The new use case was not a functional requirement for that program.
>
> I am reminded of the student who, when asked to write a program to add
> two numbers together and print the result, asked the lecturer "which two
> numbers should I add?"

:-)

== 3 of 3 ==
Date: Wed, Feb 17 2010 2:57 am
From: Michael Foukarakis

On Feb 16, 5:45 pm, Andrew Poelstra <apoels...@localhost.localdomain>
wrote:
> On 2010-02-16, Hyman Rosen <hyro...@mail.com> wrote:
>
> > On 2/14/2010 6:22 PM, Ertugrul Söylemez wrote:
> >> p...@informatimago.com (Pascal J. Bourguignon) wrote:
> >>> Perhaps today, for short lived C processes, you just don't have to
> >>> care about free anymore. Just malloc, and exit.
>
> >> This reasoning is used by many PHP programmers today. It's one reason
> >> why PHP programs are so error-prone and why PHP errors are often hard to
> >> find. There is no excuse for unfreed resources, particularly in
> >> languages, which are unsafe by nature, like C and PHP. It _will_ get
> >> you into trouble sooner or later.
>
> > There is generally no need to free resources just before
> > program exit, because the operating system will do that
>
> What basis do you have for this absurd claim...

Hardly absurd. Most OSs will reclaim all the user-space memory
previously assigned to a process, when it exits. One exception I can
think of is DOS with its TSR syscall. I also imagine embedded OSs that
don't implement virtual memory *might* also suffer from this, but that
doesn't make the claim absurd at all. It's actually very logical for
your garden variety current desktop OS (think Linux, Windows, etc).

> > for you - a program which spends a bunch of time freeing
> > every allocated object and then exits has just wasted all
>
> ...or this one? The OS, if it frees your memory, needs just
> as much CPU time as your code would, had you chosen to make
> it portable to machines who are not your mother.

The OS won't call free(). It doesn't do the same bookkeeping as a
process. Are you trying to be intentionally absurd?

> Allocators allocate. To ascribe anything more to them is
> presumptuous and unjustified.

What about bookkeeping? Error checking? What about memory
rearrangement to alleviate fragmentation? Are those unjustified? Or
does your generic term for "allocate" imply all of these?

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

== 1 of 6 ==
Date: Wed, Feb 17 2010 2:20 am
From: Phil Carmody

Richard Heathfield <rjh@see.sig.invalid> writes:
> spinoza1111 wrote:
>> On Feb 17, 6:35 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
>> wrote:
> <snip>
>>> Do not feed the troll.
>>
> <snip>
>
>> Richard Heathfield is by no means a friend of mine, yet he has gone on
>> record to say that I am not a "troll".
>
> That is true. I have also gone on record as saying that you're an idiot.

He does it for the strokes. His motives may be different, and the
strokes he seeks may be different (though not vastly different from
some of the sci.math cranks I've encountered), but he's still doing
it to elicit responses. Troll, crank, idiot - you can tick all three
with him.

And Chris' post did nothing but invite him to spew more inane crap
onto c.l.c. Why would anyone want that?

Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

== 2 of 6 ==
Date: Wed, Feb 17 2010 2:30 am
From: Richard Heathfield

spinoza1111 wrote:
> On Feb 17, 5:29 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> spinoza1111wrote:
>>> On Feb 17, 6:35 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
>>> wrote:
>> <snip>
>>>> Do not feed the troll.
>> <snip>
>>
>>> Richard Heathfield is by no means a friend of mine, yet he has gone on
>>> record to say that I am not a "troll".
>> That is true. I have also gone on record as saying that you're an idiot.
>
> That is correct. And I have gone on record as saying you're a fool.
> So, we agree that I am not a troll.

As usual, my point has gone way over your head.

You cite me as someone who says you are not a troll, in support of an
argument that you are not a troll. In so doing, you are appealing to
people's trust in my good judgement, whether or not you realise it.

For those people who do trust my good judgement, the argument is a
powerful one, but the argument that you are an idiot is equally
powerful. And for those people who do not trust my good judgement, the
argument carries no conviction.

As for your opinion of me, I ascribe it no value whatsoever, so it has
no bearing on this discussion.

ObTopic: finding substrings is easy with strstr(). If you need to find a
substring, use strstr() until and unless profiling demonstrates that
it's a significant bottleneck.

--
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: Wed, Feb 17 2010 2:17 am
From: fedora

Ben Bacarisse wrote:

> fedora <no_mail@invalid.invalid> writes:
>
>> Have finished my program for spinoza's challenge. rewrote everything and
>> this time i made each statement as simple as posible, so that i can
>> understand the program. The allSubstr procedure can search for over
>> lapping sub-string too like spinoza wanted, but the replace routine
>> doesnt use that since i cant think how to replace over lapping ones!
>>
>> haven't used any function from string.h! it works for strings i could
>> think of but maybe it got bugs since i'm just a beginner...
>
> The result is good, but I am not sure you were right to accept the
> peculiar notion of not using standard string functions. If you felt
> you had to, why not use standard functions but then plug-in you own
> versions? That way you learn about the standard library and get to
> write the character-fiddling functions that can be useful learning
> exercises.

Thanks Ben! I didn't use stdlib functions because i wanted to how
easy/difficult it would be to write my own. also spinoza didn't accept
program that called function in string.h.

About plugging in my own versions, do you mean writing routines with the
same name so that at linking the linker finds my lib first and plug it in?
but i read somewhere that using ansi c's namespace and relying on linker is
all undefined and gcc can replace calls to stdlib functions with inline code
so bypassing my code too... but i'll try it.

> I'll make a few detailed comments (one is a bug), but on the "big
> picture" I don't see why you mix size_t and unsigned all over the
> place. I'd stick to size_t.

ok.

> Finally, I think it is odd to return a null result when the substring
> is too long to match. I'd treat is like any other substring that does
> not match.

and just return copy of original target str? Okay, i'll change code to do
that but right now i'm having bigger problems.

> <snip>
>> #include <stdlib.h>
>> #include <stdio.h>
>> #include <assert.h>
>>
>> size_t strLength(char *cstr) {
>> size_t index = 0;
>>
>> while (cstr[index] != '\0') ++index;
>> return index;
>> }
>>
>> char *strFirstCh(char *str, char ch, size_t lstr) {
>> char *chpos = 0;
>> size_t current;
>>
>> for (current = 0; current < lstr; current++) {
>> if (str[current] == ch) {
>> chpos = str + current;
>> break;
>> }
>> }
>> return chpos;
>> }
>>
>> int strComp(char *s, char *t, size_t len) {
>> int ret = 0;
>> size_t index;
>>
>> for (index = 0; index < len; index++) {
>> if (s[index] != t[index]) {
>> ret = 1;
>> break;
>> }
>> }
>> return ret;
>
> Small point: ret is the same as index != len. Can you see why? Many
> C programmers would just return index != len here. Also, I'd reverse
> the sense of the returned value and call the function strEqual.

okay. that's better than modelling after stdlib strcmp. my reasoning was
since there's only one case where two strings can be identical but many
cases where they can differ i'd use the one bool value for the first case
(false) and return different true values for un-equal cases. but i think
i've thought of it wrongly. boolean flase and true are both unique values
and not like C's definition of true.

>> }
>>
>> char *strSubstr(
>> char *str,
>> char *sub,
>> size_t lstr,
>> size_t lsub) {
>> char *substr = 0;
>> char *anchor = str;
>> size_t remaining_len = (lstr - lsub) + 1;
>>
>> assert(str && sub && lstr && lsub && lstr >= lsub);
>> while (remaining_len > 0 && anchor) {
>> if (anchor = strFirstCh(anchor, *sub, remaining_len)) {
>> if (strComp(anchor, sub, lsub) == 0) {
>> substr = anchor;
>> break;
>> }
>> anchor++;
>> remaining_len--;
>> }
>> }
>> return substr;
>> }
>>
>> unsigned allSubstr(
>> char *str,
>> char *sub,
>> size_t lstr,
>> size_t lsub,
>> char ***ps,
>> int overlap) {
>> unsigned occurs = 0;
>> unsigned ctr;
>> char *orig_str = str;
>> size_t orig_lstr = lstr;
>> size_t step;
>>
>> if (overlap == 1)
>> step = 1;
>> else
>> step = lsub;
>>
>> while (lstr >= lsub) {
>> str = strSubstr(str, sub, lstr, lsub);
>> if (str == 0)
>> break;
>> occurs++;
>> str += step;
>> lstr = (orig_str + orig_lstr) - str;
>> }
>>
>> if (occurs > 0 && ps) {
>> str = orig_str;
>> lstr = orig_lstr;
>> *ps = malloc(occurs * sizeof **ps);
>> if (*ps) {
>> for (ctr = 0; ctr < occurs; ctr++) {
>> ps[0][ctr] = str = strSubstr(str, sub, lstr, lsub);
>> str += step;
>> lstr = (orig_str + orig_lstr) - str;
>> }
>> }
>> }
>> return occurs;
>> }
>>
>> char *replace(char *str, char *substr, char *rep) {
>> char *new = 0;
>> size_t lstr, lsubstr, lrep, lnew, strc, newc, repc, replaced;
>> unsigned replacements;
>> char **subpos;
>>
>> assert(str && substr && rep);
>> lstr = strLength(str);
>> lsubstr = strLength(substr);
>> lrep = strLength(rep);
>> if (lstr == 0 || lsubstr == 0 || lsubstr > lstr)
>> return 0;
>> replacements = allSubstr(str, substr, lstr, lsubstr, &subpos, 0);
>> if (replacements > 0) {
>> lnew = (lstr - (replacements * lsubstr)) + (replacements * lrep);
>> new = malloc(lnew + 1);
>> if (!new)
>> return 0;
>> strc = newc = replaced = 0;
>> while (strc <= lstr) {
>> if (str + strc == subpos[replaced]) {
>
> You have a bug here. replaced can become equal to the size of the
> subpos array and, hence, you index outside of it.

Thanks for spotting! i'd never have seen that. I replaced that line by

if (replaced < replacements && str + strc == subpos[replaced]) {

i made no other changes and compiled and ran... but strange errors are
occurring. below i'm pasting session from gdb... i really appreciate if
anyone can tell me why it's happening. what's irritating is there is no
patter for the seg faults. sometimes it happens, sometimes not.

compiled with gcc -Wall -Wextra -std=c99 -pedantic -o replace replace.c -
ggdb3

# gdb ./replace
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...

(gdb) run "sdakfhaskfhaskdfhaskdfhaksdfhksdfhajksdfhkjsdfhsdfasd" "sda" "+"
Starting program: /home/fedora/c/replace
"sdakfhaskfhaskdfhaskdfhaksdfhksdfhajksdfhkjsdfhsdfasd" "sda" "+"

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400648 in strFirstCh (str=0x7fff1da36feb "rc/c/replace",
ch=115 's', lstr=18446744073709551546) at replace.c:17
17 if (str[current] == ch) {

how can str be "rc/c/replace"?? It should be some part of the "sdak..."
string as i see...
ch is with right value. but lstr is wrong. how did it get that value? i cant
see any thing in my code that is wrong but i'm not intel.

big thanks to any one who can say why str is "rc/c/replace" and lstr is
wrong...

am thinking if string programing in C is naturally so difficult or i'm just
stupid:(

>> for (repc = 0; repc < lrep; repc++) {
>> new[newc] = rep[repc];
>> newc++;
>> }
>> replaced++;
>> strc += lsubstr;
>> }
>> else {
>> new[newc] = str[strc];
>> strc++;
>> newc++;
>> }
>> }
>> free(subpos);
>> }
>> else {
>> new = malloc(lstr + 1);
>> if (!new)
>> return 0;
>> for (strc = 0; strc <= lstr; strc++)
>> new[strc] = str[strc];
>> }
>> return new;
>> }
>>
>> int main(int argc, char **argv) {
>> char *newstr;
>>
>> assert(argc == 4);
>
> I don't think this is a good use of assert. It is almost always
> wrong to use it to check user input. I'd just use an "if".
>
>> newstr = replace(argv[1], argv[2], argv[3]);
>> if (newstr)
>> printf("%s\n", newstr);
>> else
>> printf("replace() -> null\n");
>> free(newstr);
>> return 0;
>> }
>

== 4 of 6 ==
Date: Wed, Feb 17 2010 3:19 am
From: fedora

Hi all!

Here's more session output from gdb... i cant figure out why it crashes for
random strings but not for others...

(gdb) run "askdjfhakdfhakdfhasdjkhaksdfhaklsdjfhlakfhlakfhaklfh" "ask" "+"
Starting program: /home/fedora/c/replace
"askdjfhakdfhakdfhasdjkhaksdfhaklsdjfhlakfhlakfhaklfh" "ask" "+"

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400648 in strFirstCh (str=0x7fffe11e6ff5 "ce", ch=97 'a',
lstr=18446744073709551559) at replace.c:17
17 if (str[current] == ch) {
(gdb) run
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaskadhfklajsdhfkajfhklajdfhjkafhkdf"
"a" "+"
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/fedora/c/replace
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaskadhfklajsdhfkajfhklajdfhjkafhkdf"
"a" "+"
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++sk+dhfkl+jsdhfk+jfhkl+jdfhjk+fhkdf

Program exited normally.
(gdb)

i can see that str and lstr are getting corrupt but i cant see where in my
code that is happening... and putting lots of printfs into is really
discouraging.

thanks.

== 5 of 6 ==
Date: Wed, Feb 17 2010 3:58 am
From: fedora

Hi all!

now I added two printf calls to strSubstr and allSubstr to trace where str
and lstr are getting wrong values.

I also added one if statement to check if adding step to str would result in
it going beyond str+lstr. that is :-

if (((orig_str + orig_lstr) - str) <= step) break;

below is full code and run in gdb with still seg fault. suddenly lstr is
getting i can see, but which statement is doing that i can't see:(

#include <stdlib.h>
#include <stdio.h>
#include <assert.h>

size_t strLength(char *cstr) {
size_t index = 0;

while (cstr[index] != '\0') ++index;
return index;
}

char *strFirstCh(char *str, char ch, size_t lstr) {
char *chpos = 0;
size_t current;

for (current = 0; current < lstr; current++) {
if (str[current] == ch) {
chpos = str + current;
break;
}
}
return chpos;
}

int strComp(char *s, char *t, size_t len) {
int ret = 0;
size_t index;

for (index = 0; index < len; index++) {
if (s[index] != t[index]) {
ret = 1;
break;
}
}
return ret;
}

char *strSubstr(
char *str,
char *sub,
size_t lstr,
size_t lsub) {
char *substr = 0;
char *anchor = str;
size_t remaining_len = (lstr - lsub) + 1;

assert(str && sub && lstr && lsub && lstr >= lsub);
printf("in strSubstr: str = %p\tlstr = %zu\n", (void*)str, lstr);

while (remaining_len > 0 && anchor) {
if (anchor = strFirstCh(anchor, *sub, remaining_len)) {
if (strComp(anchor, sub, lsub) == 0) {
substr = anchor;
break;
}
anchor++;
remaining_len--;
}
}
return substr;
}

unsigned allSubstr(
char *str,
char *sub,
size_t lstr,
size_t lsub,
char ***ps,
int overlap) {
unsigned occurs = 0;
unsigned ctr;
char *orig_str = str;
size_t orig_lstr = lstr;
size_t step;

if (overlap == 1)
step = 1;
else
step = lsub;

while (lstr >= lsub) {
str = strSubstr(str, sub, lstr, lsub);
if (str == 0)
break;
occurs++;
if (((orig_str + orig_lstr) - str) <= step) break;
str += step;
lstr = (orig_str + orig_lstr) - str;
printf("in allSubstr: str = %p\tlstr = %zu\n", (void*)str, lstr);
}

if (occurs > 0 && ps) {
str = orig_str;
lstr = orig_lstr;
*ps = malloc(occurs * sizeof **ps);
if (*ps) {
for (ctr = 0; ctr < occurs; ctr++) {
ps[0][ctr] = str = strSubstr(str, sub, lstr, lsub);
str += step;
lstr = (orig_str + orig_lstr) - str;
}
}
}
return occurs;
}

char *replace(char *str, char *substr, char *rep) {
char *new = 0;
size_t lstr, lsubstr, lrep, lnew, strc, newc, repc, replaced;
unsigned replacements;
char **subpos;

assert(str && substr && rep);
lstr = strLength(str);
lsubstr = strLength(substr);
lrep = strLength(rep);
if (lstr == 0 || lsubstr == 0 || lsubstr > lstr)
return 0;
replacements = allSubstr(str, substr, lstr, lsubstr, &subpos, 0);
if (replacements > 0) {
lnew = (lstr - (replacements * lsubstr)) + (replacements * lrep);
new = malloc(lnew + 1);
if (!new) {
free(subpos);
return 0;
}
strc = newc = replaced = 0;
while (strc <= lstr) {
if (replaced < replacements && str + strc == subpos[replaced]) {
for (repc = 0; repc < lrep; repc++) {
new[newc] = rep[repc];
newc++;
}
replaced++;
strc += lsubstr;
}
else {
new[newc] = str[strc];
strc++;
newc++;
}
}
free(subpos);
}
else {
new = malloc(lstr + 1);
if (!new)
return 0;
for (strc = 0; strc <= lstr; strc++)
new[strc] = str[strc];
}
return new;
}

int main(int argc, char **argv) {
char *newstr;

assert(argc == 4);
newstr = replace(argv[1], argv[2], argv[3]);
if (newstr)
printf("%s\n", newstr);
else
printf("replace() -> null\n");
free(newstr);
return 0;
}

# gdb ./replace
(gdb) run "asdkhfaklsdjfhakldfhaklsdjfhakldfhakldfhaskldfh" "asd" "+"
Starting program: /home/fedora/c/replace
"asdkhfaklsdjfhakldfhaklsdjfhakldfhakldfhaskldfh" "asd" "+"
in strSubstr: str = 0x7fff646a86e4 lstr = 47
in allSubstr: str = 0x7fff646a86e7 lstr = 44
in strSubstr: str = 0x7fff646a86e7 lstr = 44
in allSubstr: str = 0x7fff646a8717 lstr = 18446744073709551612
in strSubstr: str = 0x7fff646a8717 lstr = 18446744073709551612

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400698 in strFirstCh (str=0x7fff646a8ff5 "ce", ch=97 'a',
lstr=18446744073709551559) at replace.c:17
17 if (str[current] == ch) {

(gdb) run "asdkhfaklsdjfhakldfhaklsdjfhakldfhakldfhaskldfh" "as" "+"
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/fedora/c/replace
"asdkhfaklsdjfhakldfhaklsdjfhakldfhakldfhaskldfh" "as" "+"
in strSubstr: str = 0x7fff27e376e5 lstr = 47
in allSubstr: str = 0x7fff27e376e7 lstr = 45
in strSubstr: str = 0x7fff27e376e7 lstr = 45
in allSubstr: str = 0x7fff27e3770f lstr = 5
in strSubstr: str = 0x7fff27e3770f lstr = 5
in strSubstr: str = 0x7fff27e376e5 lstr = 47
in strSubstr: str = 0x7fff27e376e7 lstr = 45
+dkhfaklsdjfhakldfhaklsdjfhakldfhakldfh+kldfh

Program exited normally.

as its shown using "as" for sub-string instead of "asd" makes it work ok.
somewhere some length calculation is getting wrapped around but am not able
to pin point...

thanks all.

== 6 of 6 ==
Date: Wed, Feb 17 2010 4:25 am
From: Walter Banks

Branimir Maksimovic wrote:

> All in all it seems that g++ is 6 times faster than gcc and also
> java server is slightly faster than gcc according to this benchmark.
> I guess they don't test different algorithms, rather same algorihtm
> in different language implementations, but I could be wrong.
> According to this C is slower than java and both consumes more memory
> than c++ and is 6 times slower for same algorithm?
>
> http://shootout.alioth.debian.org/u64/performance.php?test=knucleotide&sort=fullcpu
>
> Ã— Program Source Code CPU secs Elapsed secs Memory KB Code B
> â‰ˆ CPU Load
> 1.0 C++ GNU g++ #6 11.22 11.23 142,288 3415 0% 0% 0% 100%
> 2.0 C++ GNU g++ 22.30 22.30 135,788 2106 0% 0% 0% 100%
> 3.1 Ada 2005 GNAT #2 34.30 34.36 256,660 4865 0% 0% 0% 100%
> 4.2 Java 6 -server #2 47.33 47.41 490,660 1602 0% 0% 0% 100%
> 5.0 Java 6 -server 56.15 56.29 1,295,096 1330 0% 0% 0% 100%
> 5.0 C GNU gcc #6 56.21 56.25 180,540 2439 0% 0% 0% 100%

> According to this C is slower than java and both consumes more memory
> than c++ and is 6 times slower for same algorithm?

The stats that are quoted are for GNU. At the risk of causing a flame war
this far from a state of the art compiler.

The shootout benchmarks have done a lot to highlight the language
component to code generation.

Regards

Walter..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com

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

== 1 of 3 ==
Date: Wed, Feb 17 2010 2:21 am
From: Malcolm McLean

On Feb 17, 11:15 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 17 Feb, 00:22, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
>
> > That is correct, but the string manager can cache an index randomly in
> > the string.
>
> I've no idea what that means
>
With a canonical linked list, one must always start traversing the
list at the head, and continue following links until one has got the
data one wants.

However it's possible to store additional pointers to points along the
list. So, for instance, if we have a linked list of 1000 entries, we
could have extra pointers at 100, 200, 300 and so on. To get to link
202, one simply checks the extra pointers (two comparisons), jumps
into the list at node 200, and carries along to 202 (3 comparisons),
thous retrieving the information in 5 comparisons instead of 203.

== 2 of 3 ==
Date: Wed, Feb 17 2010 2:32 am
From: Branimir Maksimovic

Malcolm McLean wrote:
> On Feb 17, 11:15 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
>> On 17 Feb, 00:22, spinoza1111 <spinoza1...@yahoo.com> wrote:
>>
>>
>>> That is correct, but the string manager can cache an index randomly in
>>> the string.
>> I've no idea what that means
>>
> With a canonical linked list, one must always start traversing the
> list at the head, and continue following links until one has got the
> data one wants.
>
> However it's possible to store additional pointers to points along the
> list. So, for instance, if we have a linked list of 1000 entries, we
> could have extra pointers at 100, 200, 300 and so on. To get to link
> 202, one simply checks the extra pointers (two comparisons), jumps
> into the list at node 200, and carries along to 202 (3 comparisons),
> thous retrieving the information in 5 comparisons instead of 203.
>
Are we reinventing the weal?

http://www.sgi.com/tech/stl/Rope.html

Greets

== 3 of 3 ==
Date: Wed, Feb 17 2010 3:22 am
From: Tim Streater

On 17/02/2010 00:08, spinoza1111 wrote:
> On Feb 17, 7:00 am, Tim Streater<timstrea...@waitrose.com> wrote:
>> On 16/02/2010 07:32,spinoza1111wrote:
>>
>>> On Feb 16, 12:21 am, Tim Streater<timstrea...@waitrose.com> wrote:
>>>> Which myth is that then? I'm dealing with reality - that of being left
>>>> with an undocumented mess to look after, because the clown in question
>>>> preferred to do something "cool" and "neat", rather than what he was
>>>> paid to do.
>>
>>> What was he paid to do? Something hot and sloppy?
>>
>> I observe that, like all fascists, you see the world in terms of black
>> and white. No - he was paid to do an adequate and workmanlike job,
>> taking data output from one program and changing it to be suitable to be
>> input by another. A few pages of code at most, and not worth
>> generalising since the whole suite was likely to be ditched within a
>> year or so.
>>
>> We don't need "War and Peace" when the sixpenny paperback does the job
>> just as well.
>
> The problem is that it's always like that. Management never wants to
> invest enough.

What management may or may not want to do in general is neither here nor
there, like most of your observations. In this particular instance,
management wanted to invest just the right amount, but got something
they hadn't asked for and that was pretty useless once the guy had left.

> The guy may have been a fool. But I regard these stories as primarily
> myths, since in all probability you weren't any more qualified than he
> to tell what was needed.

Oh, "in all probability", eh? You have evidence to support this, do you?
(other then your usual b/s, I mean).

The guy was not a fool and his product worked. But the fact that it
needed him to make any modifications and turned into a black box once he
left, is proof enough that I was perfectly qualified to tell better that
he what was needed.

>>>> By the way, I don't object to his doing something "cool" and "neat", but
>>>> on his own time, OK?
>>
>>> But on the job we must produce crap at speed?
>>
>> See above.
>>
>>>> Well, gee, life's a bitch sometimes, ain't it though! I'll let the good
>>>> people of Haiti know that while they might think *they* have problems,
>>>> poor Spinny has to deal with feof().
>>
>>> Haiti? OK, an old argument: don't complain about anything, you have no
>>> right given "the weight of the world". The problem being that Haiti's
>>> problems were CAUSED by US corporations in the same system in which
>>> they don't give programmers, *as a matter of principle* enough time to
>>> do a quality job.
>>
>> Gosh, US Corps can trigger earthquakes, eh? Marvellous, what will they
>> think of next?
>
> Read history. Haiti was in permanent debt as a result of being forced
> by the US, Britain and France to pay "reparations for slavery" AS THE
> SLAVE SOCIETY in 1825:

Yes, I know about this thanks very much. But any society having an
earthquake like they had would be buggered, US Corps or not.

--
Tim

"That the freedom of speech and debates or proceedings in Parliament
ought not to be impeached or questioned in any court or place out of
Parliament"

Bill of Rights 1689

==============================================================================
TOPIC: decoding a declaration
http://groups.google.com/group/comp.lang.c/t/259df4a3d0342511?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Feb 17 2010 2:26 am
From: Nick Keighley

On 16 Feb, 22:55, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> "t" <t...@t.com> writes:
> >I am trying to decode a declaration "void *(*p[]) (void *a, int n)"
>
> >Or am I missing something? Which would be a good book
> >to understand how to decode such declarations?

K&R?

> There are enough web pages on the subject, and there is the
> cdecl or gcc source code for a formal definition, but I'd
> like to add one idead of my own:
>
> The above starts with »void«, so this means:
>
> »void is the type of the expression *( *p[ 0 ])( 0, 0 ).«.
>
> From that, you can deduce the type of p.

I have the uneasy feeling you skipped a few stages...

> >Sorry, if my question is naive, but I feel bad and think i should
> >improve my skills, if i have doubts
>
> What ever happens, you must never feel bad,

but don't feel bad if you do

> because that
> will degrade your productivity. So, first of all, you need
> to reconstitute high spirits. The good mood must be upheld
> whatever your capabilities regarding C are.

this reminds me of the teacher who told me, when I was 6, not to be
afraid of dogs as they can smell your fear

== 2 of 3 ==
Date: Wed, Feb 17 2010 2:37 am
From: "Alf P. Steinbach"

* Nick Keighley:
> On 16 Feb, 22:55, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
>> because that
>> will degrade your productivity. So, first of all, you need
>> to reconstitute high spirits. The good mood must be upheld
>> whatever your capabilities regarding C are.
>
> this reminds me of the teacher who told me, when I was 6, not to be
> afraid of dogs as they can smell your fear

And a C or C++ compiler really can smell your fear.

As soon as it does it starts playing all sorts of nasty tricks on you, reporting
errors where none are, even in the wrong files; for C++ burying the relevant
information in avalanches of template gobbledegook; fouling up and refusing to
understand your self-evidently correct pointer casts; etc., etc., even, when on
occasion it does find a real error, trying to trick you into believing that it's
not an error in the code, but instead reporting an Internal Compiler Error.

The cure is in all cases to feed it goodly portion of Pascal source code until
it understands who's master.

Cheers,

- Alf

== 3 of 3 ==
Date: Wed, Feb 17 2010 2:46 am
From: Nick Keighley

On 17 Feb, 10:37, "Alf P. Steinbach" <al...@start.no> wrote:
> * Nick Keighley:
> > On 16 Feb, 22:55, r...@zedat.fu-berlin.de (Stefan Ram) wrote:

> >> [What ever happens, you must never feel bad,]
> >> because that
> >> will degrade your productivity. So, first of all, you need
> >> to reconstitute high spirits. The good mood must be upheld
> >> whatever your capabilities regarding C are.
>
> > this reminds me of the teacher who told me, when I was 6, not to be
> > afraid of dogs as they can smell your fear
>
> And a C or C++ compiler really can smell your fear.
>
> As soon as it does it starts playing all sorts of nasty tricks on you, reporting
> errors where none are, even in the wrong files; for C++ burying the relevant
> information in avalanches of template gobbledegook; fouling up and refusing to
> understand your self-evidently correct pointer casts; etc., etc., even, when on
> occasion it does find a real error, trying to trick you into believing that it's
> not an error in the code, but instead reporting an Internal Compiler Error.
>
> The cure is in all cases to feed it goodly portion of Pascal source code until
> it understands who's master.

I had always suspected this

==============================================================================
TOPIC: derived-type object
http://groups.google.com/group/comp.lang.c/t/cfab7b19dac62701?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Feb 17 2010 2:30 am
From: Phred Phungus

Nick Keighley wrote:
> On 17 Feb, 01:41, pac...@kosh.dhis.org (Alan Curry) wrote:
>> In article <lnvddwaei7....@nuthaus.mib.org>,
>> Keith Thompson <ks...@mib.org> wrote:
>
>> |The difference is that the math library is part of the C standard;
>> |those other libraries are not.
>>
>> So what? Nobody writes a C implementation exclusively for programs conforming
>> to that standard.
>
> no, but /everyone/ writes a C implementation for programs conforming
> to that standard!

I think you might emphasize /whichever standard/ instead of everyone.
>
>
>> You're just arguing that an arbitrary list of functions
>> deserves special treatment because the list came out of your favorite
>> committee.
>
> yes

I'm thinking that Alan could make a stronger case here, but then I still
risk that triple-whoosh.
--
fred

== 2 of 4 ==
Date: Wed, Feb 17 2010 2:38 am
From: Phil Carmody

pacman@kosh.dhis.org (Alan Curry) writes:
> In article <lnvddwaei7.fsf@nuthaus.mib.org>,
> Keith Thompson <kst-u@mib.org> wrote:
> |
> |The difference is that the math library is part of the C standard;
> |those other libraries are not.
>
> So what? Nobody writes a C implementation exclusively for programs conforming
> to that standard. You're just arguing that an arbitrary list of functions
> deserves special treatment because the list came out of your favorite
> committee.

When discussing use of a language defined by a particular committee,
there's _nothing_ arbitrary about using the output of that committee
in the context of that language to decide behaviour of the tools.

Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

== 3 of 4 ==
Date: Wed, Feb 17 2010 2:56 am
From: Ben Bacarisse

Phred Phungus <Phred@example.invalid> writes:

> Richard Heathfield wrote:
>> Phred Phungus wrote:
>> <snip>
>>
>>> In compiling the drivers, I stumbled on a couple things:
>>>
>>> $ gcc dl1.o -D_GNU_SOURCE -Wall -Wextra dl2.c -lm -o out
>>> dl2.c: In function 'main':
>>> dl2.c:170: warning: missing braces around initializer
>>
>> gcc is warning you about a non-problem. The = {0} idiom is perfectly
>> good C.
>
> What is the warning trying to say? I do see braces and think that the
> statement could be called one of initialization. Of what horrible
> thing does it want to make me mindful?

It is telling you that the initialiser does not have enough "depth".
CITY is a struct containing two arrays and two numbers so gcc expects
an initialiser that looks like this:

{{0}, {0}, 0, 0}

(alternatively, {"", "", 0, 0}). If you simply add {}s and use {{0}}
gcc will tell you (with these selected warnings) that you are now
missing an initialiser.

--
Ben.

== 4 of 4 ==
Date: Wed, Feb 17 2010 3:17 am
From: Phred Phungus

Oliver Jackson wrote:
> On Feb 16, 5:41 pm, pac...@kosh.dhis.org (Alan Curry) wrote:
>> In article <lnvddwaei7....@nuthaus.mib.org>,
>> Keith Thompson <ks...@mib.org> wrote:
>> |
>> |The difference is that the math library is part of the C standard;
>> |those other libraries are not.
>>
>> So what? Nobody writes a C implementation exclusively for programs conforming
>> to that standard. You're just arguing that an arbitrary list of functions
>> deserves special treatment because the list came out of your favorite
>> committee.
>
> BOOYA - finally some common sense! What I want to know is that how
> come it took this long for you to rilize this. But welcome to the club
> dog.They really ought a split the standard lib into lots of mini-libs
> like stdio, stdlib, string, ..., - and then you keep the way and have
> to type them all in again at linky time.
>

I find linking difficult.

==============================================================================
TOPIC: defining a boolean type
http://groups.google.com/group/comp.lang.c/t/fcfa31f0e0473e4f?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Feb 17 2010 2:31 am
From: Nick Keighley

On 17 Feb, 00:23, Flash Gordon <s...@spam.causeway.com> wrote:

> I've always thought that false being less than true (false<true) has a
> certain linguistic elegance, and also provides an easy way to remember
> which has what value.

oh my god! he's muddled his axiomisations!

== 2 of 3 ==
Date: Wed, Feb 17 2010 2:33 am
From: Nick Keighley

On 17 Feb, 10:31, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 17 Feb, 00:23, Flash Gordon <s...@spam.causeway.com> wrote:
>
> > I've always thought that false being less than true (false<true) has a
> > certain linguistic elegance, and also provides an easy way to remember
> > which has what value.
>
> oh my god! he's muddled his axiomisations!

http://en.wikipedia.org/wiki/Boolean_algebra_(structure)

== 3 of 3 ==
Date: Wed, Feb 17 2010 2:52 am
From: Phred Phungus

Nick Keighley wrote:
> On 17 Feb, 10:31, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
>> On 17 Feb, 00:23, Flash Gordon <s...@spam.causeway.com> wrote:
>>
>>> I've always thought that false being less than true (false<true) has a
>>> certain linguistic elegance, and also provides an easy way to remember
>>> which has what value.
>> oh my god! he's muddled his axiomisations!
>
> http://en.wikipedia.org/wiki/Boolean_algebra_(structure)

Nice page.

I have no idea how wiki happens, yet I consider it this huge advance in
information evangelism.

--
fred

==============================================================================
TOPIC: Warning to newbies
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 17 2010 2:43 am
From: Nick Keighley

On 17 Feb, 09:21, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Feb 16, 5:50 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
> > On 16 Feb, 05:49,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > [...]
>
> > > Replace "egregious" by "x" in "egregious"
> > > Expect "x":
> > > "x"
>
> > > Replace "egregious" by "x" in ""
> > > Expect "":
> > > ""

> > > Testing complete: check output carefully
>
> > you could avoid this by making your test subroutine do the check for
> > you. The TDD people rave about this. Plauger's Library book uses
> > assert() as a simple test harness.
>
> Good point, but: there's always at some point where the rubber meets
> the road, and a human bean has to step up and check things. I like
> looking over the test cases. What would test the compare test?
> Infinite regress.

I generally run a simple case where a human checks the output. Or I
run a case that is supposed to fail. Humans are poor at checking
repetitive things so if your test harness output went on for pages or
had to be run many times I'd distrust a purely human checked result. A
human could certify the test subroutine was ok by inspection. This
only has to be done once.

--
<shrug> Repeat the mantra: "All software sucks". Software,
regardless of the
language or OS, is being used to handle real-world, life-or-death
problems.
THAT should cause fear, except that the alternative is for every
single
emergency to be handled entirely by humans... <shudder>

==============================================================================
TOPIC: Motivation of software professionals
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 17 2010 2:57 am
From: Nick Keighley

On 17 Feb, 08:50, Branimir Maksimovic <bm...@hotmail.com> wrote:
> Nick Keighley wrote:

<snip>

> >> I think that are very few people who know ho to program computers these
> >> days.
>
> > "The Earth is degenerating these days. Bribery and corruption abound.
> > Children no longer mind their parents ... and it is evident that the
> > end of the world is fast approaching."
> > -- Assyrian stone tablet, c.2800bc
>
> What is the point?
> Average Joe makes memory leaks in Java no problem...
> these days...
> Software gets more bloated, more and more bugs, ...

I was noting the fixed point in the human experience. Things are
degenerating and were always better in the past.

<snip>

== 2 of 2 ==
Date: Wed, Feb 17 2010 3:11 am
From: Branimir Maksimovic

Nick Keighley wrote:
>
> I was noting the fixed point in the human experience. Things are
> degenerating and were always better in the past.
>
> <snip>

To be honest things were always simpler in the past.

Greets

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

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 17, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts