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

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

What is "complexifying" C?

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

Contents

  What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-16 22:55 +0100
    Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-16 22:55 +0000
      Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 16:41 -0700
        Re: What is "complexifying"  C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 00:05 +0000
        Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 01:12 +0000
        Re: What is "complexifying"  C? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 13:58 -0700
      Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 07:16 +0100
        Re: What is "complexifying"  C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 13:50 +0000
          Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 14:59 +0100
            Re: What is "complexifying" C? jacob navia <jacob@spamsink.net> - 2015-03-17 15:22 +0100
              Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-17 16:16 +0100
            Re: What is "complexifying"  C? Kaz Kylheku <kaz@kylheku.com> - 2015-03-17 14:39 +0000
            Re: What is "complexifying"  C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 15:23 +0000
          Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 15:40 -0700
          Re: What is "complexifying"  C? Kaz Kylheku <kaz@kylheku.com> - 2015-03-18 22:49 +0000
            Re: What is "complexifying"  C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 13:55 +0000
              Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 15:37 +0000
                Re: What is "complexifying" C? jacob navia <jacob@jacob.remcomp.fr> - 2015-03-19 23:06 +0100
                  Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 22:38 +0000
                    Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-20 19:43 +1300
                      Re: What is "complexifying" C? jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 07:49 +0100
                      Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 02:29 -0500
                        Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-20 21:37 +1300
                          Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 03:40 -0500
                            Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-20 10:18 +0100
                              Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-21 00:19 -0500
                          Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 03:15 -0700
                            Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 13:51 +1300
                              Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 15:21 +1300
                              Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 00:57 -0700
                                Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 22:28 +1300
                                  Re: What is "complexifying" C? fir <profesor.fir@gmail.com> - 2015-03-22 02:59 -0700
                                  Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 11:16 -0700
                                    Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 07:25 +1300
                                      Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 12:06 -0700
                                        Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:01 +1300
                                          Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-23 03:09 -0700
                                        Re: What is "complexifying" C? fir <profesor.fir@gmail.com> - 2015-03-23 01:42 -0700
                                    Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-22 19:32 +0100
                                      Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-22 17:34 -0500
                                        Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 20:07 -0400
                                          Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 00:00 -0500
                                            Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 18:04 +1300
                                            Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-23 23:22 -0400
                                    Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 14:54 -0400
                              Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-23 00:35 +0100
                                Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:06 +1300
                              Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:25 +1300
                                Re: What is "complexifying" C? Martin Shobe <martin.shobe@yahoo.com> - 2015-03-22 23:33 -0500
                                Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 18:01 +1300
                                  Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 09:41 -0400
                                    Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 10:23 -0400
                                      Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-24 07:10 +1300
                                        Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 14:57 -0400
                                          Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-24 09:36 +0100
                                            Re: What is "complexifying" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-24 08:42 +0000
                                              Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-24 11:23 +0100
                                                Re: What is "complexifying" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-24 10:52 +0000
                              Re: What is "complexifying" C? raltbos@xs4all.nl (Richard Bos) - 2015-03-29 16:58 +0000
                            Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-22 02:38 +0100
                            Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 09:11 -0400
                        Re: What is "complexifying" C? Les Cargill <lcargill99@comcast.com> - 2015-03-20 06:30 -0500
                      Re: What is "complexifying" C? Bartc <bc@freeuk.com> - 2015-03-20 10:31 +0000
                      Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-20 13:49 +0000
                        Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 09:23 -0700
                        Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-21 08:28 +1300
                  Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 01:04 -0700
      Re: What is "complexifying"  C? Keith Thompson <kst-u@mib.org> - 2015-03-17 08:05 -0700
        Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 16:08 +0100
          Re: What is "complexifying"  C? Keith Thompson <kst-u@mib.org> - 2015-03-17 11:09 -0700
            Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 21:37 +0100
              Re: What is "complexifying"  C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-18 00:40 -0500
        Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 15:34 +0000
      Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 15:06 +0000
    Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-17 00:05 +0100
    Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-16 23:20 +0000
    Re: What is "complexifying"  C? Ian Collins <ian-news@hotmail.com> - 2015-03-17 16:42 +1300
    Re: What is "complexifying"  C? Mark Storkamp <mstorkamp@yahoo.com> - 2015-03-17 08:59 -0500
      Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 15:18 +0100
      Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 14:41 +0000
        Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 15:47 -0700
          Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-19 00:26 +0000
            Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-19 03:23 -0700
              Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-19 11:19 +0000

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

