Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #74409 > unrolled thread

The C Containers library

Back to article view | Back to comp.lang.c

Contents

  The C Containers library jacobnavia <jacob@jacob.remcomp.fr> - 2015-10-31 09:00 +0100
    Re: The C Containers library Noob <root@127.0.0.1> - 2015-10-31 10:22 +0100
      Re: The C Containers library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-31 02:46 -0700
      Re: The C Containers library jacobnavia <jacob@jacob.remcomp.fr> - 2015-10-31 16:41 +0100
    Re: The C Containers library Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-10-31 12:48 +0100
      Re: The C Containers library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 12:21 +0000
        Re: The C Containers library Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-10-31 14:31 +0100
      Re: The C Containers library Noob <root@127.0.0.1> - 2015-10-31 13:35 +0100
        Re: The C Containers library Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-10-31 14:33 +0100
      Re: The C Containers library jacobnavia <jacob@jacob.remcomp.fr> - 2015-10-31 16:45 +0100
      Re: The C Containers library Keith Thompson <kst-u@mib.org> - 2015-10-31 13:46 -0700
        Re: The C Containers library Robert Wessel <robertwessel2@yahoo.com> - 2015-11-01 01:31 -0500
          Re: The C Containers library Ian Collins <ian-news@hotmail.com> - 2015-11-01 20:34 +1300
            Re: The C Containers library Robert Wessel <robertwessel2@yahoo.com> - 2015-11-01 01:38 -0500
          Re: The C Containers library Keith Thompson <kst-u@mib.org> - 2015-11-01 01:22 -0800
        Re: The C Containers library Richard Heathfield <rjh@cpax.org.uk> - 2015-11-01 09:20 +0000
          Re: The C Containers library supercat@casperkitty.com - 2015-11-01 07:51 -0800
            Re: The C Containers library gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-01 15:57 +0000
            Re: The C Containers library jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-01 17:41 +0100
              Re: The C Containers library gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-01 16:53 +0000
              Re: The C Containers library Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-01 12:01 -0500
                Re: The C Containers library jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-01 22:44 +0100
        Re: The C Containers library Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-11-05 11:16 +0100
          Re: The C Containers library Keith Thompson <kst-u@mib.org> - 2015-11-05 09:24 -0800
    Re: The C Containers library jacobnavia <jacob@jacob.remcomp.fr> - 2015-10-31 16:23 +0100
      Re: The C Containers library Melzzzzz <mel@zzzzz.com> - 2015-10-31 16:33 +0100
        Re: The C Containers library Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-31 11:51 -0700
          Re: The C Containers library Melzzzzz <mel@zzzzz.com> - 2015-10-31 22:04 +0100
      Re: The C Containers library Noob <root@127.0.0.1> - 2015-10-31 19:29 +0100
    Re: The C Containers library Keith Thompson <kst-u@mib.org> - 2015-10-31 13:40 -0700
    Re: The C Containers library "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-11-01 12:09 -0800
      Re: The C Containers library jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-01 22:39 +0100
        Re: The C Containers library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 22:50 +0000
          Re: The C Containers library jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-02 00:07 +0100
            Re: The C Containers library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-01 23:38 +0000
    Re: The C Containers library fir <profesor.fir@gmail.com> - 2015-11-01 16:11 -0800
      Re: The C Containers library fir <profesor.fir@gmail.com> - 2015-11-02 08:15 -0800
    Re: The C Containers library fir <profesor.fir@gmail.com> - 2015-11-01 16:27 -0800
      Re: The C Containers library fir <profesor.fir@gmail.com> - 2015-11-01 16:36 -0800

Page 1 of 2  [1] 2  Next page →

#74409 — The C Containers library

Recently, discussing in the C++ group, somebody wrote:

Now the challenge is:

"You have a file with an unknown number of text lines of variable
lengths. Read the lines and write them out sorted in another file.

Please do this in less than 10x the number of lines of C code, and make
it run faster."


The C++ solution:------------------------------------------
#include <vector>
#include <fstream>
#include <algorithm>
#include <string>

using namespace std;

int main(int argc,char* argv[])
{
     char* file = argv[2];    // input file name
     char* ofile = argv[3];   // output file name

     vector<string> buf;

     fstream fin(file, ios::in);
     string d;
     while(getline(fin, d)) buf.push_back(d);  //add line to buf

     sort(buf.begin(), buf.end());

     fstream fout(ofile, ios::out);
     copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));

}

