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

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

The big problem of C

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

Contents

  The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-04 13:41 -0700
    Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-04 23:18 +0200
      Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 14:24 -0700
        Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-04 23:31 +0200
          Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 14:39 -0700
            Re: The big problem of C Bart <bc@freeuk.com> - 2020-04-04 23:08 +0100
          Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-04 16:48 -0700
            Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-04 20:06 -0500
          Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 19:44 +0200
      Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-04 16:40 -0700
        Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-05 01:58 +0200
          Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-04 18:05 -0700
            Re: The big problem of C Ian Collins <ian-news@hotmail.com> - 2020-04-05 15:17 +1200
          Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 09:44 +0200
            Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-05 11:14 +0200
              Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 11:27 +0200
                Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-05 11:34 +0200
                  Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 11:45 +0200
                    Re: The big problem of C nobody@example.org (Scott) - 2020-04-05 16:27 +0000
                      Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 19:38 +0200
            Re: The big problem of C David Brown <david.brown@hesbynett.no> - 2020-04-05 22:19 +0200
              Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 10:16 +0200
                Re: The big problem of C David Brown <david.brown@hesbynett.no> - 2020-04-06 13:36 +0200
                  Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 13:55 +0200
                    Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 05:04 -0700
                      Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 14:11 +0200
                        Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 18:01 +0200
                          Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 22:08 +0200
                            Re: The big problem of C Öö Tiib <ootiib@hot.ee> - 2020-04-06 20:47 -0700
                              Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-07 09:06 +0200
                                Re: The big problem of C already5chosen@yahoo.com - 2020-04-07 05:58 -0700
                                  Re: The big problem of C David Brown <david.brown@hesbynett.no> - 2020-04-07 17:55 +0200
                                  Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-07 19:02 +0200
                                    Re: The big problem of C already5chosen@yahoo.com - 2020-04-07 10:21 -0700
                                      Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-07 20:02 +0200
                                        Re: The big problem of C already5chosen@yahoo.com - 2020-04-07 13:10 -0700
                                    Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-07 22:34 +0200
                                      Railway programming (Was : The big problem of C) Spiros Bousbouras <spibou@gmail.com> - 2020-04-08 00:01 +0000
                                        Re: Railway programming (Was : The big problem of C) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-08 01:11 +0100
                                          Re: Railway programming (Was : The big problem of C) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-08 01:12 +0100
                                            Re: Railway programming (Was : The big problem of C) felix@palmen-it.de (Felix Palmen) - 2020-04-08 09:56 +0200
                                              Re: Railway programming (Was : The big problem of C) Spiros Bousbouras <spibou@gmail.com> - 2020-04-09 11:55 +0000
                                            Re: Railway programming (Was : The big problem of C) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-08 08:17 +0000
                                        Re: Railway programming (Was : The big problem of C) felix@palmen-it.de (Felix Palmen) - 2020-04-08 09:42 +0200
                              Re: The big problem of C already5chosen@yahoo.com - 2020-04-07 06:13 -0700
                                Re: The big problem of C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 09:17 -0700
                                  Re: The big problem of C already5chosen@yahoo.com - 2020-04-07 09:44 -0700
                            Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-07 09:07 +0200
                  Re: The big problem of C Öö Tiib <ootiib@hot.ee> - 2020-04-06 05:01 -0700
                    Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 14:42 +0200
            Re: The big problem of C Bart <bc@freeuk.com> - 2020-04-06 00:09 +0100
              Re: The big problem of C David Brown <david.brown@hesbynett.no> - 2020-04-06 09:09 +0200
        Re: The big problem of C Bart <bc@freeuk.com> - 2020-04-05 12:41 +0100
          Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-05 07:05 -0700
    Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-04 17:48 -0500
      Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-04 17:16 -0700
    Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 09:25 +0200
    Re: The big problem of C jacobnavia <jacob@jacob.remcomp.fr> - 2020-04-05 09:50 +0200
      Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 09:53 +0200
        Re: The big problem of C jacobnavia <jacob@jacob.remcomp.fr> - 2020-04-05 18:00 +0200
          Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 19:35 +0200
            Re: The big problem of C jacobnavia <jacob@jacob.remcomp.fr> - 2020-04-06 08:05 +0200
      Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 04:25 -0700
        Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 13:32 +0200
          Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 04:57 -0700
            Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 14:09 +0200
              Re: The big problem of C chad <cdalten@gmail.com> - 2020-04-05 05:20 -0700
                Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 15:04 +0200
            Re: The big problem of C Öö Tiib <ootiib@hot.ee> - 2020-04-05 05:22 -0700
              Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 05:33 -0700
                Re: The big problem of C Öö Tiib <ootiib@hot.ee> - 2020-04-05 06:55 -0700
            Re: The big problem of C felix@palmen-it.de (Felix Palmen) - 2020-04-05 16:42 +0200
            Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-05 09:57 -0500
      Re: The big problem of C Spiros Bousbouras <spibou@gmail.com> - 2020-04-06 10:46 +0000
        Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 13:14 +0200
    Re: The big problem of C Philipp Klaus Krause <pkk@spth.de> - 2020-04-05 19:00 +0200
      Re: The big problem of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 10:08 -0700
      Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 19:52 +0200
      Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-05 13:37 -0500
        Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-05 20:49 +0200
          Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-05 15:27 -0500
            Re: The big problem of C Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-06 10:14 +0200
      Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-05 12:07 -0700
      Re: The big problem of C Guillaume <message@bottle.org> - 2020-04-06 15:09 +0200
        Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-06 07:02 -0700
          Re: The big problem of C BGB <cr88192@gmail.com> - 2020-04-06 10:30 -0500
            Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-06 09:06 -0700
          Re: The big problem of C Guillaume <message@bottle.org> - 2020-04-06 18:43 +0200
            Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-06 12:19 -0700
              Re: The big problem of C Thiago Adams <thiago.adams@gmail.com> - 2020-04-08 18:27 -0700

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#151097