#58701 — Re: What is "complexifying" C?

On 3/22/15 6:34 PM, Robert Wessel wrote:
> On Sun, 22 Mar 2015 19:32:40 +0100, Melzzzzz <mel@zzzzz.com> wrote:
>
>> On Sun, 22 Mar 2015 11:16:02 -0700 (PDT)
>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>
>>> On Sunday, March 22, 2015 at 9:28:50 AM UTC, Ian Collins wrote:
>>>> Malcolm McLean wrote:
>>>>
>>>> Maybe id does, but closing a file when it goes out of scope
>>>> certainly does not.
>>>>
>>> The C++ code
>>>
>>> class MyStream
>>> {
>>>   FILE *fp;
>>>    ~MyStream()
>>>     {
>>>        fclose(fp);
>>>     }
>>> }
>>>
>>> isn't joke code. But it's obviously written by someone unaware of the
>>> fact that fclose() can return an error condition.
>>>
>>>
>>
>> What can one do except log error condition? One can neither return
>> error nor throw exception (as it is no no throwing from destructor).
>
>
> I believe that's his point - doing the fclose in a dtor makes it very
> hard to handle it failing in a meaningful way.
>

but what about a class like (somewhat over simplified):

class MyStream
{
   FILE *fp;

   int close() {
     if(fp) {
       int ret = fclose(fp);
       fp = 0;
       return ret;
     } else {
       return EOF; // or whatever we want to signal with a double close.
     }
   }
   ~MyStream()
   {
     if(fp) close();
   }

};


This allows you to get the error code for closing if you make the effort 
to call close yourself, but if you fail to close the file, it still gets 
closed.

This is where destructors can shine. Now, C++ needs this, as with things 
like exceptions, you need this automatic resource cleanup. In C, we can 
exercise discipline to check each function that it releases what it 
acquired (or pass responsibility to someone else to do this). There are 
times when being able have automatic RAII would be useful, but I am not 
sure adding automatically run destructors keeps the language to its roots.

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

#58713 — Re: What is "complexifying" C?

On Sun, 22 Mar 2015 20:07:18 -0400, Richard Damon
<Richard@Damon-Family.org> wrote:

>On 3/22/15 6:34 PM, Robert Wessel wrote:
>> On Sun, 22 Mar 2015 19:32:40 +0100, Melzzzzz <mel@zzzzz.com> wrote:
>>
>>> On Sun, 22 Mar 2015 11:16:02 -0700 (PDT)
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>>
>>>> On Sunday, March 22, 2015 at 9:28:50 AM UTC, Ian Collins wrote:
>>>>> Malcolm McLean wrote:
>>>>>
>>>>> Maybe id does, but closing a file when it goes out of scope
>>>>> certainly does not.
>>>>>
>>>> The C++ code
>>>>
>>>> class MyStream
>>>> {
>>>>   FILE *fp;
>>>>    ~MyStream()
>>>>     {
>>>>        fclose(fp);
>>>>     }
>>>> }
>>>>
>>>> isn't joke code. But it's obviously written by someone unaware of the
>>>> fact that fclose() can return an error condition.
>>>>
>>>>
>>>
>>> What can one do except log error condition? One can neither return
>>> error nor throw exception (as it is no no throwing from destructor).
>>
>>
>> I believe that's his point - doing the fclose in a dtor makes it very
>> hard to handle it failing in a meaningful way.
>>
>
>but what about a class like (somewhat over simplified):
>
>class MyStream
>{
>   FILE *fp;
>
>   int close() {
>     if(fp) {
>       int ret = fclose(fp);
>       fp = 0;
>       return ret;
>     } else {
>       return EOF; // or whatever we want to signal with a double close.
>     }
>   }
>   ~MyStream()
>   {
>     if(fp) close();
>   }
>
>};
>
>
>This allows you to get the error code for closing if you make the effort 
>to call close yourself, but if you fail to close the file, it still gets 
>closed.
>
>This is where destructors can shine. Now, C++ needs this, as with things 
>like exceptions, you need this automatic resource cleanup. In C, we can 
>exercise discipline to check each function that it releases what it 
>acquired (or pass responsibility to someone else to do this). There are 
>times when being able have automatic RAII would be useful, but I am not 
>sure adding automatically run destructors keeps the language to its roots.


