| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 23 09:12PM -0700 Ben Bacarisse <ben.usenet@bsb.me.uk> writes: [...] > f().i is not a lvalue and has a const-qualified type. gcc prints "int", > but clang prints "const int". I think clang is right here. (So much > for "they all copy gcc"!) I have looked into this question and just now posted in comp.std.c giving the results of my investigation. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 23 09:15PM -0700 > no lvalue conversion. > I can see that it would make sense for the expression `f().i` to have > type int rather than const int, but the standard doesn't say so. There is some confusion about that. More info in comp.std.c. |
| David Brown <david.brown@hesbynett.no>: Oct 24 12:11PM +0200 On 23/10/2021 19:58, Bart wrote: > I don't do anything with these at the minute (I think 'out' and 'inout', > not shown, are just aliases for '&') but they can do a lot just as > annotations. People can write code in a lazy way (or perhaps an old way), and this can cause some inconveniences in using it along with code written in newer and better ways. That's true in general - it is not special for C, nor special for "const" in C. Your solution to C's const problem (as you see it), is to have a language where you can distinguish between pointers which cannot be used to change the data, and pointers which /can/ be used to change the data. As long as people use these correctly in your language, or Pascal, or Ada, everything works correctly. That's fine - and a good idea. It is /exactly/ the same as is done in C. "void f1(char *)" is like an "inout" parameter, and "void f2(const char *)" is like an "in" parameter. Using "char *" as a parameter in C when it is read-only data is exactly like using "inout" parameters in Ada or Pascal, or "ichar s" in your language - it is lazy, unhelpful, and it stops people using it for constant data (without extra effort). Therefore, I simply don't understand what you have against "const" in C - your own language is almost identical except for minor syntax differences. (You do have a syntax for saying the pointer is used only for writing, not for reading, which standard C is missing.) > images, which can all be modifible, or they can be altered via another > path to the original data. > But C's const doesn't prevent that either.) Yes, "const" has its limitations - the same ones as you have in your language. Programming languages /always/ have compromises. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 24 02:20PM On Thu, 2021-10-21, Juha Nieminen wrote: > Time and again I see beginner C++ programmers make the same mistake: > Make functions take objects by non-const reference, even when (in the > vast, vast majority of cases) the function doesn't modify those objects. I don't often see that mistake. If they do it, surely they must have learned from really lousy sources, and do other stupid things, too? It's important and easy for an author or a teacher to describe the common cases of parameter passing: void foo(Bar bar); void foo(const Bar& bar); And the more exotic ones: void foo(Bar& bar); void foo(Bar&& bar); void foo(Bar* bar); void foo(const Bar* bar); void foo(std::unique_ptr<Bar> bar); // and some I missed I guess /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Bart <bc@freeuk.com>: Oct 24 11:11PM +0100 On 24/10/2021 11:11, David Brown wrote: > constant data (without extra effort). > Therefore, I simply don't understand what you have against "const" in C > - your own language is almost identical except for minor syntax differences. I've played around with C-style readonly type attributes in the past. I didnt't like them. It disrupts the type system (see the fuss about how _Generic should work) and it didn't give the necessary protection. 'const' in C only affects one level of a complex type. It doesn't affects those parts not specified (like the members of a struct type, or rather those values at the other side of an embedded pointer type, which is not itself const). I want 'readonly' to protect an entire data structure, especially one that is otherwise mutable that is passed to a function, by only specifying one thing. Now, I haven't fully implemented such an attribute (I've only reserved syntax like 'let' and 'in'), I just know how I'd like it to work. That is, propagate down deep into the data structure. I think that is possible. I don't think it would be part of the type system; it's likely to be a property of an expression. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 24 04:18PM -0700 On Monday, 25 October 2021 at 01:11:57 UTC+3, Bart wrote: > specifying one thing. > Now, I haven't fully implemented such an attribute (I've only reserved > syntax like 'let' and 'in'), I just know how I'd like it to work. Can it be that you haven't implemented it because it is what you would like to want but do not always want? > That is, propagate down deep into the data structure. I think that is > possible. I don't think it would be part of the type system; it's likely > to be a property of an expression. In most software I have seen pointers in object often point at other objects that are not logically components of said object. So the pointers often do not go to "down deep" but entirely elsewhere. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment