Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #151019 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2020-04-04 13:41 -0700 |
| Last post | 2020-04-08 18:27 -0700 |
| Articles | 20 on this page of 90 — 19 participants |
Back to article view | Back to comp.lang.c
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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | felix@palmen-it.de (Felix Palmen) |
|---|---|
| Date | 2020-04-08 09:56 +0200 |
| Subject | Re: Railway programming (Was : The big problem of C) |
| Message-ID | <ulc0mg-vse1.ln1@mail.home.palmen-it.de> |
| In reply to | #151220 |
* Ben Bacarisse <ben.usenet@bsb.me.uk>:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> 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/
This might give the wrong expression, but the article explains things I
agree with. There are two very distinct kinds of errors:
* Violations of business rules
* Infrastructural errors and bugs (I see them as basically the same
class where the article does a distinction)
For the latter case of errors, exception handling can be somewhat
useful, but only if exceptions are never catched except in some central
location that typically logs the error with information where in the
code it happened. That's at least hard to achieve in C. But that's only
for debugging, it's the kind of error the running program can do nothing
about. In most cases, you won't have to /throw/ exceptions for this, as
your language's runtime or some library you use already does.
Using exceptions for violations of business rules is a trap leading to
buggy code. That's the kind of error your business logic should act
upon, and if you start doing that in some unrelated catch-block, you
will at some point miss some error handling and/or introduce
inconsistent state.
--
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]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2020-04-09 11:55 +0000 |
| Subject | Re: Railway programming (Was : The big problem of C) |
| Message-ID | <jGaHc0GjtpavlJKhos@bongo-ra.co> |
| In reply to | #151225 |
On Wed, 8 Apr 2020 09:42:55 +0200
felix@palmen-it.de (Felix Palmen) wrote:
> * Spiros Bousbouras <spibou@gmail.com>:
> > 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.
>
> I don't think it applies to C, cause it relies on higher-order functions
> and generic types. In very short terms, the idea is that every function
> returns some "either/or" object which contains either the type of the
> actual result or an error type. Then, you have HOFs on that result type
> like "OnError" and "OnSuccess" that take another function working on the
> result. Error results are just passed through unchanged, so sou can
> build chains like
>
> DoSomething()
> .OnSuccess(DoSomeOtherThing())
> .OnSuccess(DoEvenMore())
> .OnError(HandleError())
>
> where HandleError() can handle handle an error that occured in the very
> first DoSomething().
And what would the code would like if this was handled with exceptions ?
[From <ulc0mg-vse1.ln1@mail.home.palmen-it.de>] :
>* Ben Bacarisse <ben.usenet@bsb.me.uk>:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> 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/
>
>This might give the wrong expression, but the article explains things I
>agree with. There are two very distinct kinds of errors:
>
>* Violations of business rules
>* Infrastructural errors and bugs (I see them as basically the same
> class where the article does a distinction)
>
> For the latter case of errors, exception handling can be somewhat
> useful, but only if exceptions are never catched except in some central
> location that typically logs the error with information where in the
> code it happened. That's at least hard to achieve in C.
Why is it hard ? It seems to me you can have
void general_error_logger(const char * message ,
...possibly other arguments) {
... code for logging the message ...
}
and then each piece of code which comes across an error of the second
category can form an appropriate message and then call
general_error_logger() .
> But that's only for debugging, it's the kind of error the running program
> can do nothing about. In most cases, you won't have to /throw/ exceptions
> for this, as your language's runtime or some library you use already does.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-04-08 08:17 +0000 |
| Subject | Re: Railway programming (Was : The big problem of C) |
| Message-ID | <slrnr8r24n.1r7q.grahn+nntp@frailea.sa.invalid> |
| In reply to | #151220 |
On Wed, 2020-04-08, Ben Bacarisse wrote: > 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/ My take on all this is, error handling is hard. When people fail error handling using one tool, they are liable to curse it and switch to some other tool which they haven't failed with -- yet. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | felix@palmen-it.de (Felix Palmen) |
|---|---|
| Date | 2020-04-08 09:42 +0200 |
| Subject | Re: Railway programming (Was : The big problem of C) |
| Message-ID | <vsb0mg-ome1.ln1@mail.home.palmen-it.de> |
| In reply to | #151217 |
* Spiros Bousbouras <spibou@gmail.com>:
> 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.
I don't think it applies to C, cause it relies on higher-order functions
and generic types. In very short terms, the idea is that every function
returns some "either/or" object which contains either the type of the
actual result or an error type. Then, you have HOFs on that result type
like "OnError" and "OnSuccess" that take another function working on the
result. Error results are just passed through unchanged, so sou can
build chains like
DoSomething()
.OnSuccess(DoSomeOtherThing())
.OnSuccess(DoEvenMore())
.OnError(HandleError())
where HandleError() can handle handle an error that occured in the very
first DoSomething().
But then, it's basically syntactic sugar reducing the amount of code
needed for explicit error handling. In C, you'd probably use a simpler
well-known scheme with every function returning an error code like this:
errortype err = 0;
resulttype1 res1;
err = DoSomething(&res1);
if (err) goto done;
resulttype2 res2;
err = DoSomethingElse(&res2, res1);
if (err) goto done;
// [...]
done:
if (err) HandleError(err);
--
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]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2020-04-07 06:13 -0700 |
| Message-ID | <e4b0114b-d35e-4fa5-b257-0476706bc0a0@googlegroups.com> |
| In reply to | #151168 |
On Tuesday, April 7, 2020 at 6:47:52 AM UTC+3, Öö Tiib wrote:
> 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.
Yes. 'emplace_back' and 'move' in first Bonita's attempt instead of 'push_back' that everybody used for 25 years, is a good example of that.
However I think that absence of decent metaprogramming facility in C (except for powerful, but ugly preprocessor) is a serious defect of the language.
IMHO adding facility based on implicit pattern matching, like C++ templates, is a bad idea. But something more explicit, along the lines of Ada-83 Generic packets is not against a spirit of C language. Of course, except that in C variant it should me made clear that generic packets have to be textually included and there are no requirements for their separate compilation.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-07 09:17 -0700 |
| Message-ID | <874ktvmfsf.fsf@nosuchdomain.example.com> |
| In reply to | #151183 |
already5chosen@yahoo.com writes:
[...]
> IMHO adding facility based on implicit pattern matching, like C++
> templates, is a bad idea. But something more explicit, along the lines
> of Ada-83 Generic packets is not against a spirit of C language. Of
> course, except that in C variant it should me made clear that generic
> packets have to be textually included and there are no requirements
> for their separate compilation.
I think you mean generic packages, not packets. And they're not
specific to Ada 83. They exist in later versions of the language,
and they still require explicit instantiation. (And Ada also has
other generic program units, such as functions and procedures.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2020-04-07 09:44 -0700 |
| Message-ID | <2931ab15-2227-4793-a354-1aedde34c580@googlegroups.com> |
| In reply to | #151191 |
On Tuesday, April 7, 2020 at 7:17:33 PM UTC+3, Keith Thompson wrote:
> already5chosen@yahoo.com writes:
> [...]
> > IMHO adding facility based on implicit pattern matching, like C++
> > templates, is a bad idea. But something more explicit, along the lines
> > of Ada-83 Generic packets is not against a spirit of C language. Of
> > course, except that in C variant it should me made clear that generic
> > packets have to be textually included and there are no requirements
> > for their separate compilation.
>
> I think you mean generic packages, not packets. And they're not
> specific to Ada 83. They exist in later versions of the language,
> and they still require explicit instantiation. (And Ada also has
> other generic program units, such as functions and procedures.)
>
> --
> Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
> Working, but not speaking, for Philips Healthcare
> void Void(void) { Void(); } /* The recursive call of the void */
Yes, I meant packages.
Generic functions outside of generic packages? I am not sure if it would be good or bad idea in case of C. It depends on other details of specific proposal for language extension.
Anyway, the main problem for any such proposal would be how to avoid immediate rejection "because it's already available in C++".
As to Ada-95 and later, I don't know it well and parts that I do know (about 95) I mostly don't like.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-04-07 09:07 +0200 |
| Message-ID | <r6h8sc$c7c$2@news.albasani.net> |
| In reply to | #151156 |
Now it's even less C-ish:
#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> rawStrings( (size_t)fileLength + 1 );
ifs.seekg( 0, ios_base::beg );
ifs.read( &rawStrings[0], fileLength );
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 = rawStrings.begin(), end = 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 = rawStrings.begin(), end =
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 )
{
vc_it end = find( str, rawStrings.end(), 0 );
lineLength = end - str;
copy( str, end, 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;
}
}
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-04-06 05:01 -0700 |
| Message-ID | <eb46f25a-4350-409b-bd08-1d5a069a13b1@googlegroups.com> |
| In reply to | #151130 |
On Monday, 6 April 2020 14:36:20 UTC+3, David Brown wrote:
>
> 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.
Basically Bonita's code did miss essential
std::ios_base::sync_with_stdio(false);
That is needed to removing pointless synchronization with C stdio.
Also it used std::endl that is expensive and better to replace
with '\n'.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-04-06 14:42 +0200 |
| Message-ID | <r6f84d$svb$1@news.albasani.net> |
| In reply to | #151133 |
> Basically Bonita's code did miss essential > std::ios_base::sync_with_stdio(false); On Windows this doesn't make any difference. On Linux I got about 12% less runtime. > That is needed to removing pointless synchronization with C stdio. > > Also it used std::endl that is expensive and better to replace > with '\n'. endl isn guaranteed to flush. But the runtimes usually interpret '\n' to flush to be fool-proof. The thing here is that there's a large part of system-runtime.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-04-06 00:09 +0100 |
| Message-ID | <rytiG.273565$ffc1.126274@fx36.am4> |
| In reply to | #151045 |
On 05/04/2020 08: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.
For a toy program, then yes the C++ might be shorter. In practice you
have to factor in the rest of the actual application as well. Then the
differences will be less significant.
But it seems some people are getting fed up with C++ and moving back to C:
"I did write it all in C because I’ve grown tired of the abysmal C++
compile speeds. Going back to C is oddly refreshing. I may abandon C++
for most of my work now. Building even a 100k lines of C from scratch in
debug mode takes like a second on my laptop. It makes C++ absurdly slow
in comparison. It’s also cool to get to implement various data
structures I grew used to in C++, without needing to know how they
worked in detail. I took this as an opportunity to refresh my data
structures and algorithms know how :)"
(https://www.reddit.com/r/Compilers/comments/fcu1be/want_to_develop_a_simple_assembler_in_c_for_linux/)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-06 09:09 +0200 |
| Message-ID | <r6ekjh$sbj$2@dont-email.me> |
| In reply to | #151105 |
On 06/04/2020 01:09, Bart wrote: > But it seems some people are getting fed up with C++ and moving back to C: > The plural of "anecdote" is "anecdotes", not "general rule".
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-04-05 12:41 +0100 |
| Message-ID | <mtjiG.273144$wQ4.249898@fx23.am4> |
| In reply to | #151034 |
On 05/04/2020 00:40, Thiago Adams wrote: > On Saturday, April 4, 2020 at 6:20:10 PM UTC-3, Felix Palmen wrote: >> * Thiago Adams >>> One of the biggest problem of C is the lack of parametrized >>> containers and algorithms. >> >> I guess anyone who knows his way around C can stop reading right here. > > My point is not that impossible to use C because of this, > but I am saying that creating types to represent, for instance, > resizable arrays creates a lot of noise when we just want > a ordinary array of something. > > How do you do resizable arrays? > You want them to be indexed and so on like regular arrays, and to grow automatically as you append a new element? Not in C, without massive upgrades to the language. Think about, not just a resizable array of some ordinary type T (say, a struct, or a float, or even an unmanaged C string pointer). Suppose you had a struct containing such resizeable arrays. Then you had a resizable array of such a struct. And a further resizeable array of that array (to form an array of arrays). Or a linked list of those structs containing resizable arrays. It all gets a bit much. Here, I'd agree with Ian Collins for a change!
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-04-05 07:05 -0700 |
| Message-ID | <8e869380-22ff-4dfa-ab67-d54bb7722e21@googlegroups.com> |
| In reply to | #151061 |
On Sunday, April 5, 2020 at 8:41:16 AM UTC-3, Bart wrote:
> On 05/04/2020 00:40, Thiago Adams wrote:
> > On Saturday, April 4, 2020 at 6:20:10 PM UTC-3, Felix Palmen wrote:
> >> * Thiago Adams
> >>> One of the biggest problem of C is the lack of parametrized
> >>> containers and algorithms.
> >>
> >> I guess anyone who knows his way around C can stop reading right here.
> >
> > My point is not that impossible to use C because of this,
> > but I am saying that creating types to represent, for instance,
> > resizable arrays creates a lot of noise when we just want
> > a ordinary array of something.
> >
> > How do you do resizable arrays?
> >
>
> You want them to be indexed and so on like regular arrays, and to grow
> automatically as you append a new element?
First I would like to know if other people agree with the
problem.
The problem is: having to create a new ordinary array type
is bad because creates noise and boilerplate code.
Array types are already part of the language but are not
resizable.
Then we the C language could find a solution that is better
to have than the problem.
I think, for instance, that the declaration
int a[auto];
could be similar of:
struct int_array {
int * data;
size_t size;
size_t capacity;
};
struct int_array a;
This is not only some internal representation, but
theses struct members should be accessible.
So this syntax is a shortcut or alias for the struct.
Anyone can create a push algorithm to grow the array.
or you can use a default.
my_optimized_push(a, 1);
The other difference from the struct is keep the
same syntax we have for arrays today.
void F(int a[auto]);
int main()
{
int a[auto];
F(a); //a is passed as pointer to struct.
}
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2020-04-04 17:48 -0500 |
| Message-ID | <r6b2r9$tp7$1@dont-email.me> |
| In reply to | #151019 |
On 4/4/2020 4:00 PM, Stefan Ram wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> One of the biggest problem of C is the lack of parametrized
>> containers and algorithms.
>
> C is intended to enable the user to /implement/
> such beasts.
>
> Today we have a large range of languages for
> application programmers, for example, Python.
> They offer a wide range of containers and algorithms.
>
Yep.
Also it can be noted that such container types can easily lead to
laziness and inefficiency, as they may implicitly lead many people to
not think about certain matters:
What is the starting size, average-case size, and expansion rate of the
container?
What is the overhead of accessing each member by index or iterating over
the members of a container?
How does using this container effect build times, code-size overhead,
and memory footprint?
...
At least in C, one is more helpfully encouraged to think more about what
they are doing.
In one of my own languages (sort of resembles a C/Java hybrid), there
are some higher-level array types (mote like Java-style arrays), but
they are kind of a problem on the implementation front as things like
additional handling and bounds checking does not come for free. So,
in-effect, to get C-like performance with it, while using the same
backend as my C compiler, it is necessary to write code that is
basically about the same as one would otherwise write in C.
About the only features which can really be used without penalty are
things which "come mostly for free", which generally ends up being
things like overloaded function names and namespaces and similar.
Note that the language does not use a garbage collector, so at least I
have "dodged that bullet".
> But in which language is the original and most-
> maintained implementation of Python written?
>
> In C.
>
Yep.
Containers types are pretty low on my personal priority list.
I would personally rather see (ATM):
Better support for explicit data alignment, endianess, ...;
Better defined semantics for if, when, and where aliasing semantics apply;
More consistent support for SIMD vector types and operations;
More explicit handling of imports/exports/...;
...
For example, a few thoughts:
"__packed":
Applied to a struct, means to pack members;
Struct is also non-padded, and byte-aligned;
Essentially analogous to "__attribute__((packed))"
Applied to a pointer, allows misaligned access.
Something like "volatile", but maybe a little weaker. Allows pointers to
alias freely, but does not entirely disallow caching the value in
registers (as generally implied for volatile). Implicitly, would not
imply any sort of memory synchronization, whereas implicitly accessing
memory through a volatile pointer implies that memory may need to be
synchronized (eg: if the architecture uses a sort of "lazy"
cache-consistency model).
Then again, the existing practice in these cases is typically to make
some address ranges special (with these being used for MMIO), and to
have special builtin functions to facilitate cases where explicit
cache-synchronization is needed.
The current situation with SIMD vector types is a mess:
The SIMD code is generally specific to a particular combination of
compiler, instruction set, and which SIMD extensions are enabled.
The "xmmintrin.h"/"emmintrin.h" system assumes SSE and is otherwise a
terrible mess.
The GCC vector system is pretty much specific to GCC, and sort of treats
vector operations mostly like applying an operator over an array of numbers.
In my compiler, I ended up with a slightly different system:
I grandfathered in the __m128 and __m64 types and similar;
These are treated more like the SIMD vector equivalent of "void *".
Casting vectors to/from these types does a raw/untyped conversion.
Casting these to/from __int64 or __int128 does a bitwise conversion.
A bunch of more specialized vector subtypes were added:
__vec2f, __vec3f, __vec4f, __vec2d, __vec4si, __quatf, ...
These are treated more like value types:
A given vector's value is treated as immutable;
Vectors can be composed, but element values may not be modified.
They are passed by value (value is copied by assignment, ...);
...
Basically, more like if something vaguely resembling GLSL was glued on to C.
So, eg:
__vec4f v0, v1, v2, v3;
float f, g, h;
v0=(__vec4f) {1, 2, 3, 4};
v1=(__vec4f) {5, 6, 7, 8};
v2=v0+v1; //pairwise add
v3=v0*v1; //pairwise multiply
f=v2.x; //gets the value '6'
g=v3.z; //gets the value '21'
h=v3[3]; //equivalent to v3.w, gives '32'
The "_Complex" types are also treated as vector sub-types;
The "__quatf" type behaves like both a vector and a numeric type (like
"_Complex"), implementing quaternion operations.
A restricted subset of the GCC vectors may also be supported (to what
extent the semantics overlap).
Eg:
typedef float vec4f __attribute__((vector_size(16)));
Will behave like an alias for:
typedef __vec4f vec4f;
...
Likewise:
vec4f v={1,2,3,4};
Will work in both systems.
This is also valid under my system:
__vec4f v0, v1, v2;
void *p0, *p1;
...
v0=*(__packed __m128)p0; //misaligned load from a raw pointer.
...
*(__m128)p1=v2; //aligned store
Unlike the GCC system, the vectors may only currently exist in terms of
specific combinations of vector size and element types (for now,
combinations which map to the underlying SIMD registers and operators);
whereas the GCC system attempts to be generic (supporting any possible
combination whether or not it natively exists). This was mostly to limit
implementation effort.
There should still be enough overlap to hopefully be useful.
All this is mostly a thing because auto-vectorization is still one of
those "doesn't generally work effectively" categories, and my compiler
doesn't bother with this.
Import/export handling is also one of those problem areas, in that
compilers and targets treat this issue differently. Unix is
traditionally "import/export everything by default", whereas in Windows
this is generally explicit.
My compiler generally "borrowed" the "__declspec(dllimport)" and
"__declspec(dllexport)" syntax and semantics from MSVC.
...
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-04-04 17:16 -0700 |
| Message-ID | <6a134673-b7bd-48e2-916e-e2384e5e4a15@googlegroups.com> |
| In reply to | #151033 |
On Saturday, April 4, 2020 at 7:48:16 PM UTC-3, BGB wrote:
> On 4/4/2020 4:00 PM, Stefan Ram wrote:
> > Thiago Adams writes:
> >> One of the biggest problem of C is the lack of parametrized
> >> containers and algorithms.
> >
> > C is intended to enable the user to /implement/
> > such beasts.
> >
> > Today we have a large range of languages for
> > application programmers, for example, Python.
> > They offer a wide range of containers and algorithms.
> >
>
> Yep.
>
>
> Also it can be noted that such container types can easily lead to
> laziness and inefficiency, as they may implicitly lead many people to
> not think about certain matters:
My motivation for writing this topic was the code that I wrote
last week. I was writing some calendar algorithms and the
calendar need to be configured, for instance a list of holidays.
I read the calendar configuration from a json file
and I put it on memory.
Using a resizable array for holidays make sense because
I can read the json file and add new items.
It also make sense for create unit tests. I don't need
to give all the list of holidays at once) and it s easy to
configure with or without json files.
It also make sense in case I use the same data structure
and the user can edit (add/remove) items in RUNTIME.
I am explaining the usage because I know that in C we need
some context to choose the best approach.
So, I can create a type, let's says HollidaysArray.
The problem I see is that this is an ORDINARY array
of struct Holliday* and if I add new type, lets say
"struct HollidaysArray" this creates a lot of NOISE
and boilerplate code.
Note that any algorithm of allocation if fine for me, this
is not the critical part.
So far I did one experiment: (I am not 100% happy with it)
struct Calendar
{
struct ArrayOf(struct Hollidays*) hollidays;
}
This creates a struct without name(tag) that later I can
push items using a macro.
What I have fixed? The noise of create a ordinary array type.
What problem I created?
macros and I cannot identify this type in a function for
instance because identical structs (without tag) are
not the same in C.
e.g
void F(struct ArrayOf(struct Hollidays*) *ar);
At the moment there is no solution that makes me happy
and each try creates a different type of problem.
(Even if not perfect the C++ solution (vector) is better
than C for this SPECIFIC case.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-04-05 09:25 +0200 |
| Message-ID | <r6c15v$p8c$1@news.albasani.net> |
| In reply to | #151019 |
> C is intended to enable the user to /implement/ > such beasts. A contemporary language has to provide such containers.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2020-04-05 09:50 +0200 |
| Message-ID | <r6c2kh$ihc$1@dont-email.me> |
| In reply to | #151019 |
Le 04/04/2020 à 22:41, Thiago Adams a écrit : > > One of the biggest problem of C is the lack of parametrized > containers and algorithms. > I have developed several years ago a containers library for C. https://code.google.com/archive/p/ccl/ Free source code. O,ne of the containers proposed is a flexible array. I have often spoken about it in this group. The answers were all negative. I spent US$ 5000 in expenses to go to Portland, USA, to present it to the C standards committee. It was refused since C++ does it already. My work has been largely ignored. You can start there, if you wish. jacob
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-04-05 09:53 +0200 |
| Message-ID | <r6c2pv$ksp$1@news.albasani.net> |
| In reply to | #151046 |
> I have developed several years ago a containers library for C. > https://code.google.com/archive/p/ccl/ > Free source code. O,ne of the containers proposed is a flexible array. > I have often spoken about it in this group. The answers were all negative. > I spent US$ 5000 in expenses to go to Portland, USA, to present it to > the C standards committee. It was refused since C++ does it already. > My work has been largely ignored. You can start there, if you wish. Building containers with C doesn't really work as there are no useful templates.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2020-04-05 18:00 +0200 |
| Message-ID | <r6cvbi$90g$1@dont-email.me> |
| In reply to | #151047 |
Le 05/04/2020 à 09:53, Bonita Montero a écrit : > > Building containers with C doesn't really work as there are no useful > templates. > Before stating that kind of thing you *could* have looked at the source code. But after all that C++ maybe you can't read C anymore
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web