You now have two ways to close.  Which is not necessarily a problem,
but it does add a bit of complexity.

Also, you probably don't want to return the error code, rather you
want to throw if MyStream::close() fails, which means that sharing the
code between close() and the dtor is not quite so simple, probably
needing a routine that both close() and the dtor can invoke (in this
you could just change the line in the dtor to "if (fp) fclose(fp);",
but that still leaves that functionality duplicated).

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

#58715 — Re: What is "complexifying" C?

Robert Wessel wrote:
>
> You now have two ways to close.  Which is not necessarily a problem,
> but it does add a bit of complexity.
>
> Also, you probably don't want to return the error code, rather you
> want to throw if MyStream::close() fails, which means that sharing the
> code between close() and the dtor is not quite so simple, probably
> needing a routine that both close() and the dtor can invoke (in this
> you could just change the line in the dtor to "if (fp) fclose(fp);",
> but that still leaves that functionality duplicated).

Which is still better than having the code is many places!

-- 
Ian Collins

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

#58816 — Re: What is "complexifying" C?

On 3/23/15 1:00 AM, Robert Wessel wrote:
>>
>
> You now have two ways to close.  Which is not necessarily a problem,
> but it does add a bit of complexity.
>
Nope, there is only 1 way to close, calling the function close. There IS 
a path that will call it for you, but there is still only one spot that 
does the close, so if we need to change how that is done, there is a 
single location to change.

> Also, you probably don't want to return the error code, rather you
> want to throw if MyStream::close() fails, which means that sharing the
> code between close() and the dtor is not quite so simple, probably
> needing a routine that both close() and the dtor can invoke (in this
> you could just change the line in the dtor to "if (fp) fclose(fp);",
> but that still leaves that functionality duplicated).
>

IF this was a C++ group, maybe. Since this started as a discussion of 
adding stuff to C, I would say definitely not. Exceptions are one piece 
of C++ that I don't see as fitting in the spirit of C, as it adds 
significant complexity and hidden flows to the language. A program that 
needs exceptions should be moved to something more like C++ than C.

If I was writing this is C++, I would probably not change the statement 
in the destructor to directly calling fclose (as that would duplicate 
the operation), but put the close in the destructor in a try block, thus 
clearly documenting the ignoring of the error (or put some sort of error 
processing in the catch statement).

Note that generally close won't generate errors on reads, but only on 
writes (if the final flush of output has problems), what this really 
means is that before doing the close (where recovery is a lot harder), 
you really want to make a flush call while the file is still open and 
you have a chance to attempt to fix the problem and retry the final write.

Now this is getting very much into the details of "files", as opposed to 
the statement that destructors should only free memory, and not do other 
forms of resource cleanup (so they could become garbage collection).

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

#58681 — Re: What is "complexifying" C?

On 3/22/15 2:16 PM, Malcolm McLean wrote:
> On Sunday, March 22, 2015 at 9:28:50 AM UTC, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>> Maybe id does, but closing a file when it goes out of scope certainly
>> does not.
>>
> The C++ code
>
> class MyStream
> {
>   FILE *fp;
>    ~MyStream()
>     {
>        fclose(fp);
>     }
> }
>
> isn't joke code. But it's obviously written by someone unaware of the
> fact that fclose() can return an error condition.
>
>