On 05/04/2020 09:44, Bonita Montero wrote:
>> Well, the typical approach to do it yourself is along the lines of
>>
>>      struct foo
>>      {
>>          size_t size;
>>     size_t capacity;
>>     T *elements;
>>      };
> 
> Show me a C-program that resembles what this code does:
> 
> #include <iostream>
> #include <vector>
> #include <string>
> #include <algorithm>
> 
> using namespace std;
> 
> int main()
> {
>      vector<string> strings;
>      string         strIn;
>      for( ; ; )
>      {
>          getline( cin, strIn );
>          if( strIn.length() != 0 )
>              strings.emplace_back( move( strIn ) );
>          else
>              break;
>      }
>      sort( strings.begin(), strings.end() );
>      for( string &s : strings )
>          cout << s << endl;
> }
> 
> 
> If you want really want the same functionality you'd have
> to write a magnitude more code. C is simply a mess.

In Python, that can be done in two lines:

import fileinput
print('\n'.join(sorted(fileinput.input())))

In a Posix shell, it can be done by "sort".

C++ takes an order of magnitude more code.  C++ is simply a mess.


Or perhaps this is a C newsgroup, and the discussion is about C - not 
C++, not Python, not assembly, or anything else.  Different languages 
have their pros and cons, and different use-cases.

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

#151116

> In Python, that can be done in two lines:
> import fileinput
> print('\n'.join(sorted(fileinput.input())))
> C++ takes an order of magnitude more code.  C++ is simply a mess.

If you need more performance than Pythong or bash,
C++ would be the proper language.

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

#151130

On 06/04/2020 10:16, Bonita Montero wrote:
> 
>> In Python, that can be done in two lines:
>> import fileinput
>> print('\n'.join(sorted(fileinput.input())))
>> C++ takes an order of magnitude more code.  C++ is simply a mess.
> 
> If you need more performance than Pythong or bash,
> C++ would be the proper language.

