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

Groups > comp.lang.c > #68626

Re: sht static guard locks

Show all headers | View raw

On 29/08/15 10:39, fir wrote:
> W dniu sobota, 29 sierpnia 2015 09:47:09 UTC+2 użytkownik fir
> napisał:
>> W dniu sobota, 29 sierpnia 2015 04:28:27 UTC+2 użytkownik Les
>> Cargill napisał:
>>> David Brown wrote: <snip>
>>>>
>>>> All in all, in reality it is an extremely low-cost way to
>>>> eliminate some hard-to-trace potential bugs, and help people
>>>> write correct code as easily as possible.
>>>>
>>>
>>> Dang, David., Nice job.
>>>
>>> I think the worst of all possible worlds is one in which you
>>> write correct code and have no idea how that actually came to
>>> be.
>>>
>> good comment - i forgot such climates long ago but it was
>> remembering me this - coding by hoping this is maybe right ;C
>>
>> Anyway OFC this static guard is not bad becouse it makes thise
>> guards BUT it is bad becouse it not makes no-guards(I mean
>> programmer should choose.. some keyword or attribute like 'guarded'
>> could repair the situation)
>

People (especially in c.l.c) already complain that C++ is too complicated!

And as I wrote in my earlier posts, there are ways to avoid the guards 
if you want, such as by separating initialisation code from the 
constructor code.

> as to c and those initialised statics
>
> 1) the idea that statics could be initialised in some 'deferred' way
> seem at least partially good to me

Yes, it can be a nice thing - but it can be a bad thing too, as 
something that appears to be a fast function can take longer than 
expected as it is handing the initialisation.  And for /very/ heavily 
used functions, even the check of the "objNeedsConstructor" flag is a cost.

Once you understand what is going on, you can make the choices that suit 
your code - but the default given by C++ is with an emphasis on correct 
code, which is good.

>
> (not to say that idea of free initialisers (such functions called
> before main) is good of bad (for me its hard to say)
>
> 2) this kind of initialisation with hidden guard variable is imo not
> quite conformant to explicity spirit of c (seems bad)
>

The hidden guard variable is not in the spirit of C - and it does not 
exist in C.  It /is/ in the spirit of C++, and that is where it is found.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-27 11:11 -0700
  Re: sht static guard locks jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-27 23:15 +0200
    Re: sht static guard locks Ian Collins <ian-news@hotmail.com> - 2015-08-28 09:51 +1200
      Re: sht static guard locks Les Cargill <lcargill99@comcast.com> - 2015-08-27 18:06 -0500
        Re: sht static guard locks David Brown <david.brown@hesbynett.no> - 2015-08-28 10:14 +0200
          Re: sht static guard locks Les Cargill <lcargill99@comcast.com> - 2015-08-28 21:30 -0500
            Re: sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-29 00:46 -0700
              Re: sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-29 01:39 -0700
                Re: sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-29 03:09 -0700
                Re: sht static guard locks David Brown <david.brown@hesbynett.no> - 2015-08-29 12:43 +0200
              Re: sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-29 03:20 -0700
              Re: sht static guard locks fir <profesor.fir@gmail.com> - 2015-08-29 04:28 -0700
            Re: sht static guard locks David Brown <david.brown@hesbynett.no> - 2015-08-29 12:38 +0200
    Re: sht static guard locks Ian Collins <ian-news@hotmail.com> - 2015-08-28 11:02 +1200
      Re: sht static guard locks Gareth Owen <gwowen@gmail.com> - 2015-08-31 18:15 +0100

csiph-web