Yes, MyStream should have a separate close operation that can return the 
error code (and perhaps a flush operation to force I/O before closing), 
but the destructor still should close the file if it hasn't already been 
closed or you just leaked the file and perhaps now can't access it 
anymore in the program as it is already open.

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

#58697 — Re: What is "complexifying" C?

On 22 Mar 2015 22:50:13 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

> Ian Collins <ian-news@hotmail.com> writes:
> >It certainly is not a bad idea, it is one of the most useful tools
> >in the C++ toolbox.  Amongst other things, it makes resource leaks a
> >thing of the past.
> 
>   Where is the resource leak in the following C code?

I can't see one.

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

#58709 — Re: What is "complexifying" C?

Melzzzzz wrote:
> On 22 Mar 2015 22:50:13 GMT
> ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>
>> Ian Collins <ian-news@hotmail.com> writes:
>>> It certainly is not a bad idea, it is one of the most useful tools
>>> in the C++ toolbox.  Amongst other things, it makes resource leaks a
>>> thing of the past.
>>
>>    Where is the resource leak in the following C code?
>
> I can't see one.

Probably because the lack of white-space makes the code so hard to read!

-- 
Ian Collins

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

#58710 — Re: What is "complexifying" C?

Stefan Ram wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> It certainly is not a bad idea, it is one of the most useful tools in
>> the C++ toolbox.  Amongst other things, it makes resource leaks a thing
>> of the past.
>
>    Where is the resource leak in the following C code?
>
>    (The entry point is the function »f« at the bottom.
>    This is from a previous post I wrote in this NG as
>    a reply; that's where the »f« comes from.«
>
>    The order of the following functions is »bottom up«.)

Does it matter?  The point I was making is RAII removes the burden of 
resource management from the user of the managing object.

> static inline int copy
> ( char const * const x, char * const a, char * const b )
> { int const success = 1; strcpy( a, x ); strcpy( b, x );
>    strcpy( b + 255, a ); return success; }
>
> static inline int allocate_second_buffer
> ( char const * const x, char * const a )
> { int success = 0; char * const buffer = malloc( 2 * 256 );
>    if( buffer ){ success = copy( x, a, buffer ); free( buffer ); }
>    return success; }
>
> static inline int allocate_first_buffer
> ( char const * const x )
> { int success = 0; char * const buffer = malloc( 256 );
>    if( buffer )
>    { success = allocate_second_buffer( x, buffer );
>      free( buffer ); }
>    return success; }
>
> static inline int check_x( char const * const x )
> { int success = 0; if( x )success = allocate_first_buffer( x );
>    return success; }
>
> static inline int check_l( char const * const x, int const l )
> { int success = 0; if( l <= 255 )success = check_x( x );
>    return success; }
>
> int f( char const * const x, int const l )
> { return check_l( x, l ); }
>
>    Does it look much harder to read or to write than the
>    equivalent C++?

The lack of white-space is what makes it hard to read!

If I get the gist of what you have written, the C++ might look something 
like:

int
f( char const* const x, int l )
{
   if( l > 255 ) return 0;

   std::unique_ptr<char> buffer1( new char[256] );

   std::unique_ptr<char> buffer2( new char[2*256] );

   return copy( x, buffer1.get(), buffer2.get() );
}

-- 
Ian Collins

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

#58711 — Re: What is "complexifying" C?

