Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #82895 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2022-02-04 13:54 +0100 |
| Last post | 2022-02-07 18:30 +0100 |
| Articles | 20 on this page of 103 — 18 participants |
Back to article view | Back to comp.lang.c++
C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 13:54 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-04 14:25 +0000
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 15:31 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-04 14:54 +0000
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 17:41 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-05 11:31 +0000
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 12:49 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-05 12:20 +0000
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-04 16:15 +0000
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 17:43 +0100
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 01:51 +0100
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-05 01:59 +0000
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-04 23:05 -0500
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 11:56 +0100
Re: C++20 concepts rocks David Brown <david.brown@hesbynett.no> - 2022-02-05 13:53 +0100
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 14:12 +0100
Re: C++20 concepts rocks Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2022-02-12 11:13 -0800
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-12 22:18 -0500
Re: C++20 concepts rocks Richard Damon <Richard@Damon-Family.org> - 2022-02-13 12:51 -0500
Re: C++20 concepts rocks Paavo Helde <eesnimi@osa.pri.ee> - 2022-02-13 20:16 +0200
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-13 14:12 -0500
Re: C++20 concepts rocks Richard Damon <Richard@Damon-Family.org> - 2022-02-13 16:22 -0500
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-13 17:18 -0500
Re: C++20 concepts rocks Öö Tiib <ootiib@hot.ee> - 2022-02-14 00:51 -0800
Re: C++20 concepts rocks "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-02-14 08:29 -0800
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-04 23:37 -0800
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 11:58 +0100
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 02:16 -0800
Re: C++20 concepts rocks "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-02-05 12:35 -0800
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 05:54 -0800
Re: C++20 concepts rocks Manfred <noname@add.invalid> - 2022-02-06 19:43 +0100
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-04 23:53 -0800
Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-05 10:10 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 19:51 +0100
Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-05 16:42 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-06 01:39 +0000
Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-05 18:02 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 09:57 +0100
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-06 10:57 +0100
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 12:40 +0100
Re: C++20 concepts rocks Öö Tiib <ootiib@hot.ee> - 2022-02-06 03:53 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-06 14:35 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 11:20 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-06 21:53 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 19:03 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-07 11:50 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 06:26 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-07 15:48 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 12:16 -0800
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 22:27 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-09 21:43 +0000
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-09 21:07 -0500
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-09 21:25 -0800
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-10 13:05 +0000
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-10 11:19 -0500
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-11 05:41 -0800
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-11 17:06 +0100
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-11 11:50 -0500
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-11 21:13 +0100
Re: C++20 concepts rocks scott@slp53.sl.home (Scott Lurndal) - 2022-02-11 17:06 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-15 00:10 -0800
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-15 20:58 +0100
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-16 06:40 +0000
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-16 09:54 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-16 09:00 +0000
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-16 20:25 +0100
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-17 08:53 +0000
Re: C++20 concepts rocks Paavo Helde <eesnimi@osa.pri.ee> - 2022-02-17 16:11 +0200
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-17 10:58 -0500
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-17 07:32 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-19 02:21 -0700
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-19 11:56 +0200
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 03:02 -0700
Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-12 00:01 +0000
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-14 23:55 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 18:31 +0100
Re: C++20 concepts rocks scott@slp53.sl.home (Scott Lurndal) - 2022-02-07 17:43 +0000
Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-06 14:25 -0500
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 02:01 -0800
Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-06 19:37 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 10:18 +0100
Re: C++20 concepts rocks Paavo Helde <eesnimi@osa.pri.ee> - 2022-02-07 11:32 +0200
Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-07 07:55 -0800
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 02:11 -0800
Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-06 13:13 +0100
Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 04:58 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 14:08 +0100
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 12:48 +0100
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-04 20:15 +0000
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-05 11:32 +0000
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-06 08:28 +0000
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-07 09:52 +0000
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-08 07:05 +0000
Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-08 09:25 +0000
Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-08 10:09 +0000
Re: C++20 concepts rocks Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-02-04 12:10 -0800
Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 13:41 +0100
Re: C++20 concepts rocks "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-02-05 19:28 -0800
A little benchmark: Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 13:22 +0100
A better benchmark Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 14:56 +0100
A improved routine Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 15:19 +0100
Re: A better benchmark Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 06:57 -0800
Re: A better benchmark Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 18:30 +0100
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-02-13 14:12 -0500 |
| Message-ID | <subl6c$su9$1@dont-email.me> |
| In reply to | #82994 |
On 2/13/22 13:16, Paavo Helde wrote: > 13.02.2022 05:18 James Kuyper kirjutas: ... >> "The unary & operator yields the address of its operand. ... If the >> operand is the result of a unary * operator, neither that operator nor >> the & operator is evaluated and the result is as if both were omitted, >> except that the constraints on the operators still apply and the result >> is not an lvalue." (6.5.3.2p3). >> >> Because of that clause, if there's no problem an expression E that has a >> pointer type, and if &*E violates no constraints, then there's also no >> problem with &*E, which has the same value, even if *E would have had >> undefined behavior (for instance, if the value of E is a null pointer or >> (as in this case) points one past the end of an array. >> >> I don't know why the C++ committee never choose to add similar wording >> to the C++ standard. > > One reason might be that this wording would prohibit debugging > implementations of operator[] which check its arguments and fail if it > is >=N. > > Such an instrumented operator[] would not have a way to know if its > result is immediately passed to the & operator or not, so it cannot > take this into an account. For a compiler implementer it would be > easier to take into account, so e.g. the gcc bounds-checking regime > would still be possible to implement, but an ordinary user-defined > bounds-checking operator[] would not be possible. > > So I would say the difference of C and C++ in this aspect is because > in C++ one can redefine operator[], but not in C. "... Overloaded operators obey the rules for syntax and evaluation order specified in 7.6, but the requirements of operand type and value category are replaced by the rules for function call. Relations between operators, such as ++a meaning a+=1, are not guaranteed for overloaded operators" (7.1p2) "Subclause 7.6 defines the effects of operators when applied to types for which they have not been overloaded." (7.1p3). For example, 7.6.1.1p3 specifies that "E1[E2] is identical (by definition) to *((E1)+(E2))", a specification that doesn't apply if operator[](), operator*(), or operator+() is overloaded for any of the relevant types. Why would inserting a rule into section 7.6.2.1, saying that &*(E) is equivalent to E, be any more problematic than the rule that a++ means a+=1, or that E1[E2] == *(E1 + E2)?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-02-13 16:22 -0500 |
| Message-ID | <IEeOJ.8296$WZCa.833@fx08.iad> |
| In reply to | #82995 |
On 2/13/22 2:12 PM, James Kuyper wrote: > On 2/13/22 13:16, Paavo Helde wrote: >> 13.02.2022 05:18 James Kuyper kirjutas: > ... >>> "The unary & operator yields the address of its operand. ... If the >>> operand is the result of a unary * operator, neither that operator nor >>> the & operator is evaluated and the result is as if both were omitted, >>> except that the constraints on the operators still apply and the result >>> is not an lvalue." (6.5.3.2p3). >>> >>> Because of that clause, if there's no problem an expression E that has a >>> pointer type, and if &*E violates no constraints, then there's also no >>> problem with &*E, which has the same value, even if *E would have had >>> undefined behavior (for instance, if the value of E is a null pointer or >>> (as in this case) points one past the end of an array. >>> >>> I don't know why the C++ committee never choose to add similar wording >>> to the C++ standard. >> >> One reason might be that this wording would prohibit debugging >> implementations of operator[] which check its arguments and fail if it >> is >=N. >> >> Such an instrumented operator[] would not have a way to know if its >> result is immediately passed to the & operator or not, so it cannot >> take this into an account. For a compiler implementer it would be >> easier to take into account, so e.g. the gcc bounds-checking regime >> would still be possible to implement, but an ordinary user-defined >> bounds-checking operator[] would not be possible. >> >> So I would say the difference of C and C++ in this aspect is because >> in C++ one can redefine operator[], but not in C. > > "... Overloaded operators obey the rules for syntax and evaluation order > specified in 7.6, but the requirements of operand type and value > category are replaced by the rules for function call. Relations between > operators, such as ++a meaning a+=1, are not guaranteed for overloaded > operators" (7.1p2) > "Subclause 7.6 defines the effects of operators when applied to types > for which they have not been overloaded." (7.1p3). > > For example, 7.6.1.1p3 specifies that "E1[E2] is identical (by > definition) to *((E1)+(E2))", a specification that doesn't apply if > operator[](), operator*(), or operator+() is overloaded for any of the > relevant types. > > Why would inserting a rule into section 7.6.2.1, saying that &*(E) is > equivalent to E, be any more problematic than the rule that a++ means > a+=1, or that E1[E2] == *(E1 + E2)? > Except that rule says that the compiler CAN'T assume that either a++ is equivalent to a += 1 or that E1[E2] means the same as *(E1 + E2), which means that the concept that &* cancelation might not be actually applicable. I suspect that there are ways of using 'proxy objects' as the results of a user defined operator*() that would allow you to implement that sort of rule, maybe even at minimal or no actual run-time cost, but it is not the most straight forward way (or the only way) to implement operator*() and thus the &* cancelation is NOT a promise by the Standard.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-02-13 17:18 -0500 |
| Message-ID | <suc03g$bn8$1@dont-email.me> |
| In reply to | #82996 |
On 2/13/22 16:22, Richard Damon wrote: > On 2/13/22 2:12 PM, James Kuyper wrote: >> On 2/13/22 13:16, Paavo Helde wrote: >>> 13.02.2022 05:18 James Kuyper kirjutas: >> ... >>>> "The unary & operator yields the address of its operand. ... If the >>>> operand is the result of a unary * operator, neither that operator nor >>>> the & operator is evaluated and the result is as if both were omitted, >>>> except that the constraints on the operators still apply and the result >>>> is not an lvalue." (6.5.3.2p3). >>>> >>>> Because of that clause, if there's no problem an expression E that >>>> has a >>>> pointer type, and if &*E violates no constraints, then there's also no >>>> problem with &*E, which has the same value, even if *E would have had >>>> undefined behavior (for instance, if the value of E is a null >>>> pointer or >>>> (as in this case) points one past the end of an array. >>>> >>>> I don't know why the C++ committee never choose to add similar wording >>>> to the C++ standard. >>> >>> One reason might be that this wording would prohibit debugging >>> implementations of operator[] which check its arguments and fail if it >>> is >=N. >>> >>> Such an instrumented operator[] would not have a way to know if its >>> result is immediately passed to the & operator or not, so it cannot >>> take this into an account. For a compiler implementer it would be >>> easier to take into account, so e.g. the gcc bounds-checking regime >>> would still be possible to implement, but an ordinary user-defined >>> bounds-checking operator[] would not be possible. >>> >>> So I would say the difference of C and C++ in this aspect is because >>> in C++ one can redefine operator[], but not in C. >> >> "... Overloaded operators obey the rules for syntax and evaluation order >> specified in 7.6, but the requirements of operand type and value >> category are replaced by the rules for function call. Relations between >> operators, such as ++a meaning a+=1, are not guaranteed for overloaded >> operators" (7.1p2) >> "Subclause 7.6 defines the effects of operators when applied to types >> for which they have not been overloaded." (7.1p3). >> >> For example, 7.6.1.1p3 specifies that "E1[E2] is identical (by >> definition) to *((E1)+(E2))", a specification that doesn't apply if >> operator[](), operator*(), or operator+() is overloaded for any of the >> relevant types. >> >> Why would inserting a rule into section 7.6.2.1, saying that &*(E) is >> equivalent to E, be any more problematic than the rule that a++ means >> a+=1, or that E1[E2] == *(E1 + E2)? >> > > Except that rule says that the compiler CAN'T assume that either a++ > is equivalent to a += 1 or that E1[E2] means the same as *(E1 + E2), > which Yes, when operator overloads come into play (and the compiler necessarily knows when that is the case), it also knows that it can't assume a++ means a+=1, E1[E2] means *(E1+E2), and I'm suggesting that it could also not assume that &*(E) can be replaced by E. When operator overloads don't come into play, it works the other way around. A developer who knows that overloads are not involved can be absolutely certain that implementation must treat a++ as meanin a+=1, and E1[E2] as meanin *(E1+E2), and I'm suggesting that he should also be absolutely certain that the implementation must treat &*(E) as equivalent to E. I don't see why borrowing this rule from C would be any more problematic than the other two rules (also borrowed from C). > means that the concept that &* cancelation might not be actually > applicable. > > I suspect that there are ways of using 'proxy objects' as the results > of a user defined operator*() that would allow you to implement that > sort of rule, maybe even at minimal or no actual run-time cost, but it > is not the most straight forward way (or the only way) to implement > operator*() and thus the &* cancelation is NOT a promise by the Standard. Sure - and in precisely those circumstances, as specified by 7.1p3, the new rule (which would belong in 7.6.2.1, and therefore within the scope of applicability of 7.1p3), would not apply, any more than a++ means a+=1 or E1[E2] means *(E1+E2). When operator overloads allow proxy objects to come in play, all three of those requirements get thrown out the window.fhyt
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-02-14 00:51 -0800 |
| Message-ID | <23722bd9-ec00-4b9e-9f13-6cb779ab38fen@googlegroups.com> |
| In reply to | #82996 |
On Sunday, 13 February 2022 at 23:23:36 UTC+2, Richard Damon wrote: > On 2/13/22 2:12 PM, James Kuyper wrote: > > On 2/13/22 13:16, Paavo Helde wrote: > >> 13.02.2022 05:18 James Kuyper kirjutas: > > ... > >>> "The unary & operator yields the address of its operand. ... If the > >>> operand is the result of a unary * operator, neither that operator nor > >>> the & operator is evaluated and the result is as if both were omitted, > >>> except that the constraints on the operators still apply and the result > >>> is not an lvalue." (6.5.3.2p3). > >>> > >>> Because of that clause, if there's no problem an expression E that has a > >>> pointer type, and if &*E violates no constraints, then there's also no > >>> problem with &*E, which has the same value, even if *E would have had > >>> undefined behavior (for instance, if the value of E is a null pointer or > >>> (as in this case) points one past the end of an array. > >>> > >>> I don't know why the C++ committee never choose to add similar wording > >>> to the C++ standard. > >> > >> One reason might be that this wording would prohibit debugging > >> implementations of operator[] which check its arguments and fail if it > >> is >=N. > >> > >> Such an instrumented operator[] would not have a way to know if its > >> result is immediately passed to the & operator or not, so it cannot > >> take this into an account. For a compiler implementer it would be > >> easier to take into account, so e.g. the gcc bounds-checking regime > >> would still be possible to implement, but an ordinary user-defined > >> bounds-checking operator[] would not be possible. > >> > >> So I would say the difference of C and C++ in this aspect is because > >> in C++ one can redefine operator[], but not in C. > > > > "... Overloaded operators obey the rules for syntax and evaluation order > > specified in 7.6, but the requirements of operand type and value > > category are replaced by the rules for function call. Relations between > > operators, such as ++a meaning a+=1, are not guaranteed for overloaded > > operators" (7.1p2) > > "Subclause 7.6 defines the effects of operators when applied to types > > for which they have not been overloaded." (7.1p3). > > > > For example, 7.6.1.1p3 specifies that "E1[E2] is identical (by > > definition) to *((E1)+(E2))", a specification that doesn't apply if > > operator[](), operator*(), or operator+() is overloaded for any of the > > relevant types. > > > > Why would inserting a rule into section 7.6.2.1, saying that &*(E) is > > equivalent to E, be any more problematic than the rule that a++ means > > a+=1, or that E1[E2] == *(E1 + E2)? > > > Except that rule says that the compiler CAN'T assume that either a++ is > equivalent to a += 1 or that E1[E2] means the same as *(E1 + E2), which > means that the concept that &* cancelation might not be actually applicable. > > I suspect that there are ways of using 'proxy objects' as the results of > a user defined operator*() that would allow you to implement that sort > of rule, maybe even at minimal or no actual run-time cost, but it is not > the most straight forward way (or the only way) to implement operator*() > and thus the &* cancelation is NOT a promise by the Standard. Is it still about that ... char result[28], *ep = (&result)[1]; ? Or maybe it has gone elsewhere? AFAIK user can't overload operators for char[28] . So compiler must assume that nothing has been overloaded.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-02-14 08:29 -0800 |
| Message-ID | <25a4fe17-3601-4f57-b78a-cd8a6948b05dn@googlegroups.com> |
| In reply to | #82998 |
On Monday, February 14, 2022 at 3:52:23 AM UTC-5, Öö Tiib wrote:
> On Sunday, 13 February 2022 at 23:23:36 UTC+2, Richard Damon wrote:
> > On 2/13/22 2:12 PM, James Kuyper wrote:
> > > On 2/13/22 13:16, Paavo Helde wrote:
> > >> 13.02.2022 05:18 James Kuyper kirjutas:
> > > ...
> > >>> "The unary & operator yields the address of its operand. ... If the
> > >>> operand is the result of a unary * operator, neither that operator nor
> > >>> the & operator is evaluated and the result is as if both were omitted,
> > >>> except that the constraints on the operators still apply and the result
> > >>> is not an lvalue." (6.5.3.2p3).
...
> > > Why would inserting a rule into section 7.6.2.1, saying that &*(E) is
> > > equivalent to E, be any more problematic than the rule that a++ means
> > > a+=1, or that E1[E2] == *(E1 + E2)?
> > >
> > Except that rule says that the compiler CAN'T assume that either a++ is
> > equivalent to a += 1 or that E1[E2] means the same as *(E1 + E2), which
> > means that the concept that &* cancelation might not be actually applicable.
> >
> > I suspect that there are ways of using 'proxy objects' as the results of
> > a user defined operator*() that would allow you to implement that sort
> > of rule, maybe even at minimal or no actual run-time cost, but it is not
> > the most straight forward way (or the only way) to implement operator*()
> > and thus the &* cancelation is NOT a promise by the Standard.
> Is it still about that ... char result[28], *ep = (&result)[1]; ? ...
No. That code doesn't make use if &*. Therefore, whether or not &* cancels is
irrelevant to it. `(&result)[1]` is equivalent to `*(&result + 1)`. For purposes of
pointer arithmetic, `result` is treated as the first and only element of a one
element array whose elements have the type char[20]. While that does
nominally dereference a pointer to the hypothetical element one past the end
of that 1-element array, the result of that dereference has the type char[20].
That is an array type, and is therefore implicitly converted into a pointer to the
first element of that array. Under such circumstances, I don't think
this should count as undefined behavior, but I admit that the standard isn't clear
on that point.
However, four lines later, the line
> ep -= 4;
appears, which does have undefined behavior, because it tries to move that
pointer before the beginning of the hypothetical array that it point into, but I don't
think there's anything wrong with `(&result)[1]` itself.
> ... Or maybe it
> has gone elsewhere?
Yes. On February 5th, David Brown posted the following code as part of the discussion:
> char r[20];
>
> void foo1(void) {
> char *p = &r[20];
On February 12th, Anand Harihan criticized that code based upon the fact that r[20]
dereferences a pointer one past the end of an array. I'm afraid he has a point - but only
because the C++ standard doesn't have wording comparable to 6.5.3.2p3 from the C
standard, cited above.
> ... AFAIK user can't overload operators for
> char[28] . So compiler must assume that nothing has been overloaded.
While thread of this discussion now involves a different bit of code, your comment is
still relevant. No overloads apply, so if wording equivalent to C's 6.5.3.2p3 were
inserted into the C++ standard, it would be applicable, despite the fact that it wouldn't
apply to cases where operator overloads were involved.
Of course, on the very next line of code, it says
> p--;
Which has undefined behavior for the same reason that `ep -= 4` did, so the question is
moot, either way.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-02-04 23:37 -0800 |
| Message-ID | <86a6f5lq76.fsf@linuxsc.com> |
| In reply to | #82904 |
"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
> On 4 Feb 2022 17:15, Ben Bacarisse wrote:
[...]
>> template<typename StringType>
>> requires is_same_v<StringType,
>> basic_string<typename StringType::value_type,
>> typename StringType::traits_type,
>> typename StringType::allocator_type>>
>> StringType formatClockCycles(uint64_t clockCycles)
>> {
>> char result[28], *ep = (&result)[1];
>> do {
>> sprintf(ep - 4, "%03lu", clockCycles % 1000);
>> if (ep != (&result)[1]) ep[-1] = '.';
>> ep -= 4;
>> } while (clockCycles /= 1000);
>> while (*ep == '0' && ep[1]) ep++;
>> return ep;
>> }
>>
>> (the appropriate comment on the 28 is left as an exercise to the reader!)
>
> Nice, but I believe it's formal UB to move a pointer to `char` from
> beyond an array into the array, and dereference it.
>
> The C committee wrote a rationale for their earlier decision to make
> it so, instead of admitting that it was bludner. Uh, blunder. I
> don't recall who provided that information, but someone in this
> group.
I suspect that you either are misremembering or have misunderstood.
Usage patterns like that seen above are defined behavior in C,
because they were in common use for at least 10 years before the
first C standard. It would be unthinkable for WG14 to have turned
it into undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2022-02-05 11:58 +0100 |
| Message-ID | <stll8j$ao6$2@dont-email.me> |
| In reply to | #82907 |
On 5 Feb 2022 08:37, Tim Rentsch wrote:
> "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
>
>> On 4 Feb 2022 17:15, Ben Bacarisse wrote:
>
> [...]
>
>>> template<typename StringType>
>>> requires is_same_v<StringType,
>>> basic_string<typename StringType::value_type,
>>> typename StringType::traits_type,
>>> typename StringType::allocator_type>>
>>> StringType formatClockCycles(uint64_t clockCycles)
>>> {
>>> char result[28], *ep = (&result)[1];
>>> do {
>>> sprintf(ep - 4, "%03lu", clockCycles % 1000);
>>> if (ep != (&result)[1]) ep[-1] = '.';
>>> ep -= 4;
>>> } while (clockCycles /= 1000);
>>> while (*ep == '0' && ep[1]) ep++;
>>> return ep;
>>> }
>>>
>>> (the appropriate comment on the 28 is left as an exercise to the reader!)
>>
>> Nice, but I believe it's formal UB to move a pointer to `char` from
>> beyond an array into the array, and dereference it.
>>
>> The C committee wrote a rationale for their earlier decision to make
>> it so, instead of admitting that it was bludner. Uh, blunder. I
>> don't recall who provided that information, but someone in this
>> group.
>
> I suspect that you either are misremembering or have misunderstood.
> Usage patterns like that seen above are defined behavior in C,
> because they were in common use for at least 10 years before the
> first C standard. It would be unthinkable for WG14 to have turned
> it into undefined behavior.
The "unthinkable" is why I maintain that it was originally a blunder,
not intentional.
They were just not able to admit it.
- Alf
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-02-06 02:16 -0800 |
| Message-ID | <86sfswjo58.fsf@linuxsc.com> |
| In reply to | #82910 |
"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
> On 5 Feb 2022 08:37, Tim Rentsch wrote:
>
>> "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
>>
>>> On 4 Feb 2022 17:15, Ben Bacarisse wrote:
>>
>> [...]
>>
>>>> template<typename StringType>
>>>> requires is_same_v<StringType,
>>>> basic_string<typename StringType::value_type,
>>>> typename StringType::traits_type,
>>>> typename StringType::allocator_type>>
>>>> StringType formatClockCycles(uint64_t clockCycles)
>>>> {
>>>> char result[28], *ep = (&result)[1];
>>>> do {
>>>> sprintf(ep - 4, "%03lu", clockCycles % 1000);
>>>> if (ep != (&result)[1]) ep[-1] = '.';
>>>> ep -= 4;
>>>> } while (clockCycles /= 1000);
>>>> while (*ep == '0' && ep[1]) ep++;
>>>> return ep;
>>>> }
>>>>
>>>> (the appropriate comment on the 28 is left as an exercise to the reader!)
>>>
>>> Nice, but I believe it's formal UB to move a pointer to `char` from
>>> beyond an array into the array, and dereference it.
>>>
>>> The C committee wrote a rationale for their earlier decision to make
>>> it so, instead of admitting that it was bludner. Uh, blunder. I
>>> don't recall who provided that information, but someone in this
>>> group.
>>
>> I suspect that you either are misremembering or have misunderstood.
>> Usage patterns like that seen above are defined behavior in C,
>> because they were in common use for at least 10 years before the
>> first C standard. It would be unthinkable for WG14 to have turned
>> it into undefined behavior.
>
> The "unthinkable" is why I maintain that it was originally a blunder,
> not intentional.
After reading some of your other comments elsethread, I now see
the difficulty: your earlier comments didn't clearly explain
what the issue is that you wanted to point out.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2022-02-05 12:35 -0800 |
| Message-ID | <ecce9e1b-baba-45cf-91c8-3a3c32ce75d4n@googlegroups.com> |
| In reply to | #82907 |
On Saturday, February 5, 2022 at 2:38:49 AM UTC-5, Tim Rentsch wrote: > "Alf P. Steinbach" <alf.p.s...@gmail.com> writes: ... > > Nice, but I believe it's formal UB to move a pointer to `char` from > > beyond an array into the array, and dereference it. > > > > The C committee wrote a rationale for their earlier decision to make > > it so, instead of admitting that it was bludner. Uh, blunder. I > > don't recall who provided that information, but someone in this > > group. > I suspect that you either are misremembering or have misunderstood. > Usage patterns like that seen above are defined behavior in C, > because they were in common use for at least 10 years before the > first C standard. It would be unthinkable for WG14 to have turned > it into undefined behavior. Though it's not clear from the above message, later messages have made it clear that the concept he was talking about is the one explained in the following sentence: "An array subscript is out of range, even if an object is apparently accessible with the given subscript (as in the lvalue expression a[1][7] given the declaration int a[4][5] ) (6.5.6)." Therefore, not only is it thinkable, it has in fact been thought. Since that sentence comes from section J.2 of the C standard, it has been endorsed by the committee as the correct interpretation of 6.5.6. No such wording was present in C90, but when the committee confirmed that this is the correct interpretation for C90, they decided to clarify that fact by adding a comment to section J.2 of the C99 standard. There was no corresponding change to the normative wording of the standard, because the committee felt that no change was needed.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-02-06 05:54 -0800 |
| Message-ID | <86k0e8je27.fsf@linuxsc.com> |
| In reply to | #82922 |
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes: > On Saturday, February 5, 2022 at 2:38:49 AM UTC-5, Tim Rentsch wrote: > >> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes: > > ... > >>> Nice, but I believe it's formal UB to move a pointer to `char` from >>> beyond an array into the array, and dereference it. >>> >>> The C committee wrote a rationale for their earlier decision to make >>> it so, instead of admitting that it was bludner. Uh, blunder. I >>> don't recall who provided that information, but someone in this >>> group. >> >> I suspect that you either are misremembering or have misunderstood. >> Usage patterns like that seen above are defined behavior in C, >> because they were in common use for at least 10 years before the >> first C standard. It would be unthinkable for WG14 to have turned >> it into undefined behavior. > > Though it's not clear from the above message, later messages > have made it clear that the concept he was talking about is the > one explained in the following sentence: [...] Yes, I already saw that. > Therefore, not only is it thinkable, it has in fact been > thought. [...] My statements are correct. It seems you have made some bad assumptions about the referents of what I was saying.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-02-06 19:43 +0100 |
| Message-ID | <stp4rk$e78$1@gioia.aioe.org> |
| In reply to | #82922 |
On 2/5/2022 9:35 PM, james...@alumni.caltech.edu wrote: > On Saturday, February 5, 2022 at 2:38:49 AM UTC-5, Tim Rentsch wrote: >> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes: > ... >>> Nice, but I believe it's formal UB to move a pointer to `char` from >>> beyond an array into the array, and dereference it. >>> >>> The C committee wrote a rationale for their earlier decision to make >>> it so, instead of admitting that it was bludner. Uh, blunder. I >>> don't recall who provided that information, but someone in this >>> group. >> I suspect that you either are misremembering or have misunderstood. >> Usage patterns like that seen above are defined behavior in C, >> because they were in common use for at least 10 years before the >> first C standard. It would be unthinkable for WG14 to have turned >> it into undefined behavior. > > Though it's not clear from the above message, later messages have made > it clear that the concept he was talking about is the one explained in the > following sentence: > > "An array subscript is out of range, even if an object is apparently accessible with the given > subscript (as in the lvalue expression a[1][7] given the declaration int a[4][5] ) (6.5.6)." But the issue in this thread is different: the subscript '7' in a[1][7] is in fact out of range, but it references the /third/ element past-the-end of a row in the array declared as "int a[4][5]" Alf's remark was about Ben's declaration: > char result[28], *ep = (&result)[1]; Here 'ep' points to the /first/ element past-the-end of the 1-sized array that includes "result" (a char[28]) Now, pointers to the /first/ past-the-end element of an array are well defined in C. > > Therefore, not only is it thinkable, it has in fact been thought. Since that > sentence comes from section J.2 of the C standard, it has been > endorsed by the committee as the correct interpretation of 6.5.6. > > No such wording was present in C90, but when the committee confirmed > that this is the correct interpretation for C90, they decided to clarify that > fact by adding a comment to section J.2 of the C99 standard. There was no > corresponding change to the normative wording of the standard, because > the committee felt that no change was needed.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-02-04 23:53 -0800 |
| Message-ID | <865yptlpgf.fsf@linuxsc.com> |
| In reply to | #82899 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Am 04.02.2022 um 15:25 schrieb Muttley@dastardlyhq.com:
>>
>>> On Fri, 4 Feb 2022 13:54:27 +0100
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>
>>>> I've just written a small routine:
>>>>
>>>> [.. some c++ code ..]
>>>
>>> Thats nice. Personally I'd just use printf().
>>
>> You can't do what I did with (s)printf().
>
> template<typename StringType>
> requires is_same_v<StringType,
> basic_string<typename StringType::value_type,
> typename StringType::traits_type,
> typename StringType::allocator_type>>
> StringType formatClockCycles(uint64_t clockCycles)
> {
> char result[28], *ep = (&result)[1];
> do {
> sprintf(ep - 4, "%03lu", clockCycles % 1000);
> if (ep != (&result)[1]) ep[-1] = '.';
> ep -= 4;
> } while (clockCycles /= 1000);
> while (*ep == '0' && ep[1]) ep++;
> return ep;
> }
>
> (the appropriate comment on the 28 is left as an exercise to the reader!)
Most of the work can be done using only a single call to sprintf().
(Disclaimer: not compiled.)
template< typename StringType >
requires
is_same_v<
StringType,
basic_string<
typename StringType::value_type,
typename StringType::traits_type,
typename StringType::allocator_type
>
>
StringType
formatClockCycles( uint64_t clockCycles ){
char result[ 27 ];
int n = sprintf( result, "%" PRIu64, clockCycles );
char *ep = (&result)[1];
*--ep = 0;
while( n > 3 ){
memmove( ep -= 3, &result[ n -= 3 ], 3 );
*--ep = '.';
}
do *--ep = result[ --n ]; while( n > 0 );
return ep;
}
[toc] | [prev] | [next] | [standalone]
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2022-02-05 10:10 -0800 |
| Message-ID | <stmeik$a9k$1@redfloyd.dont-email.me> |
| In reply to | #82908 |
On 2/4/2022 11:53 PM, Tim Rentsch wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>> Am 04.02.2022 um 15:25 schrieb Muttley@dastardlyhq.com:
>>>
>>>> On Fri, 4 Feb 2022 13:54:27 +0100
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>
>>>>> I've just written a small routine:
>>>>>
>>>>> [.. some c++ code ..]
>>>>
>>>> Thats nice. Personally I'd just use printf().
>>>
>>> You can't do what I did with (s)printf().
>>
>> template<typename StringType>
>> requires is_same_v<StringType,
>> basic_string<typename StringType::value_type,
>> typename StringType::traits_type,
>> typename StringType::allocator_type>>
>> StringType formatClockCycles(uint64_t clockCycles)
>> {
>> char result[28], *ep = (&result)[1];
>> do {
>> sprintf(ep - 4, "%03lu", clockCycles % 1000);
>> if (ep != (&result)[1]) ep[-1] = '.';
>> ep -= 4;
>> } while (clockCycles /= 1000);
>> while (*ep == '0' && ep[1]) ep++;
>> return ep;
>> }
>>
>> (the appropriate comment on the 28 is left as an exercise to the reader!)
>
> Most of the work can be done using only a single call to sprintf().
> (Disclaimer: not compiled.)
>
>
> template< typename StringType >
> requires
> is_same_v<
> StringType,
> basic_string<
> typename StringType::value_type,
> typename StringType::traits_type,
> typename StringType::allocator_type
> >
> >
> StringType
> formatClockCycles( uint64_t clockCycles ){
> char result[ 27 ];
> int n = sprintf( result, "%" PRIu64, clockCycles );
> char *ep = (&result)[1];
>
> *--ep = 0;
> while( n > 3 ){
> memmove( ep -= 3, &result[ n -= 3 ], 3 );
> *--ep = '.';
> }
> do *--ep = result[ --n ]; while( n > 0 );
>
> return ep;
> }
Why the oddly unreadable initialization of ep? Why not just
char *ep = result + sizeof(result)?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-02-05 19:51 +0100 |
| Message-ID | <stmgvd$r0s$1@dont-email.me> |
| In reply to | #82920 |
> On 2/4/2022 11:53 PM, Tim Rentsch wrote: >> char *ep = (&result)[1]; > Am 05.02.2022 um 19:10 schrieb red floyd: > Why the oddly unreadable initialization of ep? Why not just > > char *ep = result + sizeof(result)? > I also consider (&result)[1] as the more elegant way.
[toc] | [prev] | [next] | [standalone]
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2022-02-05 16:42 -0800 |
| Message-ID | <stn5hs$23i$1@redfloyd.dont-email.me> |
| In reply to | #82921 |
On 2/5/2022 10:51 AM, Bonita Montero wrote: >> On 2/4/2022 11:53 PM, Tim Rentsch wrote: >>> char *ep = (&result)[1]; > > > Am 05.02.2022 um 19:10 schrieb red floyd: >> Why the oddly unreadable initialization of ep? Why not just >> >> char *ep = result + sizeof(result)? >> > > I also consider (&result)[1] as the more elegant way. To be honest, I don't give a damn about your opinion. Mine makes it explicitly clear what is going on, without the whole weird casting shit.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-02-06 01:39 +0000 |
| Message-ID | <87sfswrcx1.fsf@bsb.me.uk> |
| In reply to | #82923 |
red floyd <no.spam.here@its.invalid> writes: > On 2/5/2022 10:51 AM, Bonita Montero wrote: >>> On 2/4/2022 11:53 PM, Tim Rentsch wrote: >>>> char *ep = (&result)[1]; >> > Am 05.02.2022 um 19:10 schrieb red floyd: >>> Why the oddly unreadable initialization of ep? Why not just >>> >>> char *ep = result + sizeof(result)? >>> >> I also consider (&result)[1] as the more elegant way. > > To be honest, I don't give a damn about your opinion. > > Mine makes it explicitly clear what is going on, without > the whole weird casting shit. There's no cast. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2022-02-05 18:02 -0800 |
| Message-ID | <stna8g$o2l$1@redfloyd.dont-email.me> |
| In reply to | #82924 |
On 2/5/2022 5:39 PM, Ben Bacarisse wrote: > red floyd <no.spam.here@its.invalid> writes: > >> On 2/5/2022 10:51 AM, Bonita Montero wrote: >>>> On 2/4/2022 11:53 PM, Tim Rentsch wrote: >>>>> char *ep = (&result)[1]; >>> > Am 05.02.2022 um 19:10 schrieb red floyd: >>>> Why the oddly unreadable initialization of ep? Why not just >>>> >>>> char *ep = result + sizeof(result)? >>>> >>> I also consider (&result)[1] as the more elegant way. >> >> To be honest, I don't give a damn about your opinion. >> >> Mine makes it explicitly clear what is going on, without >> the whole weird casting shit. > > There's no cast. > Good point. I still think it's more clear though.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-02-06 09:57 +0100 |
| Message-ID | <sto2hk$4ha$1@dont-email.me> |
| In reply to | #82923 |
Am 06.02.2022 um 01:42 schrieb red floyd: > On 2/5/2022 10:51 AM, Bonita Montero wrote: >>> On 2/4/2022 11:53 PM, Tim Rentsch wrote: >>>> char *ep = (&result)[1]; >> >> > Am 05.02.2022 um 19:10 schrieb red floyd: >>> Why the oddly unreadable initialization of ep? Why not just >>> >>> char *ep = result + sizeof(result)? >>> >> >> I also consider (&result)[1] as the more elegant way. > > To be honest, I don't give a damn about your opinion. Your solution works only with char-arrays. Tims solution works with all arrays. Therefore it's preferrable. > Mine makes it explicitly clear what is going on, without > the whole weird casting shit.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2022-02-06 10:57 +0100 |
| Message-ID | <sto62g$b91$1@dont-email.me> |
| In reply to | #82928 |
On 6 Feb 2022 09:57, Bonita Montero wrote: > Am 06.02.2022 um 01:42 schrieb red floyd: >> On 2/5/2022 10:51 AM, Bonita Montero wrote: >>>> On 2/4/2022 11:53 PM, Tim Rentsch wrote: >>>>> char *ep = (&result)[1]; >>> >>> > Am 05.02.2022 um 19:10 schrieb red floyd: >>>> Why the oddly unreadable initialization of ep? Why not just >>>> >>>> char *ep = result + sizeof(result)? >>>> >>> >>> I also consider (&result)[1] as the more elegant way. >> >> To be honest, I don't give a damn about your opinion. > > Your solution works only with char-arrays. > Tims solution works with all arrays. > Therefore it's preferrable. Red Floyd used `sizeof` because it was a `char`-array. That avoided an otherwise needless include directive or DIY function definition. The standard library offers `std::ssize` (plus the unsigned `std::size` in C++17 and earlier) for the general case. That's portable and clear code. The code using `(&result)[1]` involves a couple of extra conversions and indirections and is thus needlessly complex, plus it's formally UB, though I guess to most of us that formal UB doesn't matter except as an example of the improvement potential of the standardization process. [snip] - Alf
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-02-06 12:40 +0100 |
| Message-ID | <stoc37$f4$1@dont-email.me> |
| In reply to | #82929 |
Am 06.02.2022 um 10:57 schrieb Alf P. Steinbach: > On 6 Feb 2022 09:57, Bonita Montero wrote: >> Am 06.02.2022 um 01:42 schrieb red floyd: >>> On 2/5/2022 10:51 AM, Bonita Montero wrote: >>>>> On 2/4/2022 11:53 PM, Tim Rentsch wrote: >>>>>> char *ep = (&result)[1]; >>>> >>>> > Am 05.02.2022 um 19:10 schrieb red floyd: >>>>> Why the oddly unreadable initialization of ep? Why not just >>>>> >>>>> char *ep = result + sizeof(result)? >>>>> >>>> >>>> I also consider (&result)[1] as the more elegant way. >>> >>> To be honest, I don't give a damn about your opinion. >> >> Your solution works only with char-arrays. >> Tims solution works with all arrays. >> Therefore it's preferrable. > > Red Floyd used `sizeof` because it was a `char`-array. That avoided an > otherwise needless include directive or DIY function definition. The > standard library offers `std::ssize` (plus the unsigned `std::size` in > C++17 and earlier) for the general case. Red Floyd's solution is just uncommon for most developers, but if you know what it does it is not such a kind of syntax -bloat like array + size( array ).
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web