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

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

C23 (C2x) changes

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

Contents

  C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-20 10:54 +0430
    Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 09:35 +0200
      Re: C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-21 11:01 +0430
    Re: C23 (C2x) changes John Bode <jfbode1029@gmail.com> - 2021-09-20 10:41 -0500
      Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 18:17 +0200
        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 18:55 +0100
          Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-20 18:21 +0000
          Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 21:39 +0200
            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 21:07 +0100
              Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 22:59 +0200
                Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 22:29 +0100
                  Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-20 17:43 -0700
                  Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-21 17:56 +0200
                    Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-21 18:05 +0100
                      Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-21 11:42 -0700
                      Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-22 11:37 +0200
                        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 11:55 +0100
                          Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-22 14:21 +0200
                            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 13:58 +0100
                    Re: C23 (C2x) changes Ian Pilcher <arequipeno@gmail.com> - 2021-09-22 12:02 -0500
                      Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-22 17:19 +0000
            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 23:05 +0100
              Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-20 22:47 +0000
                Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-09-20 22:58 +0000
                Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 07:16 -0700
                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 15:15 +0000
              Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-20 17:45 -0700
          Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-09-27 17:15 +0200
            Re: C23 (C2x) changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-27 17:38 +0100
              Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-09-27 23:18 +0200
                Re: C23 (C2x) changes antispam@math.uni.wroc.pl - 2021-09-28 13:53 +0000
                Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 08:07 -0700
                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 15:18 +0000
                    Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-02 15:04 -0700
                      Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 01:58 +0000
                        Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-02 22:06 -0700
                          Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 10:43 +0000
                            Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 13:30 -0700
                              Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 05:04 +0000
                                Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 23:24 -0700
                                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 06:54 +0000
                                Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-04 09:58 +0200
                                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 15:52 +0000
                                    Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-04 10:45 -0700
                                      Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 20:30 +0000
                                      Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 03:57 -0700
                                        Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 12:27 +0000
            Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 03:38 +0000
        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 11:35 +0100
          Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-10-15 18:27 +0000
            Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 20:08 +0100
            Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-10-15 19:20 +0000
              Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 21:50 +0100
      Re: C23 (C2x) changes Florian Weimer <fw@deneb.enyo.de> - 2021-10-03 09:43 +0200
        Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-03 18:53 +0200
        Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 13:55 -0700
    Re: C23 (C2x) changes William Ahern <william@25thandClement.com> - 2021-09-21 22:57 -0700
      Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 08:55 -0700
        Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 16:36 +0000
    Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-09-22 20:27 +0200
      Re: C23 (C2x) changes Philipp Klaus Krause <pkk@spth.de> - 2021-09-22 22:25 +0200
        Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-22 14:05 -0700
          Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 23:24 +0100
            Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-22 18:49 -0700
          Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-09-23 18:47 +0200
    Static bounds checking (was Re: C23 (C2x) changes) William Ahern <william@25thandClement.com> - 2021-09-23 21:11 -0700
      Re: Static bounds checking (was Re: C23 (C2x) changes) David Brown <david.brown@hesbynett.no> - 2021-09-24 08:51 +0200
        Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 09:30 +0200
      Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 07:52 +0000
        Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 12:32 +0200
          Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 10:49 +0000
            Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 14:46 +0200
        Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-24 18:14 +0200
          Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 01:00 +0000
            Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-25 07:44 +0200
              Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 11:28 +0000
              Re: Static bounds checking (was Re: C23 (C2x) changes) antispam@math.uni.wroc.pl - 2021-09-28 10:56 +0000
            Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 09:48 +0200
              Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 11:30 +0000
                Re: Static bounds checking (was Re: C23 (C2x) changes) Kaz Kylheku <480-992-1380@kylheku.com> - 2021-09-25 20:49 +0000
                  Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-26 00:04 +0000
                Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-26 06:56 +0200
    Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 10:15 -0700
      Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-27 11:15 -0700
        Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-27 22:11 +0200
        Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 14:20 -0700
          Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 14:31 -0700
        Re: C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-28 10:43 +0330
    Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 04:01 -0700
      Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-06 04:42 -0700
        Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 04:04 -0700
          Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-29 16:34 +0200
      Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-06 19:07 +0200
        Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-07 11:06 +0200
          Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-07 19:31 +0200
            Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-07 22:14 +0200
              Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 06:18 -0700
                Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 06:21 -0700
        Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 04:01 -0700
      Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-15 12:59 +0200
        Re: C23 (C2x) changes Jim Jackson <jj@franjam.org.uk> - 2021-10-15 16:50 +0000
          Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-16 07:51 +0200
            Re: C23 (C2x) changes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-16 11:50 -0700
              Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-16 21:28 +0200
                Re: C23 (C2x) changes Jim Jackson <jj@franjam.org.uk> - 2021-10-17 17:18 +0000
                  Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 20:00 +0200
                    Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-17 19:17 +0100
                      Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-18 06:49 +0200
                        Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-18 11:23 +0100
                          Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-18 14:09 +0200
                    Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:07 +0000
                  Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:02 +0000
            Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-16 21:28 +0200
              Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 06:04 +0200
                Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-10-17 19:35 +0200
                  Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 20:01 +0200
                    Re: C23 (C2x) changes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-17 14:15 -0700
                Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:02 +0000
                  Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-21 13:15 +0200

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