On 3/22/2015 11:25 PM, Ian Collins wrote:
> Stefan Ram wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>> It certainly is not a bad idea, it is one of the most useful tools in
>>> the C++ toolbox.  Amongst other things, it makes resource leaks a thing
>>> of the past.
>>
>>    Where is the resource leak in the following C code?
>>
>>    (The entry point is the function »f« at the bottom.
>>    This is from a previous post I wrote in this NG as
>>    a reply; that's where the »f« comes from.«
>>
>>    The order of the following functions is »bottom up«.)
>
> Does it matter?  The point I was making is RAII removes the burden of
> resource management from the user of the managing object.
>
>> static inline int copy
>> ( char const * const x, char * const a, char * const b )
>> { int const success = 1; strcpy( a, x ); strcpy( b, x );
>>    strcpy( b + 255, a ); return success; }
>>
>> static inline int allocate_second_buffer
>> ( char const * const x, char * const a )
>> { int success = 0; char * const buffer = malloc( 2 * 256 );
>>    if( buffer ){ success = copy( x, a, buffer ); free( buffer ); }
>>    return success; }
>>
>> static inline int allocate_first_buffer
>> ( char const * const x )
>> { int success = 0; char * const buffer = malloc( 256 );
>>    if( buffer )
>>    { success = allocate_second_buffer( x, buffer );
>>      free( buffer ); }
>>    return success; }
>>
>> static inline int check_x( char const * const x )
>> { int success = 0; if( x )success = allocate_first_buffer( x );
>>    return success; }
>>
>> static inline int check_l( char const * const x, int const l )
>> { int success = 0; if( l <= 255 )success = check_x( x );
>>    return success; }
>>
>> int f( char const * const x, int const l )
>> { return check_l( x, l ); }
>>
>>    Does it look much harder to read or to write than the
>>    equivalent C++?
>
> The lack of white-space is what makes it hard to read!
>
> If I get the gist of what you have written, the C++ might look something
> like:
>
> int
> f( char const* const x, int l )
> {
>    if( l > 255 ) return 0;
>
>    std::unique_ptr<char> buffer1( new char[256] );
>
>    std::unique_ptr<char> buffer2( new char[2*256] );
>
>    return copy( x, buffer1.get(), buffer2.get() );
> }

You missed a check. Replace the

if (l > 255) return 0;

with

if (l > 255 && x != nullptr) return 0;

It should also be noted that the behavior has changed when one of the 
allocation fails. Whether or not it's still equivalent as Stefan means 
it, I can't say.

Martin Shobe

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

#58714 — Re: What is "complexifying" C?

Stefan Ram wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> Does it matter?  The point I was making is RAII removes the burden of
>> resource management from the user of the managing object.
>
>    But the C++ programmer has the burden of writing his blocks
>    in an exception-safe manner, which is not trivial.
>
>    For example,
>
> process_request
> ( ::std::shared_ptr< request >( new request ),
>    compute_duration() );
>
>    is a potential resource leak. (When »compute_duration«
>    throws, the pointer »new request« possibly will be lost.)

How?

>    It is not obvious that learning and following all the rules
>    for exception-safety is simpler than taking care to release
>    all resources manually in a language without exceptions.
>
>    C++ code might look simple sometimes because it hides
>    complexity. But sometimes, the programmer still must know
>    what happens behind the simple-looking surface.

Most software hides complexity!  If the programmer wants to look, he or 
she can.

-- 
Ian Collins

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

#58741 — Re: What is "complexifying" C?

On 03/23/2015 07:59 AM, Stefan Ram wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> Stefan Ram wrote:
...
>>> But the C++ programmer has the burden of writing his blocks
>>> in an exception-safe manner, which is not trivial.
>>> For example,
>>> process_request
>>> ( ::std::shared_ptr< request >( new request ),
>>> compute_duration() );
>>> is a potential resource leak. (When �compute_duration�
>>> throws, the pointer �new request� possibly will be lost.)
>> How?
> 
>   You asking this shows that it is difficult and error-prone
>   to write exception-safe code, when even an expert-level
>   programmer like you asks this question! And then, nobody
>   else in the newsgroup already has answered it, so possibly
>   others don't know this too (although, this is a C newsgroup,
>   not a C++ newsgroup).
> 
>   The implementation is free to sequence the operations as:
> 
> step 0 �new request�
> step 1 �compute_duration()�
> steo 2 construct the shared_ptr from the result of step 0
> 
>   . When step 1 throws, the pointer from step 0 will not be
>   safed in the shared_ptr of step 2.

?

"A pair of expressions separated by a comma is evaluated left-to-right;
the left expression is a discardedvalue expression (Clause 5). Every
value computation and side effect associated with the left expression is
sequenced before every value computation and side effect associated with
the right expression" (5.18p1, C++)