The C solution---------------------------------------------

#include <containers.h>

int main(void)
{
     strCollection *myData =
         strCollection.CreateFromFile("mydata.txt");
     strCollection.Sort(myData);
     strCollection.WriteToFile(myData,"mySortedData.txt");
     return 0;
}


We can see that the solution in C is just as short as the C++ solution. 
The C containers library allows C programmers to have the same level of 
abstraction than C++ in a key feature: containers.

The C containers library is written in C and features nice stuff. Fully 
open source (no license) available at:

https://code.google.com/p/ccl/

[toc] | [next] | [standalone]

#74415

On 31/10/2015 09:00, jacobnavia wrote:

> Recently, discussing in the C++ group, somebody wrote:
> 
> Now the challenge is:
> 
> "You have a file with an unknown number of text lines of variable
> lengths. Read the lines and write them out sorted in another file.
> 
> Please do this in less than 10x the number of lines of C code, and make
> it run faster."

That is one stupid problem statement.

> The C containers library is written in C and features nice stuff. Fully 
> open source (no license)

Do you mean you've placed the code in the public domain?
There are licenses for that ;-)

https://en.wikipedia.org/wiki/Public_domain_software#Licenses

Regards.

[toc] | [prev] | [next] | [standalone]

#74416

On Saturday, October 31, 2015 at 9:22:50 AM UTC, Noob wrote:
> On 31/10/2015 09:00, jacobnavia wrote:
> 
> > Please do this in less than 10x the number of lines of C code, and make
> > it run faster."
> 
> That is one stupid problem statement.
> 
If speed is our priority there are things we can do to make a C
function run faster. For example, we can slurp in the file in
one go (if we're prepared to accept a technical portability
glitch). We can then do two passes, one to count the newlines,
and one to create the newline pointer buffer. Then we call the
sort with a hard-coded strcmp.
However it's a lot of code, and there's seldom much point 
writing routine code such as file sorts like that (unless
user is sorting lots of files on the fly, he won't see any
real benefit, if he's sorting huge files we probably need
to provide an out of memory sort anyway). 

[toc] | [prev] | [next] | [standalone]

#74441

Le 31/10/2015 10:22, Noob a écrit :
>> Recently, discussing in the C++ group, somebody wrote:
>> >
>> >Now the challenge is:
>> >
>> >"You have a file with an unknown number of text lines of variable
>> >lengths. Read the lines and write them out sorted in another file.
>> >
>> >Please do this in less than 10x the number of lines of C code, and make
>> >it run faster."
> That is one stupid problem statement.
>

"This is an example from one of Bjarne's papers:" said the guy in the 
C++ forums...

[toc] | [prev] | [next] | [standalone]

#74423

On 31.10.2015 09:00, jacobnavia wrote:

> The C++ solution:------------------------------------------
> #include <vector>
> #include <fstream>
> #include <algorithm>
> #include <string>
> 
> using namespace std;
> 
> int main(int argc,char* argv[])
> {
>     char* file = argv[2];    // input file name
>     char* ofile = argv[3];   // output file name
> 
>     vector<string> buf;
> 
>     fstream fin(file, ios::in);
>     string d;
>     while(getline(fin, d)) buf.push_back(d);  //add line to buf
> 
>     sort(buf.begin(), buf.end());
> 
>     fstream fout(ofile, ios::out);
>     copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));
> 
> }

Doesn't compile for me. Has probably UB (return missing).

$ g++ -Wall -std=c++11 -O3 foo.cpp
foo.cpp: In function ‘int main(int, char**)’:
foo.cpp:22:34: error: ‘ostream_iterator’ was not declared in this scope
     copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));
                                  ^
foo.cpp:22:57: error: expected primary-expression before ‘>’ token
     copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));
                                                         ^
foo.cpp:22:64: warning: left operand of comma operator has no effect
[-Wunused-value]
     copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));
                                                             ^
> The C solution---------------------------------------------
> 
> #include <containers.h>
> 
> int main(void)
> {
>     strCollection *myData =
>         strCollection.CreateFromFile("mydata.txt");
>     strCollection.Sort(myData);
>     strCollection.WriteToFile(myData,"mySortedData.txt");
>     return 0;
> }