#162841 — Re: Static bounds checking (was Re: C23 (C2x) changes)

On 2021-09-25, Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>>> optimizer: the part before the begin of the array, the part within the
>>> array and the part afterwards; that's how Java and Rust do it. And Rust
>>> isn't significantly slower than C or c++.
>>>
>>
>> That's costly.
>> Fact when iterating over array hides it (because of cache), but not all accesses
>> are sequential.
>
> Never mind caching; when you're iterating over an array, you can hoist
> the bounds check out of the loop (if you know that the loop has no
> termination condition other than the array bounds).
>
Thanks, I'll remember that.

-- 

7-77-777
Evil Sinner!

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

#162842 — Re: Static bounds checking (was Re: C23 (C2x) changes)

Am 25.09.2021 um 13:30 schrieb Branimir Maksimovic:
> On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Look, bounds checking is costly, if done in run time, and people think that
>>> using to_string is not efficient :P
>>
>> Bounds-checking is only costly when you have random-access array access.
>> If you iterate linearely the loop will be split in three passes by the
>> optimizer: the part before the begin of the array, the part within the
>> array and the part afterwards; that's how Java and Rust do it. And Rust
>> isn't significantly slower than C or c++.
>>
> 
> That's costly.

No, this linear optimization almost costs nothing. The loops before
and afterwards are only there to throw out of bounds exceptions if
array-elements are actually touched.

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

#162847

On Monday, September 20, 2021 at 3:25:11 AM UTC-3, Mehdi Amini Valashani son of Bahram wrote:
> Hi, 
> 
> It seems these are some of changes for C23(C2x) standard taken from 
> draft documents: 
> 
> https://en.cppreference.com/w/c/23 
> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting 
> 
> What do you think of changes ? 
> 
> One minor suggestion for me is to have format specifier for bool type in 
> printf function. Even though currently the fix is a trivial one.

Something new in C23 are attributes.
One of then is nodiscard :

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf

"
EXAMPLE 2
[[nodiscard]] int important_func(void);
void call(void) {
int i = important_func();
}
No diagnostic for the call to important_func is encouraged despite the value of i not being used.
"
[[nodiscard("must check armed state")]]
bool arm_detonator(int);
void call(void) {
arm_detonator(3);
detonate();
}

"A diagnostic for the call toarm_detonator using the string literal "must check armed state" from the attribute argument
clause is encouraged."

This called my attention because the treatment is different for 
int or _bool
I have no idea why.


And what is funny is that C++ has
[[noreturn]]		
and C  (before attributes and after)
_NoReturn.

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

#162849

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> Something new in C23 are attributes.
> One of then is nodiscard :
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
>
> "
> EXAMPLE 2
> [[nodiscard]] int important_func(void);
> void call(void) {
> int i = important_func();
> }
> No diagnostic for the call to important_func is encouraged despite the value of i not being used.
> "
> [[nodiscard("must check armed state")]]
> bool arm_detonator(int);
> void call(void) {
> arm_detonator(3);
> detonate();
> }
>
> "A diagnostic for the call toarm_detonator using the string literal "must check armed state" from the attribute argument
> clause is encouraged."
>
> This called my attention because the treatment is different for 
> int or _bool
> I have no idea why.