Construction of the shared pointer is a side-effect of the left
expression, and therefore must be sequenced before the call to
compute_duration().
-- 
James Kuyper

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

#58746 — Re: What is "complexifying" C?

On 03/23/2015 09:46 AM, Stefan Ram wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> "A pair of expressions separated by a comma is evaluated left-to-right;
> ...
>> (5.18p1, C++)
> 
>   This refers to the comma operator, not to arguments
>   separated by a comma. The heading above the paragraph
>   quoted should make that clear.
> 
>       �Except where noted, evaluations of operands of
>       individual operators and of subexpressions of
>       individual expressions are unsequenced.� - 1.9, C++

Sorry - stupid mistake - I misread the code. When Ian quoted your code,
some of the whitespace disappeared, and my eyes got confused - they
skipped right over the line containing process_request, so I though it
was just a parenthesized comma expression (In my defense, I've seen
weirder constructs than that become a valid topic of conversation).
-- 
James Kuyper

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

#58776 — Re: What is "complexifying" C?

James Kuyper wrote:
> On 03/23/2015 09:46 AM, Stefan Ram wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> "A pair of expressions separated by a comma is evaluated left-to-right;
>> ...
>>> (5.18p1, C++)
>>
>>    This refers to the comma operator, not to arguments
>>    separated by a comma. The heading above the paragraph
>>    quoted should make that clear.
>>
>>        �Except where noted, evaluations of operands of
>>        individual operators and of subexpressions of
>>        individual expressions are unsequenced.� - 1.9, C++
>
> Sorry - stupid mistake - I misread the code. When Ian quoted your code,
> some of the whitespace disappeared, and my eyes got confused - they
> skipped right over the line containing process_request, so I though it
> was just a parenthesized comma expression (In my defense, I've seen
> weirder constructs than that become a valid topic of conversation).

I didn't strip any whitespace, there wasn't much there to start with. 
This is why I read the code as you did....

Which just goes to show clear code layout is one way to minimise bugs!

-- 
Ian Collins

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

#58779 — Re: What is "complexifying" C?

On 03/23/2015 02:10 PM, Ian Collins wrote:
> James Kuyper wrote:
>> On 03/23/2015 09:46 AM, Stefan Ram wrote:
>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>> "A pair of expressions separated by a comma is evaluated left-to-right;
>>> ...
>>>> (5.18p1, C++)
>>>
>>>    This refers to the comma operator, not to arguments
>>>    separated by a comma. The heading above the paragraph
>>>    quoted should make that clear.
>>>
>>>        �Except where noted, evaluations of operands of
>>>        individual operators and of subexpressions of
>>>        individual expressions are unsequenced.� - 1.9, C++
>>
>> Sorry - stupid mistake - I misread the code. When Ian quoted your code,
>> some of the whitespace disappeared, and my eyes got confused - they
>> skipped right over the line containing process_request, so I though it
>> was just a parenthesized comma expression (In my defense, I've seen
>> weirder constructs than that become a valid topic of conversation).
> 
> I didn't strip any whitespace, there wasn't much there to start with. 
> This is why I read the code as you did....

Yet another mistake - I misidentified the message in which the
whitespace disappeared (maybe it displayed differently on my home machine?)

From your message with "Date: 23 Mar 2015 04:39:49 GMT":
>>    For example,
>>
>> process_request
>> ( ::std::shared_ptr< request >( new request ),
>>    compute_duration() );
>>
>>    is a potential resource leak. (When »compute_duration«
>>    throws, the pointer »new request« possibly will be lost.)

From Stefan Ram's response, with Date: "23 Mar 2015 11:59:52 GMT":
>>>For example,
>>>process_request
>>>( ::std::shared_ptr< request >( new request ),
>>>compute_duration() );
>>>is a potential resource leak. (When »compute_duration«
>>>throws, the pointer »new request« possibly will be lost.)