Doesn't compile for me.

$ gcc -O3 -Wall foo.c -I .
foo.c: In function ‘main’:
foo.c:7:9: error: expected expression before ‘strCollection’
         strCollection.CreateFromFile("mydata.txt");
         ^
foo.c:8:18: error: expected identifier or ‘(’ before ‘.’ token
     strCollection.Sort(myData);
                  ^
foo.c:9:18: error: expected identifier or ‘(’ before ‘.’ token
     strCollection.WriteToFile(myData,"mySortedData.txt");
                  ^
foo.c:6:20: warning: unused variable ‘myData’ [-Wunused-variable]
     strCollection *myData =
                    ^

gcc/g++ 4.8 on Linux x86_64. No idea why g++ doesn't find
std::ostream_iterator. No idea at all how I'm supposed to debug the
"ccl" code.

It would be super helpful if you would post code that can actually be
compiled so one can check performance (that's something you completely
omitted, even though it's in the original problem description)

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#74425

Johannes Bauer <dfnsonfsduifb@gmx.de> writes:

> On 31.10.2015 09:00, jacobnavia wrote:
>
>> The C++ solution:------------------------------------------
>> #include <vector>
>> #include <fstream>
>> #include <algorithm>
>> #include <string>
>> 
>> using namespace std;
>> 
>> int main(int argc,char* argv[])
>> {
>>     char* file = argv[2];    // input file name
>>     char* ofile = argv[3];   // output file name
>> 
>>     vector<string> buf;
>> 
>>     fstream fin(file, ios::in);
>>     string d;
>>     while(getline(fin, d)) buf.push_back(d);  //add line to buf
>> 
>>     sort(buf.begin(), buf.end());
>> 
>>     fstream fout(ofile, ios::out);
>>     copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));
>> 
>> }
>
> Doesn't compile for me. Has probably UB (return missing).
>
> $ g++ -Wall -std=c++11 -O3 foo.cpp
> foo.cpp: In function ‘int main(int, char**)’:
> foo.cpp:22:34: error: ‘ostream_iterator’ was not declared in this scope
>      copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));
>                                   ^
> foo.cpp:22:57: error: expected primary-expression before ‘>’ token
>      copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));
>                                                          ^
> foo.cpp:22:64: warning: left operand of comma operator has no effect
> [-Wunused-value]
>      copy(buf.begin(), buf.end(),
> ostream_iterator<string>(fout,"\n"));

There's a missing #include <iterator>.