I ran a quick test with the Complete Works of Shakespeare as a text file 
(thanks, Project Gutenberg!) comparing your C++ program to other solutions:

Linux "sort":
	0.208 s real time, 0.329 s user time (i.e., it is threaded)

C++:
	0.203 s real time, 0.146 s user time

Python 3:
	0.166 s real time, 0.153 s user time

Python 2:
	0.106 s real time, 0.101 s user time

Pypy:
	0.098 s real time, 0.086 s user time


With a file made from 10 copies, the numbers are now:

	
Linux "sort":
	1.6 s real time, 6.6 s user time (i.e., it is threaded)

C++:
	2.2 s real time, 1.5 s user time

Python 3:
	1.8 s real time, 1.7 s user time

Python 2:
	1.3 s real time, 1.3 s user time

Pypy:
	1.2 s real time, 1.1 s user time


With a bigger file, C++ is now the /slowest/ option.  Slower than 
off-the-shelf "sort", slower than Python.  (And yes, the C++ code was 
compiled with optimisation.)

Obviously this is a simple sample.  And obviously different methods have 
their advantages and disadvantages, and all could be optimised or 
specialised in different ways to be better at some sorting while worse 
at others.

For example, a simple C program that can handle up to 10,000,000 lines 
of up to 128 characters can be written:

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

enum { maxLine = 128 };
enum { maxLineCount = 10000000 };

static char lines[maxLineCount][maxLine];
static int indexes[maxLineCount];

int comp(const void * a, const void * b) {
     const int * ap = (const int *) a;
     const int * bp = (const int *) b;
     return strcmp(lines[*ap], lines[*bp]);
}

int main(void) {
     int n = 0;
     while (fgets(lines[n], maxLine - 1, stdin)) n++;

     for (int i = 0; i < n; i++) {
         indexes[i] = i;
     }
     qsort(indexes, n, sizeof(int), comp);
     for (int i = 0; i < n; i++) {
         fputs(lines[indexes[i]], stdout);
     }
}


For the original test file, this gave:

	0.047 s real time, 0.043 s user time

For the ten times bigger file, it gave :

	0.586 s real time, 0.513 s user time

It is about 4 times as fast as the C++ code, and twice as fast as the 
Python code.  But it only works within certain limitations.


What can we see from this?  We can see that anyone who says "language X 
is the fastest" is simplifying so much they are just wrong.  Anyone who 
says "language X is a mess" is doing likewise.

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

#151132

Maybe, but that's not usual.
Check the Computer Languages Benchmark Game.

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

#151134

On Monday, 6 April 2020 12:55:38 UTC+1, Bonita Montero  wrote:
> Maybe, but that's not usual.
> Check the Computer Languages Benchmark Game.
>
C's qsort() takes a comparison function which returns 0, positive,
or negative. Probably designed so that the strcmp() function can
be used very simply on the sort field.
However you can make a sort slightly more efficient if your comparison
function returns true on less than and false on greater than or equal.
That's what the C++ standard library does.

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

#151135

> C's qsort() takes a comparison function which returns 0, positive,
> or negative. Probably designed so that the strcmp() function can
> be used very simply on the sort field.
> However you can make a sort slightly more efficient if your comparison
> function returns true on less than and false on greater than or equal.
> That's what the C++ standard library does.

Maybe it's not the sorting which makes the differnce here but the
input and output of the lines, making the difference in different
buffer-sizes.

This should be faster because there won't be whole string-objects
being moved around but only unique_ptrs to them:

#include <iostream>
#include <vector>
#include <string>
#include <algorithm>
#include <memory>
#include <functional>
using namespace std;

int main()
{
     using up_str = unique_ptr<string>;
     vector<up_str> strings;
     string         strIn;
     for( ; ; )
     {
         getline( cin, strIn );
         if( strIn.length() != 0 )
             strings.emplace_back( move( make_unique<string>( strIn ) ) );
         else
             break;
     }
     sort( strings.begin(), strings.end(), []( up_str &left, up_str 
&right ) { return *left < *right; } );
     for( up_str &s : strings )
         cout << *s << endl;
}

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