It's entirely possible that this occurred without Stefan having any
control over it, in which cases it's entirely possible that it won't
display properly now.

> Which just goes to show clear code layout is one way to minimise bugs!

It's not the white space in the code itself, but the white space
separating the code from the message, that disappeared.

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

#58820 — Re: What is "complexifying" C?

On 24/03/15 00:21, Stefan Ram wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>>From your message with "Date: 23 Mar 2015 04:39:49 GMT":
>>>>    For example,
>>>>
>>>> process_request
>>>> ( ::std::shared_ptr< request >( new request ),
>>>>    compute_duration() );
>>>>
>>>>    is a potential resource leak. (When »compute_duration«
>>>>    throws, the pointer »new request« possibly will be lost.)
>>From Stefan Ram's response, with Date: "23 Mar 2015 11:59:52 GMT":
>>>>> For example,
>>>>> process_request
>>>>> ( ::std::shared_ptr< request >( new request ),
>>>>> compute_duration() );
>>>>> is a potential resource leak. (When »compute_duration«
>>>>> throws, the pointer »new request« possibly will be lost.)
>> It's entirely possible that this occurred without Stefan having any
>> control over it, in which cases it's entirely possible that it won't
>> display properly now.
> 
>   Mea culpa!
> 
>   I have the habbit of manually stripping whitespace at the start
>   of the line of a quotation so as to »compactify« the quotation.
> 
>   The original message with all the white space is there, so if 
>   anyone responds to that, he will see all the white space; if
>   anyone wants to see the original message, he can open it.
> 
>   But when I am answering, I want to draw the attention to the 
>   /new/ text, so I »compactify« the quotation in order to reduce
>   its optical saliency.
> 
>   I also have the habbit of formatting
> 
> f
> ( x )
> 
>   when breaking a function call across two lines, instead of,
>   for example,
> 
> f(
>   x )
> 
>   . So, in the first case, when one starts reading at the
>   second line, it might not be obvious that this is a continuation
>   of an expression.
> 
>   This reminds me of the observation that one might deem a
>   line such as
> 
> while( x < 10 );
> 
>   to be erroneous, unless, one looks up and sees the 
> 
> do
> 
>   several lines above!
> 

In general, I think your coding style is too compact and makes poor use
of indentation to show blocking.  Of course, these things are a matter
of personal preference and style, and any programmer finds their own
style and habits to be the easiest and clearest.  But very tight style
can be hard to others to follow - something closer to K&R is going to be
clearer for most people.

So rather than:

static inline int allocate_first_buffer
( char const * const x )
{ int success = 0; char * const buffer = malloc( 256 );
  if( buffer )
  { success = allocate_second_buffer( x, buffer );
    free( buffer ); }
  return success; }

try:

static inline int allocate_first_buffer(char const * const x) {
	int success = 0;
	char * const buffer = malloc(256);
	if (buffer) {
		success = allocate_second_buffer(x, buffer);
		free(buffer);
	}
	return success;
}


At least then people are unlikely to argue about the spacing!

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

#58821 — Re: What is "complexifying" C?

On 24/03/15 08:36, David Brown wrote:

<snip>

> At least then people are unlikely to argue about the spacing!

Isn't this like arguing about what font colour to use in your code 
editor? Everyone who is likely to have an intelligent opinion about 
spacing already has access to indent(1), and so they can arrange the 
spacing as seems good to them - if anyone else doesn't like it, they can 
run it through their own indent(1) with their own config settings.

-- 
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]

#58828 — Re: What is "complexifying" C?

On 24/03/15 09:42, Richard Heathfield wrote:
> On 24/03/15 08:36, David Brown wrote:
> 
> <snip>
> 
>> At least then people are unlikely to argue about the spacing!
> 
> Isn't this like arguing about what font colour to use in your code
> editor? Everyone who is likely to have an intelligent opinion about
> spacing already has access to indent(1), and so they can arrange the
> spacing as seems good to them - if anyone else doesn't like it, they can
> run it through their own indent(1) with their own config settings.
> 