>> #include <containers.h>
>> 
>> int main(void)
>> {
>>     strCollection *myData =
>>         strCollection.CreateFromFile("mydata.txt");
>>     strCollection.Sort(myData);
>>     strCollection.WriteToFile(myData,"mySortedData.txt");
>>     return 0;
>> }
>
> Doesn't compile for me.
>
> $ gcc -O3 -Wall foo.c -I .
> foo.c: In function ‘main’:
> foo.c:7:9: error: expected expression before ‘strCollection’
>          strCollection.CreateFromFile("mydata.txt");
>          ^
> foo.c:8:18: error: expected identifier or ‘(’ before ‘.’ token
>      strCollection.Sort(myData);
>                   ^
> foo.c:9:18: error: expected identifier or ‘(’ before ‘.’ token
>      strCollection.WriteToFile(myData,"mySortedData.txt");
>                   ^
> foo.c:6:20: warning: unused variable ‘myData’ [-Wunused-variable]
>      strCollection *myData =
>                     ^

Yes, I get the same errors.  Maybe Jacob has changed his library, but
the version I once looked at needed istrCollection.Whatever.

When both compiled with -O3 they run at about the same speed for at
least one test file (140,000 lines of English text, with average line
length 36 characters).  The C++ one is slightly faster but it's very
close.

Of course, it's an odd test.  C with a high-level string library vs. C++
is not really C vs C++.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#74429

On 31.10.2015 13:21, Ben Bacarisse wrote:

> Yes, I get the same errors.  Maybe Jacob has changed his library, but
> the version I once looked at needed istrCollection.Whatever.

I haven't looked deeply enough in Jacob's code to judge what to fix and
I also don't know C++ iterators well enough that I would have known
which header file to include. In any case, since Jacob is the one
posting the code, it would have been his responsibility to ensure they
actually compile. That neither of the two examples actually worked is
just annoying.

> When both compiled with -O3 they run at about the same speed for at
> least one test file (140,000 lines of English text, with average line
> length 36 characters).  The C++ one is slightly faster but it's very
> close.

Interesting, thank you.

> Of course, it's an odd test.  C with a high-level string library vs. C++
> is not really C vs C++.

I agree but was still curious :-)

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#74427

On 31/10/2015 12:48, Johannes Bauer wrote:

> On 31.10.2015 09:00, jacobnavia wrote:
> 
>> #include <containers.h>
>>
>> int main(void)
>> {
>>     strCollection *myData =
>>         strCollection.CreateFromFile("mydata.txt");
>>     strCollection.Sort(myData);
>>     strCollection.WriteToFile(myData,"mySortedData.txt");
>>     return 0;
>> }
> 
> Doesn't compile for me.

Even when fixing the syntax errors, I guess?
(strCollection->foo instead of strCollection.foo)

> $ gcc -O3 -Wall foo.c -I .
> foo.c: In function ‘main’:
> foo.c:7:9: error: expected expression before ‘strCollection’
>          strCollection.CreateFromFile("mydata.txt");
>          ^

Hmmm, what containers.h did your compiler pick up?
https://code.google.com/p/ccl/source/browse/trunk/containers.h

Regards.

[toc] | [prev] | [next] | [standalone]

#74430

On 31.10.2015 13:35, Noob wrote:
> On 31/10/2015 12:48, Johannes Bauer wrote:
> 
>> On 31.10.2015 09:00, jacobnavia wrote:
>>
>>> #include <containers.h>
>>>
>>> int main(void)
>>> {
>>>     strCollection *myData =
>>>         strCollection.CreateFromFile("mydata.txt");
>>>     strCollection.Sort(myData);
>>>     strCollection.WriteToFile(myData,"mySortedData.txt");
>>>     return 0;
>>> }
>>
>> Doesn't compile for me.
> 
> Even when fixing the syntax errors, I guess?
> (strCollection->foo instead of strCollection.foo)

I didn't change anything in the code, but your suggestion also doesn't work:

foo.c: In function ‘main’:
foo.c:7:9: error: expected expression before ‘strCollection’
         strCollection->CreateFromFile("mydata.txt");
         ^
foo.c:8:18: error: expected identifier or ‘(’ before ‘->’ token
     strCollection->Sort(myData);
                  ^
foo.c:9:18: error: expected identifier or ‘(’ before ‘->’ token
     strCollection->WriteToFile(myData,"mySortedData.txt");

>> $ gcc -O3 -Wall foo.c -I .
>> foo.c: In function ‘main’:
>> foo.c:7:9: error: expected expression before ‘strCollection’
>>          strCollection.CreateFromFile("mydata.txt");
>>          ^
> 
> Hmmm, what containers.h did your compiler pick up?
> https://code.google.com/p/ccl/source/browse/trunk/containers.h

$ svn info
Path: .
Working Copy Root Path: /home/joe/tmp/ccl-read-only
URL: http://ccl.googlecode.com/svn/trunk
Relative URL: ^/trunk
Repository Root: http://ccl.googlecode.com/svn
Repository UUID: 296350f9-0297-81ab-4957-b6e6a657bb76
Revision: 283
Node Kind: directory
Schedule: normal
Last Changed Author: jacob@jacob.remcomp.fr
Last Changed Rev: 283
Last Changed Date: 2014-08-27 14:30:19 +0200 (Mi, 27 Aug 2014)

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#74443

Le 31/10/2015 12:48, Johannes Bauer a écrit :
> Doesn't compile for me. Has probably UB (return missing).
>
> $ g++ -Wall -std=c++11 -O3 foo.cpp
> foo.cpp: In function ‘int main(int, char**)’:
> foo.cpp:22:34: error: ‘ostream_iterator’ was not declared in this scope
>       copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));
>                                    ^
> foo.cpp:22:57: error: expected primary-expression before ‘>’ token
>       copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));
>                                                           ^
> foo.cpp:22:64: warning: left operand of comma operator has no effect
> [-Wunused-value]
>       copy(buf.begin(), buf.end(), ostream_iterator<string>(fout,"\n"));