#151141

> This should be faster because there won't be whole string-objects
> being moved around but only unique_ptrs to them:
> 
> #include <iostream>
> #include <vector>
> #include <string>
> #include <algorithm>
> #include <memory>
> #include <functional>
> using namespace std;
> 
> int main()
> {
>      using up_str = unique_ptr<string>;
>      vector<up_str> strings;
>      string         strIn;
>      for( ; ; )
>      {
>          getline( cin, strIn );
>          if( strIn.length() != 0 )
>              strings.emplace_back( move( make_unique<string>( strIn ) ) );
>          else
>              break;
>      }
>      sort( strings.begin(), strings.end(), []( up_str &left, up_str 
> &right ) { return *left < *right; } );
>      for( up_str &s : strings )
>          cout << *s << endl;
> }

The main problem with the code is that, under Linux with my gcc /
libstdc++ 81% of the runtime is spent in kernel-mode. So the buffer
-flushes take the most time. But the sort itself shouldn't be faster
in any language.

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

#151156

Ok, this is unbeatable; about three times faster as the code before:

#include <iostream>
#include <fstream>
#include <sstream>
#include <vector>
#include <string>
#include <algorithm>
#include <memory>
#include <functional>
#include <cstring>

using namespace std;

int main( int argc, char **argv )
{
     if( argc != 3 )
         return EXIT_FAILURE;
     try
     {
         ifstream ifs;
         ifs.exceptions( ifstream::failbit | ifstream::badbit );
         ifs.open( argv[1], ifstream::binary );
         ifs.seekg( 0, ios_base::end );
         streampos    fileLength = ifs.tellg();
         vector<char> m_rawStrings( (size_t)fileLength + 1 );
         ifs.seekg( 0, ios_base::beg );
         ifs.read( &m_rawStrings[0], fileLength );
         m_rawStrings[fileLength] = 0;
         size_t nLines      = 0,
                nCharacters = 0;
         // count the number of lines to prevent incremental 
buffer-growing of the "strings"-object
         using vc_it = vector<char>::iterator;
         for( vc_it scn = m_rawStrings.begin(), end = 
m_rawStrings.end(); scn != end; )
         {
             ++nLines;
             do
                 if( *scn == '\r' )
                 {
                     if( ++scn == end )
                         break;
                     if( *scn == '\n' )
                         ++scn;
                     break;
                 }
                 else if( *scn == '\n' )
                 {
                     ++scn;
                     break;
                 }
                 else
                     ++nCharacters;
             while( ++scn != end );
         }
         vector<vc_it>           strings( nLines );
         vector<vc_it>::iterator curString = strings.begin();
         for( vector<char>::iterator scn = m_rawStrings.begin(), end = 
m_rawStrings.end(); scn != end; )
         {
             *curString++ = scn;
             do
                 if( *scn == '\r' )
                 {
                     *scn = 0;
                     if( ++scn == end )
                         break;
                     if( *scn == '\n' )
                         ++scn;
                     break;
                 }
                 else if( *scn == '\n' )
                 {
                     *scn++ = 0;
                     break;
                 }
             while( ++scn != end );
         }
         sort( strings.begin(), strings.end(), []( vc_it left, vc_it 
right ) { return strcmp( &*left, &*right ) < 0; } );
         vector<char> buff;
         buff.resize( nCharacters + nLines );
         size_t lineLength;
         vc_it  wrt = buff.begin();
         for( vc_it str : strings )
             lineLength = strlen( &*str ),
             copy( str, str + lineLength, wrt ),
             wrt += lineLength,
             *wrt++ = '\n';
         ofstream ofs;
         ofs.exceptions( ifstream::failbit | ifstream::badbit );
         ofs.open( argv[2], ofstream::trunc );
         ofs.write( &buff[0], buff.size() );
         return EXIT_SUCCESS;
     }
     catch( exception &exc )
     {
         cout << exc.what() << endl;
         return EXIT_FAILURE;
     }
}