No, there's no difference in the treatment for int and _Bool.

The two relevant examples are:

    [[nodiscard]] int important_func(void);
    void call(void) {
        int i = important_func();
    }

    No diagnostic for the call to important_func is encouraged despite
    the value of i not being used.

and

    [[nodiscard("must check armed state")]]
    bool arm_detonator(int);
    void call(void) {
        arm_detonator(3);
        detonate();
    }

    A diagnostic for the call to arm_detonator using the string literal
    "must check armed state" from the attribute argument clause is
    encouraged.

The difference isn't the types, it's the way the result is used.  In the
first example, the result of the function is used to initialize an
object, so it's "used", even though that object's stored value is never
used.  In the second example, the result isn't assigned to anything.
The point is that compilers aren't required to do data flow analysis;
any immediate use of the result is enough to turn off the warning.  (Of
course compilers can warn about anything they like, and compilers
commonly do warn about unused variables, but that warning isn't
connected to the [[nodiscard]] attribute.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#162851

On 27/09/2021 20:15, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> [...]
>> Something new in C23 are attributes.
>> One of then is nodiscard :
>>
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf
>>
>> "
>> EXAMPLE 2
>> [[nodiscard]] int important_func(void);
>> void call(void) {
>> int i = important_func();
>> }
>> No diagnostic for the call to important_func is encouraged despite the value of i not being used.
>> "
>> [[nodiscard("must check armed state")]]
>> bool arm_detonator(int);
>> void call(void) {
>> arm_detonator(3);
>> detonate();
>> }
>>
>> "A diagnostic for the call toarm_detonator using the string literal "must check armed state" from the attribute argument
>> clause is encouraged."
>>
>> This called my attention because the treatment is different for 
>> int or _bool
>> I have no idea why.
> 
> No, there's no difference in the treatment for int and _Bool.
> 
> The two relevant examples are:
> 
>     [[nodiscard]] int important_func(void);
>     void call(void) {
>         int i = important_func();
>     }
> 
>     No diagnostic for the call to important_func is encouraged despite
>     the value of i not being used.
> 
> and
> 
>     [[nodiscard("must check armed state")]]
>     bool arm_detonator(int);
>     void call(void) {
>         arm_detonator(3);
>         detonate();
>     }
> 
>     A diagnostic for the call to arm_detonator using the string literal
>     "must check armed state" from the attribute argument clause is
>     encouraged.
> 
> The difference isn't the types, it's the way the result is used.  In the
> first example, the result of the function is used to initialize an
> object, so it's "used", even though that object's stored value is never
> used.  In the second example, the result isn't assigned to anything.
> The point is that compilers aren't required to do data flow analysis;
> any immediate use of the result is enough to turn off the warning.  (Of
> course compilers can warn about anything they like, and compilers
> commonly do warn about unused variables, but that warning isn't
> connected to the [[nodiscard]] attribute.)
> 

Or, I think more accurately, it does not have to be connected to the
attribute.  A compiler could choose to warn about "i" not being used in
the first example, precisely because of the attribute, even if it did
not normally warn about unused variables.  There is quite a lot of
freedom about how the attributes are actually implemented.

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

#162853

On Monday, September 27, 2021 at 3:16:07 PM UTC-3, Keith Thompson wrote:
> Thiago Adams <thiago...@gmail.com> writes: 
> [...]
> > Something new in C23 are attributes. 
> > One of then is nodiscard : 
> > 
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf 
> > 
> > " 
> > EXAMPLE 2 
> > [[nodiscard]] int important_func(void); 
> > void call(void) { 
> > int i = important_func(); 
> > } 
> > No diagnostic for the call to important_func is encouraged despite the value of i not being used. 
> > " 
> > [[nodiscard("must check armed state")]] 
> > bool arm_detonator(int); 
> > void call(void) { 
> > arm_detonator(3); 
> > detonate(); 
> > } 
> > 
> > "A diagnostic for the call toarm_detonator using the string literal "must check armed state" from the attribute argument 
> > clause is encouraged." 
> > 
> > This called my attention because the treatment is different for 
> > int or _bool 
> > I have no idea why.
> No, there's no difference in the treatment for int and _Bool. 
> 
> The two relevant examples are:
> [[nodiscard]] int important_func(void); 
> void call(void) { 
> int i = important_func(); 
> } 
> 
> No diagnostic for the call to important_func is encouraged despite 
> the value of i not being used.
> and
> [[nodiscard("must check armed state")]] 
> bool arm_detonator(int); 
> void call(void) { 
> arm_detonator(3); 
> detonate(); 
> }
> A diagnostic for the call to arm_detonator using the string literal
> "must check armed state" from the attribute argument clause is 
> encouraged.
> The difference isn't the types, it's the way the result is used. In the 
> first example, the result of the function is used to initialize an 
> object, so it's "used", even though that object's stored value is never 
> used. In the second example, the result isn't assigned to anything. 
> The point is that compilers aren't required to do data flow analysis; 
> any immediate use of the result is enough to turn off the warning. (Of 
> course compilers can warn about anything they like, and compilers 
> commonly do warn about unused variables, but that warning isn't 
> connected to the [[nodiscard]] attribute.)

hum.. right. 
It is clear now thanks.

Although this can be ignored it looks a good documentation for the "function contract".

(The other topic about [static size] for arrays in that case I was expecting
more to be able to remove runtime checks and sizes.)

In this case it looks more like "nice to have" but not indispensable to change
the code style removing runtime checks for instance.

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

#162854

On Monday, September 27, 2021 at 6:20:51 PM UTC-3, Thiago Adams wrote:
> On Monday, September 27, 2021 at 3:16:07 PM UTC-3, Keith Thompson wrote: 
> > Thiago Adams <thiago...@gmail.com> writes: 
> > [...] 
> > > Something new in C23 are attributes. 
> > > One of then is nodiscard : 
> > > 
> > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf 
> > > 
> > > " 
> > > EXAMPLE 2 
> > > [[nodiscard]] int important_func(void); 
> > > void call(void) { 
> > > int i = important_func(); 
> > > } 
> > > No diagnostic for the call to important_func is encouraged despite the value of i not being used. 
> > > " 
> > > [[nodiscard("must check armed state")]] 
> > > bool arm_detonator(int); 
> > > void call(void) { 
> > > arm_detonator(3); 
> > > detonate(); 
> > > } 
> > > 
> > > "A diagnostic for the call toarm_detonator using the string literal "must check armed state" from the attribute argument 
> > > clause is encouraged." 
> > > 
> > > This called my attention because the treatment is different for 
> > > int or _bool 
> > > I have no idea why. 
> > No, there's no difference in the treatment for int and _Bool. 
> > 
> > The two relevant examples are: 
> > [[nodiscard]] int important_func(void); 
> > void call(void) { 
> > int i = important_func(); 
> > } 
> > 
> > No diagnostic for the call to important_func is encouraged despite 
> > the value of i not being used. 
> > and 
> > [[nodiscard("must check armed state")]] 
> > bool arm_detonator(int); 
> > void call(void) { 
> > arm_detonator(3); 
> > detonate(); 
> > } 
> > A diagnostic for the call to arm_detonator using the string literal 
> > "must check armed state" from the attribute argument clause is 
> > encouraged. 
> > The difference isn't the types, it's the way the result is used. In the 
> > first example, the result of the function is used to initialize an 
> > object, so it's "used", even though that object's stored value is never 
> > used. In the second example, the result isn't assigned to anything. 
> > The point is that compilers aren't required to do data flow analysis; 
> > any immediate use of the result is enough to turn off the warning. (Of 
> > course compilers can warn about anything they like, and compilers 
> > commonly do warn about unused variables, but that warning isn't 
> > connected to the [[nodiscard]] attribute.)
> hum.. right. 
> It is clear now thanks. 
> 
> Although this can be ignored it looks a good documentation for the "function contract". 
> 
> (The other topic about [static size] for arrays in that case I was expecting 
> more to be able to remove runtime checks and sizes.) 
> 
> In this case it looks more like "nice to have" but not indispensable to change 
> the code style removing runtime checks for instance.

Microsoft compiler has the macro _Check_return_
https://docs.microsoft.com/en-us/cpp/code-quality/annotating-function-behavior?view=msvc-160

Another point about attributes is that they are optional for code generation, (at least standard ones)

"166)Standard attributes specified by this document can be parsed but ignored by
 an implementation without changing the semantics of a correct program; the same is not true 
for attributes not specified by this document."

but we cannot use an old compilers because the parsing will fail. so.. the macros will remain
or the code will be changed gradually.

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

#162855

On 9/27/21 9:45 PM, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> [...]
[...]
> The difference isn't the types, it's the way the result is used.  In the
> first example, the result of the function is used to initialize an
> object, so it's "used", even though that object's stored value is never
> used.  In the second example, the result isn't assigned to anything.
> The point is that compilers aren't required to do data flow analysis;
> any immediate use of the result is enough to turn off the warning.  (Of
> course compilers can warn about anything they like, and compilers
> commonly do warn about unused variables, but that warning isn't
> connected to the [[nodiscard]] attribute.)
> 

Thank you for explanation. I also found this link for nodiscard
attribute:

https://en.cppreference.com/w/c/language/attributes/nodiscard

I have a question about attributes too. Coder may use attributes
directly or he/she may include a header file (<attributes.h> for
instance) ?

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

#163015

Mehdi Amini <atorrses@gmail.com> writes:

> It seems these are some of changes for C23(C2x) standard taken from
> draft documents:
>
> https://en.cppreference.com/w/c/23
> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>
> What do you think of changes ?

My impression is that as time goes on C is looking more and more like
C++ and less and less like C.  That's a bad trend.

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

#163017

On Wednesday, October 6, 2021 at 8:01:38 AM UTC-3, Tim Rentsch wrote:
> Mehdi Amini <ator...@gmail.com> writes: 
> 
> > It seems these are some of changes for C23(C2x) standard taken from 
> > draft documents: 
> > 
> > https://en.cppreference.com/w/c/23 
> > https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting 
> > 
> > What do you think of changes ? 
> 
> My impression is that as time goes on C is looking more and more like 
> C++ and less and less like C. That's a bad trend.

I don't think C is going that way. At least for now..
Do you have any proposal in mind to justify this?

One feature that may be in that direction is nullptr (but not approved yet)
not because it is complex but because it can create (like C++)
multiple ways to do the same thing creating a mess
in my opinion. 
There are other more radical proposals but they are not approved yet.

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

#163232

Thiago Adams <thiago.adams@gmail.com> writes:

> On Wednesday, October 6, 2021 at 8:01:38 AM UTC-3, Tim Rentsch wrote:
>
>> Mehdi Amini <ator...@gmail.com> writes:
>>
>>> It seems these are some of changes for C23(C2x) standard taken from
>>> draft documents:
>>>
>>> https://en.cppreference.com/w/c/23
>>> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>>>
>>> What do you think of changes ?
>>
>> My impression is that as time goes on C is looking more and more like
>> C++ and less and less like C. That's a bad trend.
>
> I don't think C is going that way.  At least for now..
> Do you have any proposal in mind to justify this?  [...]

Forgive me for being blunt, but I find your postings idiotic.
I don't see any value in participating in that idiocy.

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

#163239

On 29/10/2021 13:04, Tim Rentsch wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> 
>> On Wednesday, October 6, 2021 at 8:01:38 AM UTC-3, Tim Rentsch wrote:
>>
>>> Mehdi Amini <ator...@gmail.com> writes:
>>>
>>>> It seems these are some of changes for C23(C2x) standard taken from
>>>> draft documents:
>>>>
>>>> https://en.cppreference.com/w/c/23
>>>> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>>>>
>>>> What do you think of changes ?
>>>
>>> My impression is that as time goes on C is looking more and more like
>>> C++ and less and less like C. That's a bad trend.
>>
>> I don't think C is going that way.  At least for now..
>> Do you have any proposal in mind to justify this?  [...]
> 
> Forgive me for being blunt, but I find your postings idiotic.
> I don't see any value in participating in that idiocy.
> 

Disagreeing with your out-of-the-blue statement and asking for examples
and justification is being "idiotic" ?  Even by your usual low
standards, Tim, that is unreasonable.

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

#163025

Le 06/10/2021 à 13:01, Tim Rentsch a écrit :
> Mehdi Amini <atorrses@gmail.com> writes:
> 
>> It seems these are some of changes for C23(C2x) standard taken from
>> draft documents:
>>
>> https://en.cppreference.com/w/c/23
>> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>>
>> What do you think of changes ?
> 
> My impression is that as time goes on C is looking more and more like
> C++ and less and less like C.  That's a bad trend.

It's really far from it.

What makes you say that is probably that C borrows some "features" from 
C++ at each new revision, but it's not a new trend.

The "features" it borrows from C++ are nothing that inherently makes C++ 
though, and IMO the majority of them are just things that were 
long-awaited in C, without breaking the essence of C at all, and there's 
no good reason to reinvent the wheel if those are already defined in C++.

With that said, from the C++ perspective, Bjarne Stroustrup (and 
probably followed by the C++ committee) has always been, and still is, a 
vehement proponent of fusing C into C++, making it a strict subset of 
C++, instead of the current situation, with two different languages. Now 
what kind of influence the C++ committee has over the C committee, I do 
not know. I guess the main reason for including some C++ features into C 
is the one I stated above: if C is going to get new features that are 
similar to some that already exist in C++, why make them different and 
further make the two languages divergent for no good reason?

Now, feel free to give relevant examples of C++ features that found 
their way into C and which you think have no place there, with a 
rationale. I'm all ears.

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

#163039

On 06/10/2021 19:07, Guillaume wrote:
> Le 06/10/2021 à 13:01, Tim Rentsch a écrit :
>> Mehdi Amini <atorrses@gmail.com> writes:
>>
>>> It seems these are some of changes for C23(C2x) standard taken from
>>> draft documents:
>>>
>>> https://en.cppreference.com/w/c/23
>>> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>>>
>>> What do you think of changes ?
>>
>> My impression is that as time goes on C is looking more and more like
>> C++ and less and less like C.  That's a bad trend.
> 
> It's really far from it.
> 
> What makes you say that is probably that C borrows some "features" from
> C++ at each new revision, but it's not a new trend.
> 
> The "features" it borrows from C++ are nothing that inherently makes C++
> though, and IMO the majority of them are just things that were
> long-awaited in C, without breaking the essence of C at all, and there's
> no good reason to reinvent the wheel if those are already defined in C++.
> 

That is absolutely the case, as I see it.  There are several good
reasons for it.  The C committee don't like adding new things to the
language unless they are /really/ sure they are a good idea.  One way to
do that is to look at the practice from C++.  Another is to look at
current C implementations with extensions - tools like gcc and clang
have a long history of letting some features flow between C and C++, if
they can be done without conflict.  So in many cases, stretching back to
C99, the C committee have merely standardised C++ features that gcc had
already supported in C compilation.  Low risk, low effort, and useful in
practice - what's not to like?

There are some people who stubbornly insist that C and C++ are
completely separate, and should progress independently.  In reality,
mixes occur on a regular basis.  Libraries or code gets written in C and
used in C++ projects - it's vital that most of what could reasonably be
expected to be in a C header, should also be valid and usable with C++
(possibly with an extern "C" wrapper).  Real-world projects can often
start as C, and migrate towards C++ for new code - or they can be
started in C++ and borrow old C code.  Toolchains support both
languages, and arbitrary differences just means more work.  The same
applies to things like syntax highlighting editors.  And in the MSVC
world, people writing C code generally use the C++ compiler because it
is (or has traditionally been) better than compiling as C.


> With that said, from the C++ perspective, Bjarne Stroustrup (and
> probably followed by the C++ committee) has always been, and still is, a
> vehement proponent of fusing C into C++, making it a strict subset of
> C++, instead of the current situation, with two different languages. Now
> what kind of influence the C++ committee has over the C committee, I do
> not know. I guess the main reason for including some C++ features into C
> is the one I stated above: if C is going to get new features that are
> similar to some that already exist in C++, why make them different and
> further make the two languages divergent for no good reason?
> 
> Now, feel free to give relevant examples of C++ features that found
> their way into C and which you think have no place there, with a
> rationale. I'm all ears.
> 

One proposal that I can think of is lambdas - there have been proposals
to add these to C, and these really don't seem a good fit to me.  One
source of many of these ideas is Jens Gustedt, who is one of the few C
standards committee members who has a significant public internet
presence with his blog, and is quite prolific with his ideas and
proposals.  Some of his ideas come from C++, others are new to both
languages.  (Most C committee members are more anonymous, at least
compared to the C++ committee.  That is quite appropriate for a language
that changes slowly and values stability so highly.)  Of course Jens is
free to bring up his ideas - that does not mean that they will be
accepted by the committee as a whole.

As to features that C has already copied from C++, rather than just
proposals, which don't fit the style and philosophy of C - I can't think
of any off-hand.  Tim will have to give examples himself.

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

#163045

Le 07/10/2021 à 11:06, David Brown a écrit :
> One proposal that I can think of is lambdas - there have been proposals
> to add these to C, and these really don't seem a good fit to me.

Yeah. Absolutely. I'm already not sure they are a good fit for C++, but 
then again, C++ is this kind of all-you-can-eat buffet, so... sadly, I 
think it's eventually going to collapse under its own weight.

Jens Gustedt has a lot of interesting ideas from what I've read, but 
he's a researcher. I'll take the practicality of his proposals with a 
pinch of salt.

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

#163046

On 07/10/2021 19:31, Guillaume wrote:
> Le 07/10/2021 à 11:06, David Brown a écrit :
>> One proposal that I can think of is lambdas - there have been proposals
>> to add these to C, and these really don't seem a good fit to me.
> 
> Yeah. Absolutely. I'm already not sure they are a good fit for C++, but
> then again, C++ is this kind of all-you-can-eat buffet, so... sadly, I
> think it's eventually going to collapse under its own weight.
> 

I like lambdas, and I'm glad C++ supports them.

But I agree that there are risks in the feature growth of C++ - while
individual programmers are usually going to be happy with just a subset
of the features, different programmers are going to pick different
subsets, and people are inevitably going to find themselves faced with
code that is written in the language they "know" while still being alien
to them.

> Jens Gustedt has a lot of interesting ideas from what I've read, but
> he's a researcher. I'll take the practicality of his proposals with a
> pinch of salt.
> 

I think it is important for a language to have many people involved -
including more theoretical researcher types and more practical types.

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

#163047

On Thursday, October 7, 2021 at 5:14:56 PM UTC-3, David Brown wrote:
> On 07/10/2021 19:31, Guillaume wrote: 
> > Le 07/10/2021 à 11:06, David Brown a écrit : 
> >> One proposal that I can think of is lambdas - there have been proposals 
> >> to add these to C, and these really don't seem a good fit to me. 
> > 
> > Yeah. Absolutely. I'm already not sure they are a good fit for C++, but 
> > then again, C++ is this kind of all-you-can-eat buffet, so... sadly, I 
> > think it's eventually going to collapse under its own weight. 
> >
> I like lambdas, and I'm glad C++ supports them. 

The difficult (and I believe controversial) part in C is capture and how to store 
lambda on heap for instance. It also requires the feature "auto" to work.

Here we can find how it is suppose to work in c here:
https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my

The amount of code to create a lambda and store on heap is similar of
the amount of the code we have today without this feature. 
So, I am not convinced yet that C needs lambda capture.

I miss Lambdas a lot in my C code. Lambdas without capture would be fine for me.
The syntax and feature I  would be happy is:

(void (void* data) ) {    printf("hi!");   }

It if very similar of compound literal of function pointer.

(void (void (*) data) ) {   0  }

The difference it creates a compound literal that is a function itself.

I have implemented this at my transpiler

Select "Function Literal"
http://thradams.com/web2/cprime.html

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

#163048

On Friday, October 8, 2021 at 10:18:29 AM UTC-3, Thiago Adams wrote:
> On Thursday, October 7, 2021 at 5:14:56 PM UTC-3, David Brown wrote: 
> > On 07/10/2021 19:31, Guillaume wrote: 
> > > Le 07/10/2021 à 11:06, David Brown a écrit : 
> > >> One proposal that I can think of is lambdas - there have been proposals 
> > >> to add these to C, and these really don't seem a good fit to me. 
> > > 
> > > Yeah. Absolutely. I'm already not sure they are a good fit for C++, but 
> > > then again, C++ is this kind of all-you-can-eat buffet, so... sadly, I 
> > > think it's eventually going to collapse under its own weight. 
> > > 
> > I like lambdas, and I'm glad C++ supports them.
> The difficult (and I believe controversial) part in C is capture and how to store 
> lambda on heap for instance. It also requires the feature "auto" to work. 
> 
> Here we can find how it is suppose to work in c here: 
> https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my 
> 
> The amount of code to create a lambda and store on heap is similar of 
> the amount of the code we have today without this feature. 
> So, I am not convinced yet that C needs lambda capture. 
> 
> I miss Lambdas a lot in my C code. Lambdas without capture would be fine for me. 
> The syntax and feature I would be happy is: 
> 
> (void (void* data) ) { printf("hi!"); } 
> 
> It if very similar of compound literal of function pointer. 
> 
> (void (void (*) data) ) { 0 } 
> 
> The difference it creates a compound literal that is a function itself. 
> 
> I have implemented this at my transpiler 
> 
> Select "Function Literal" 
> http://thradams.com/web2/cprime.html

I forgot to mention that lambdas in C++ also required addition of
return type.

[] (void) -> int

and mutable.

So lambdas with capture is a good example of how things can go bad in C.

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

#163231

Guillaume <message@bottle.org> writes:

> Le 06/10/2021 at 13:01, Tim Rentsch a ecrit:
>
>> Mehdi Amini <atorrses@gmail.com> writes:
>>
>>> It seems these are some of changes for C23(C2x) standard taken from
>>> draft documents:
>>>
>>> https://en.cppreference.com/w/c/23
>>> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>>>
>>> What do you think of changes ?
>>
>> My impression is that as time goes on C is looking more and more
>> like C++ and less and less like C.  That's a bad trend.
>
> It's really far from it.
>
> What makes you say that is probably that C borrows some "features"
> from C++ at each new revision, but it's not a new trend.
>
> The "features" it borrows from C++ are nothing that inherently makes
> C++ though, and IMO the majority of them are just things that were
> long-awaited in C, without breaking the essence of C at all, and
> there's no good reason to reinvent the wheel if those are already
> defined in C++.
>
> With that said, from the C++ perspective, Bjarne Stroustrup (and
> probably followed by the C++ committee) has always been, and still
> is, a vehement proponent of fusing C into C++, making it a strict
> subset of C++, instead of the current situation, with two different
> languages.  Now what kind of influence the C++ committee has over
> the C committee, I do not know.  I guess the main reason for
> including some C++ features into C is the one I stated above:  if C
> is going to get new features that are similar to some that already
> exist in C++, why make them different and further make the two
> languages divergent for no good reason?

None of the foregoing comments changes my reaction to the
proposal summary or my assessment of the trend.

> Now, feel free to give relevant examples of C++ features that found
> their way into C and which you think have no place there, with a
> rationale.  I'm all ears.

Given your statements above, what is my incentive for doing that?

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

#163094

> My impression is that as time goes on C is looking more and
> more like C++ and less and less like C.  That's a bad trend.

C should be dropped in favour of C++ for almost any project. With C
you have a dramatic less development-performance and make much more
bugs. If Chrome f.e. would be developed in C, it would be at least
five times the code and ten times the number of bugs.

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

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

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

csiph-web