Of course - but who is going to do that when reading a Usenet post?
About the only reformatting anyone does on posts is a "rewrap" to fix
bad line endings, and that /really/ screws up code snippets.

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

#58830 — Re: What is "complexifying" C?

On 24/03/15 10:23, David Brown wrote:
> On 24/03/15 09:42, Richard Heathfield wrote:
>> On 24/03/15 08:36, David Brown wrote:
>>
>> <snip>
>>
>>> At least then people are unlikely to argue about the spacing!
>>
>> Isn't this like arguing about what font colour to use in your code
>> editor? Everyone who is likely to have an intelligent opinion about
>> spacing already has access to indent(1), and so they can arrange the
>> spacing as seems good to them - if anyone else doesn't like it, they can
>> run it through their own indent(1) with their own config settings.
>>
>
> Of course - but who is going to do that when reading a Usenet post?

If I want to compile the snippet, I will generally run it through 
indent(1) as part of the process if the whitespace looks like it might 
be a nuisance.

Otherwise (i.e. if I don't want to compile it), my decision procedure is 
normally "does this code look readable without too much effort on my 
part?" If so, I'll live with whatever whitespace decisions the author 
made. If not, very often I'll just quietly skip to the next article.

> About the only reformatting anyone does on posts is a "rewrap" to fix
> bad line endings, and that /really/ screws up code snippets.

I think there are only really two relevant problems inherent in 
Usenet-posted code. One is solved by using
"short"
" (or split)"
" string literals",
and the other is solved by using /* C comments */ rather than // BCPL[1] 
comments.

Excuse me. I mean, the other is solved by using /* C90 comments */ 
rather than // C99 comments.

So, if everybody follows those guidelines, there need be no problem 
whatsoever with line-wrap.


[1] See Richards 1967, 2.1.2(b).

-- 
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]

#59218 — Re: What is "complexifying" C?

Ian Collins <ian-news@hotmail.com> wrote:

> Malcolm McLean wrote:
> > On Friday, March 20, 2015 at 8:37:12 AM UTC, Ian Collins wrote:
> >>
> >> I agree again.  The one thing C++ can do that C can't is manage resource
> >> lifetime with constructors and destructors.  But then again, if you want
> >> C++, you know where to find it...
> >>
> > lcc_win has garbage collection.
> > So effectively you have automatic destructors. C++ allows you to do things like
> > close a file or make an space invader explode in a destructor, but generally this
> > is a bad idea (maybe not the space invaders). Destructors should just free
> > memory, detaching should be done explicitly.
> 
> It certainly is not a bad idea, it is one of the most useful tools in 
> the C++ toolbox.  Amongst other things, it makes resource leaks a thing 
> of the past.  Automatic resource management also removes any possible 
> justification for using goto and those horribly kludgy finalisers in 
> other OO languages.

Maybe. Maybe, in the kind of saturnine, elephantine projects that are
perfectly suited for C++. Maybe even in the _justifiedly_ involved,
large projects that are perfectly suited for ADA or PL/I. But for fuck's
sake, _keep it away from C_! We don't have enough garbage to need
automatic collecting, not if we write our programs sensibly anyway.
Please, please, please. _Do not_ turn C into C++ yet another time. Once
was bad enough.

Richard

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

#58622 — Re: What is "complexifying" C?

On Fri, 20 Mar 2015 03:15:21 -0700 (PDT)
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> On Friday, March 20, 2015 at 8:37:12 AM UTC, Ian Collins wrote:
> > 
> > I agree again.  The one thing C++ can do that C can't is manage
> > resource lifetime with constructors and destructors.  But then
> > again, if you want C++, you know where to find it...
> > 
> lcc_win has garbage collection.
> So effectively you have automatic destructors. C++ allows you to do
> things like close a file or make an space invader explode in a
> destructor, but generally this is a bad idea (maybe not the space
> invaders). Destructors should just free memory, detaching should be
> done explicitly.

In combination with exceptions destructors are must. There is no
need for 'finally'...

[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