A bittle C-ish because of the memory scan and the raw iterator-list,
but the containers and the exception-handling save a lot of code.
And having iterators helps debugging because you can switch to
bounds-checked iterators.

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

#151168

On Monday, 6 April 2020 23:08:19 UTC+3, Bonita Montero  wrote:
> Ok, this is unbeatable; about three times faster as the code before:
> 
> #include <iostream>
> #include <fstream>
> #include <sstream>
> #include <vector>
> #include <string>
> #include <algorithm>
> #include <memory>
> #include <functional>
> #include <cstring>
> 
> using namespace std;
> 
> int main( int argc, char **argv )
> {
>      if( argc != 3 )
>          return EXIT_FAILURE;
>      try
>      {
>          ifstream ifs;
>          ifs.exceptions( ifstream::failbit | ifstream::badbit );
>          ifs.open( argv[1], ifstream::binary );
>          ifs.seekg( 0, ios_base::end );
>          streampos    fileLength = ifs.tellg();
>          vector<char> m_rawStrings( (size_t)fileLength + 1 );
>          ifs.seekg( 0, ios_base::beg );
>          ifs.read( &m_rawStrings[0], fileLength );
>          m_rawStrings[fileLength] = 0;
>          size_t nLines      = 0,
>                 nCharacters = 0;
>          // count the number of lines to prevent incremental 
> buffer-growing of the "strings"-object
>          using vc_it = vector<char>::iterator;
>          for( vc_it scn = m_rawStrings.begin(), end = 
> m_rawStrings.end(); scn != end; )
>          {
>              ++nLines;
>              do
>                  if( *scn == '\r' )
>                  {
>                      if( ++scn == end )
>                          break;
>                      if( *scn == '\n' )
>                          ++scn;
>                      break;
>                  }
>                  else if( *scn == '\n' )
>                  {
>                      ++scn;
>                      break;
>                  }
>                  else
>                      ++nCharacters;
>              while( ++scn != end );
>          }
>          vector<vc_it>           strings( nLines );
>          vector<vc_it>::iterator curString = strings.begin();
>          for( vector<char>::iterator scn = m_rawStrings.begin(), end = 
> m_rawStrings.end(); scn != end; )
>          {
>              *curString++ = scn;
>              do
>                  if( *scn == '\r' )
>                  {
>                      *scn = 0;
>                      if( ++scn == end )
>                          break;
>                      if( *scn == '\n' )
>                          ++scn;
>                      break;
>                  }
>                  else if( *scn == '\n' )
>                  {
>                      *scn++ = 0;
>                      break;
>                  }
>              while( ++scn != end );
>          }
>          sort( strings.begin(), strings.end(), []( vc_it left, vc_it 
> right ) { return strcmp( &*left, &*right ) < 0; } );
>          vector<char> buff;
>          buff.resize( nCharacters + nLines );
>          size_t lineLength;
>          vc_it  wrt = buff.begin();
>          for( vc_it str : strings )
>              lineLength = strlen( &*str ),
>              copy( str, str + lineLength, wrt ),
>              wrt += lineLength,
>              *wrt++ = '\n';
>          ofstream ofs;
>          ofs.exceptions( ifstream::failbit | ifstream::badbit );
>          ofs.open( argv[2], ofstream::trunc );
>          ofs.write( &buff[0], buff.size() );
>          return EXIT_SUCCESS;
>      }
>      catch( exception &exc )
>      {
>          cout << exc.what() << endl;
>          return EXIT_FAILURE;
>      }
> }
> 
> A bittle C-ish because of the memory scan and the raw iterator-list,
> but the containers and the exception-handling save a lot of code.
> And having iterators helps debugging because you can switch to
> bounds-checked iterators.