Just include "#include "iterator", the poster in the C++ group forgot that.

It is not an error that difficult to find really...

[toc] | [prev] | [next] | [standalone]

#74493

Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
> On 31.10.2015 09:00, jacobnavia wrote:
>
>> The C++ solution:------------------------------------------
[snip]

> Doesn't compile for me.

Already addressed.

>                         Has probably UB (return missing).

If you're referring to the lack of a return statement at the end of
main(), that's not an issue.  In C++ (as in C starting with C90),
reaching the closing "}" of main() does an implicit `return 0;`.

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

[toc] | [prev] | [next] | [standalone]

#74522

On Sat, 31 Oct 2015 13:46:20 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>> On 31.10.2015 09:00, jacobnavia wrote:
>>
>>> The C++ solution:------------------------------------------
>[snip]
>
>> Doesn't compile for me.
>
>Already addressed.
>
>>                         Has probably UB (return missing).
>
>If you're referring to the lack of a return statement at the end of
>main(), that's not an issue.  In C++ (as in C starting with C90),
>reaching the closing "}" of main() does an implicit `return 0;`.


Was that a change in C90?  In C89 falling off the end of main was
legal, but the value returned to the system was not defined.  C99
defined the return value in that case to be zero.

[toc] | [prev] | [next] | [standalone]

#74523

Robert Wessel wrote:
> On Sat, 31 Oct 2015 13:46:20 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
>
>> Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>>> On 31.10.2015 09:00, jacobnavia wrote:
>>>
>>>> The C++ solution:------------------------------------------
>> [snip]
>>
>>> Doesn't compile for me.
>>
>> Already addressed.
>>
>>>                          Has probably UB (return missing).
>>
>> If you're referring to the lack of a return statement at the end of
>> main(), that's not an issue.  In C++ (as in C starting with C90),
>> reaching the closing "}" of main() does an implicit `return 0;`.
>
>
> Was that a change in C90?  In C89 falling off the end of main was
> legal, but the value returned to the system was not defined.  C99
> defined the return value in that case to be zero.

The code was C++....

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#74524

On Sun, 01 Nov 2015 20:34:17 +1300, Ian Collins <ian-news@hotmail.com>
wrote:

>Robert Wessel wrote:
>> On Sat, 31 Oct 2015 13:46:20 -0700, Keith Thompson <kst-u@mib.org>
>> wrote:
>>
>>> Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>>>> On 31.10.2015 09:00, jacobnavia wrote:
>>>>
>>>>> The C++ solution:------------------------------------------
>>> [snip]
>>>
>>>> Doesn't compile for me.
>>>
>>> Already addressed.
>>>
>>>>                          Has probably UB (return missing).
>>>
>>> If you're referring to the lack of a return statement at the end of
>>> main(), that's not an issue.  In C++ (as in C starting with C90),
>>> reaching the closing "}" of main() does an implicit `return 0;`.
>>
>>
>> Was that a change in C90?  In C89 falling off the end of main was
>> legal, but the value returned to the system was not defined.  C99
>> defined the return value in that case to be zero.
>
>The code was C++....


"(as in C starting with C90)"

[toc] | [prev] | [next] | [standalone]

#74527

Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
>>
>>>                         Has probably UB (return missing).
>>
>>If you're referring to the lack of a return statement at the end of
>>main(), that's not an issue.  In C++ (as in C starting with C90),
>>reaching the closing "}" of main() does an implicit `return 0;`.
>
>
> Was that a change in C90?  In C89 falling off the end of main was
> legal, but the value returned to the system was not defined.  C99
> defined the return value in that case to be zero.

Sorry, that was a typo.  I meant C99.

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

[toc] | [prev] | [next] | [standalone]

#74526

On 31/10/15 20:46, Keith Thompson wrote:

<snip>

> If you're referring to the lack of a return statement at the end of
> main(), that's not an issue.

Well, it's not an "issue" in the sense of requiring a diagnostic 
message. It remains an issue in the sense of being appallingly ugly 
code. If we say we're going to return an int, the least we can do is 
have the courtesy to return an int.

> In C++ (as in C starting with C90),

s/C90/C99/

n'est ce pas?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#74559