Yes, but notice how this example now damages your premise that
efficient code in C++ is way shorter and simpler than C. 
During last five years I have grown more and more displeased with
C++. The profiler keeps constantly showing that performance of
popular Stack Overflow and handbook / tutorial snippets has gone
worse and worse by default while what is needed to make it actually
efficient has grown uglier and less novice-friendly.

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

#151171

> Yes, but notice how this example now damages your premise that
> efficient code in C++ is way shorter and simpler than C.

It is very shorter and simpler becaue of the containers
and error-handling which would be more complicated in C.

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

#151182

On Tuesday, April 7, 2020 at 10:06:21 AM UTC+3, Bonita Montero wrote:
> > Yes, but notice how this example now damages your premise that
> > efficient code in C++ is way shorter and simpler than C.
> 
> It is very shorter and simpler becaue of the containers
> and error-handling which would be more complicated in C.

Error handling in C would be longer only if your religion disallows goto.
Besides, your "short" error handling is only short because it does not produce informative error message.

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

#151190

On 07/04/2020 14:58, already5chosen@yahoo.com wrote:
> On Tuesday, April 7, 2020 at 10:06:21 AM UTC+3, Bonita Montero wrote:
>>> Yes, but notice how this example now damages your premise that
>>> efficient code in C++ is way shorter and simpler than C.
>>
>> It is very shorter and simpler becaue of the containers
>> and error-handling which would be more complicated in C.
> 
> Error handling in C would be longer only if your religion disallows goto.
> Besides, your "short" error handling is only short because it does not produce informative error message.
> 

The error handling in the C++ program there is worse than useless - it 
hides any information that might be available behind a simple exit code 
that can easily go unnoticed.  You'd be better off with no error 
handling at all - then critical faults will get trapped by the OS and 
give you a hint about what went wrong.  And if there is one language 
that is good for writing code with no error handling, it is C !  (You 
can do it in C++ too, of course.)

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

#151196

> Error handling in C would be longer only if your religion disallows goto.

It will also be longer with goto. You would have to evalate return
-values at every place whreas in C++ you do this only when using
functions that return return-codes to convert their return-codes
into exceptions; but that's very rare.

> Besides, your "short" error handling is only short because it does not produce informative error message.

The standard-library has built-in error-messages which are usually
sufficient.

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

#151198

On Tuesday, April 7, 2020 at 8:02:56 PM UTC+3, Bonita Montero wrote:
> > Error handling in C would be longer only if your religion disallows goto.
> 
> It will also be longer with goto. You would have to evalate return
> -values at every place whreas in C++ you do this only when using
> functions that return return-codes to convert their return-codes
> into exceptions; but that's very rare.
> 

If you want comprehensive error reporting then evaluating errors in place is necessary anyway. Otherwise too much information is lost.

> > Besides, your "short" error handling is only short because it does not produce informative error message.
> 
> The standard-library has built-in error-messages which are usually
> sufficient.


No it's not sufficient in your case.
I tested three most probable user mistakes: not providing sufficient number of command-line parameters, non-existing input file and read-only output file. In all three cases error messages were either non-existing or non-comprehensive, at least on windows/msys2. I didn't try Linux or Visual Studio.

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

#151202

> If you want comprehensive error reporting then evaluating errors in place is necessary anyway. Otherwise too much information is lost.

Most errors can be gathered in a single place. You f.e. don't know at
which call there was a memory-collapse; you simply just need to know
that there was any.

> I tested three most probable user mistakes: not providing sufficient number of command-line parameters, non-existing input file and read-only output file. In all three cases error messages were either non-existing or non-comprehensive, at least on windows/msys2. I didn't try Linux or Visual Studio.

Even Windows is very comfotable at this. When you throw a system_error
with an error-code containing GetLastError() it converts the error-code
to a meaningful localized error-string.

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

#151210

On Tuesday, April 7, 2020 at 9:03:02 PM UTC+3, Bonita Montero wrote:
> > If you want comprehensive error reporting then evaluating errors in place is necessary anyway. Otherwise too much information is lost.
> 
> Most errors can be gathered in a single place. You f.e. don't know at
> which call there was a memory-collapse; you simply just need to know
> that there was any.
> 
> > I tested three most probable user mistakes: not providing sufficient number of command-line parameters, non-existing input file and read-only output file. In all three cases error messages were either non-existing or non-comprehensive, at least on windows/msys2. I didn't try Linux or Visual Studio.
> 
> Even Windows is very comfotable at this. When you throw a system_error
> with an error-code containing GetLastError() it converts the error-code
> to a meaningful localized error-string.

Of course, Windows gives sufficient information which is easily extractable in C or C-style C++ even without platform-specific system calls (e.g. via perror() or sys_errlist[]), although for non-toy Windows program I'd prefer platform-specific FormatMessage()). But I am not talking about that.
I am talking about program *you* posted above which produces either no messages or non-informative messages. Like "basic_ios::clear: iostream error"

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

#151211

* Bonita Montero <Bonita.Montero@gmail.com>:
>> Error handling in C would be longer only if your religion disallows goto.
> 
> It will also be longer with goto. You would have to evalate return
> -values at every place whreas in C++ you do this only when using
> functions that return return-codes to convert their return-codes
> into exceptions; but that's very rare.

If you use exceptions, you lost control. Take a second to get the double
meaning please.

There's a reason we are banning exceptions from our .NET core code at
work, in favour of railway programming.

-- 
 Dipl.-Inform. Felix Palmen  <felix@palmen-it.de>   ,.//..........
 {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
 {pgp public key}     http://palmen-it.de/pub.txt   //   """""""""""
 {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A

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

#151217 — Railway programming (Was : The big problem of C)

On Tue, 7 Apr 2020 22:34:52 +0200
felix@palmen-it.de (Felix Palmen) wrote:
> If you use exceptions, you lost control. Take a second to get the double
> meaning please.
> 
> There's a reason we are banning exceptions from our .NET core code at
> work, in favour of railway programming.

I hadn't heard of "railway programming". I googled it but couldn't get an
idea quickly. If it can be done with C , I'd love to see some examples.

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

#151219 — Re: Railway programming (Was : The big problem of C)

Spiros Bousbouras <spibou@gmail.com> writes:

> On Tue, 7 Apr 2020 22:34:52 +0200
> felix@palmen-it.de (Felix Palmen) wrote:
>> If you use exceptions, you lost control. Take a second to get the double
>> meaning please.
>> 
>> There's a reason we are banning exceptions from our .NET core code at
>> work, in favour of railway programming.
>
> I hadn't heard of "railway programming". I googled it but couldn't get an
> idea quickly. If it can be done with C , I'd love to see some
> examples.

The inventor of the term seems to think it should /not/ be used as an
alternative to exceptions.  It seems the technique has, in his view at
least, a rather narrow set of uses.

-- 
Ben.

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

#151220 — Re: Railway programming (Was : The big problem of C)

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Spiros Bousbouras <spibou@gmail.com> writes:
>
>> On Tue, 7 Apr 2020 22:34:52 +0200
>> felix@palmen-it.de (Felix Palmen) wrote:
>>> If you use exceptions, you lost control. Take a second to get the double
>>> meaning please.
>>> 
>>> There's a reason we are banning exceptions from our .NET core code at
>>> work, in favour of railway programming.
>>
>> I hadn't heard of "railway programming". I googled it but couldn't get an
>> idea quickly. If it can be done with C , I'd love to see some
>> examples.
>
> The inventor of the term seems to think it should /not/ be used as an
> alternative to exceptions.  It seems the technique has, in his view at
> least, a rather narrow set of uses.

Sorry, forgot the link!

https://fsharpforfunandprofit.com/posts/against-railway-oriented-programming/

-- 
Ben.

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

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

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

csiph-web