On Sunday, November 1, 2015 at 3:20:33 AM UTC-6, Richard Heathfield wrote:
> Well, it's not an "issue" in the sense of requiring a diagnostic 
> message. It remains an issue in the sense of being appallingly ugly 
> code. If we say we're going to return an int, the least we can do is 
> have the courtesy to return an int.

IMHO, the proper "fix" would have been to legitimize "void main(...)" and
say that a function declared in that fashion would return 0 (returning
another status value would require an "exit" call).  Not only would that
make things cleaner in the case where any normal program termination will
return 0, but it would also be useful for programs which will never reach
the end of main.  Having a function declared as returning "int" when there
is no circumstance when it will actually do so seems a little dubious.

[toc] | [prev] | [next] | [standalone]

#74562

In article <f24e397d-7c27-47f5-80e2-0bff746239f1@googlegroups.com>,
 <supercat@casperkitty.com> wrote:
>On Sunday, November 1, 2015 at 3:20:33 AM UTC-6, Richard Heathfield wrote:
>> Well, it's not an "issue" in the sense of requiring a diagnostic 
>> message. It remains an issue in the sense of being appallingly ugly 
>> code. If we say we're going to return an int, the least we can do is 
>> have the courtesy to return an int.
>
>IMHO, the proper "fix" would have been to legitimize "void main(...)" and
>say that a function declared in that fashion would return 0 (returning
>another status value would require an "exit" call).  Not only would that
>make things cleaner in the case where any normal program termination will
>return 0, but it would also be useful for programs which will never reach
>the end of main.  Having a function declared as returning "int" when there
>is no circumstance when it will actually do so seems a little dubious.

+1

-- 
"I have a simple philosophy. Fill what's empty. Empty what's full. And
scratch where it itches."

	Alice Roosevelt Longworth

[toc] | [prev] | [next] | [standalone]

#74569

Le 01/11/2015 16:51, supercat@casperkitty.com a écrit :
> On Sunday, November 1, 2015 at 3:20:33 AM UTC-6, Richard Heathfield wrote:
>> Well, it's not an "issue" in the sense of requiring a diagnostic
>> message. It remains an issue in the sense of being appallingly ugly
>> code. If we say we're going to return an int, the least we can do is
>> have the courtesy to return an int.
>
> IMHO, the proper "fix" would have been to legitimize "void main(...)" and
> say that a function declared in that fashion would return 0 (returning
> another status value would require an "exit" call).  Not only would that
> make things cleaner in the case where any normal program termination will
> return 0, but it would also be useful for programs which will never reach
> the end of main.  Having a function declared as returning "int" when there
> is no circumstance when it will actually do so seems a little dubious.
>

No matter what the subject is, all discussions in this group end with

int main(void)
or
void main(void)

Not a word about the containers library

[toc] | [prev] | [next] | [standalone]

#74571

In article <n15f7v$lj1$1@dont-email.me>,
jacobnavia  <jacob@jacob.remcomp.fr> wrote:
>Le 01/11/2015 16:51, supercat@casperkitty.com a écrit :
>> On Sunday, November 1, 2015 at 3:20:33 AM UTC-6, Richard Heathfield wrote:
>>> Well, it's not an "issue" in the sense of requiring a diagnostic
>>> message. It remains an issue in the sense of being appallingly ugly
>>> code. If we say we're going to return an int, the least we can do is
>>> have the courtesy to return an int.
>>
>> IMHO, the proper "fix" would have been to legitimize "void main(...)" and
>> say that a function declared in that fashion would return 0 (returning
>> another status value would require an "exit" call).  Not only would that
>> make things cleaner in the case where any normal program termination will
>> return 0, but it would also be useful for programs which will never reach
>> the end of main.  Having a function declared as returning "int" when there
>> is no circumstance when it will actually do so seems a little dubious.
>>
>
>No matter what the subject is, all discussions in this group end with
>
>int main(void)
>or
>void main(void)
>
>Not a word about the containers library
>

That - or casting the return value of malloc().

How long have you been reading/posting-to this group now?

-- 
     Modern Christian: Someone who can take time out
     from using Leviticus to defend homophobia and Exodus
     to plaster the Ten Commandments on every school and
     courthouse to claim that the Old Testament is merely
     "ancient laws" that "only applies to Jews".

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web