- I think references should have been const by default - 15 Updates
- A few question about learning c++ - 1 Update
| Juha Nieminen <nospam@thanks.invalid>: Oct 22 04:41AM > I don't about C++, but in C, you can take a program, remove all the > 'const' qualifiers, and it will still compile and work. At least if you turn off warnings. Also, you'll likely make some programs less efficient because the compiler will do compile-time calculations on things like const arrays containing compile-time literals, which it won't if the array is not const. So yes, 'const' can actually make the program more efficient (especially in C++, where it guarantees to the compiler that it can assume the contents won't change). |
| Juha Nieminen <nospam@thanks.invalid>: Oct 22 04:45AM > Except throw inside a function means throw any exception currently on the stack. > You can't have it both ways and for once the C++ committee saw sense and > replaced it with noexcept. If 'throw(...)' after a function declaration specifies a list of exceptions that the function may throw, it's only logical that if this list is empty then it doesn't throw anything. You could just as well complain about the multiple different uses of {}. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 22 04:45AM > You're compulsive. And you are an asshole. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 22 04:48AM > void foo( Ref_<Baluba> x ) > instead of > void foo( const Baluba& x ) Doesn't really help with the problem of beginners using non-const references everywhere... |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 22 07:55AM +0200 >> You're compulsive. > And you are an asshole. That depends on the situation, but sometimes that's true. I just don't like compulsive personalities that arise problems that don't really exist. |
| David Brown <david.brown@hesbynett.no>: Oct 22 09:46AM +0200 On 21/10/2021 16:04, Bart wrote: > I don't about C++, but in C, you can take a program, remove all the > 'const' qualifiers, and it will still compile and work. > Makes you think... I makes you think that it is true that good programming language design is more about what you /can't/ do, rather than about what you /can/ do. "const" in C does not let you do things you could not otherwise do - it restricts you, thus making code clearer, safer, more maintainable, and perhaps sometimes more efficient. Const in C++ is more integral to the language, and can't be removed in the same way (not that anyone would want to). |
| David Brown <david.brown@hesbynett.no>: Oct 22 11:13AM +0200 On 21/10/2021 18:09, James Kuyper wrote: > "const" qualifiers from all of the #included header files, and you can't > do that with standard library headers. It would also be difficult to do > with the headers associated with third-party libraries. I'm not suggesting that this would be at all a good idea, and it would certainly be undefined and undocumented behaviour, but you could probably remove "const" by adding "-Dconst=" to your compiler flags. It works for gcc (maybe I should file a bug here - it is even accepted with -std=c99 -Wpedantic). |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 22 11:21AM > That depends on the situation, but sometimes that's true. > I just don't like compulsive personalities that arise problems > that don't really exist. PEACE&LOVE, brothers and sisters :P -- 7-77-777 Evil Sinner! with software, you repeat same experiment, expecting different results... |
| Bart <bc@freeuk.com>: Oct 22 03:48PM +0100 On 22/10/2021 08:46, David Brown wrote: > "const" in C does not let you do things you could not otherwise do - it > restricts you, thus making code clearer, safer, more maintainable, and > perhaps sometimes more efficient. There are better ways of doing it. In C, it is just adds a lot of clutter that effects readability and can hide real problems. Neither does the syntax make it that obvious which bit of the type is refered to, as in: const int * const * x; The first const applies to the following int; the second const refers to the /previous/ * (AIUI). This can give a false sense of security, especially when you have, say, a const pointer to a struct which contains non-const pointers. The 'const' only protects that top level; it does not stop you writing nested non-const data. In my example, x can still be written to! (x=0 is allowed; but *x=0 and **x=0 are not.) Use of 'const' can also proliferate through interactions with non-const versions of the type, adding to the clutter. (I don't do much with readonly stuff [in my languages]. My experiments focus on mutability of objects, or specific variables, not of types.) |
| Bart <bc@freeuk.com>: Oct 22 04:14PM +0100 >> } >> The output is different when x has a const attribute. > You're correct, I forgot about that. _Generic provides a capability similar to but much more restricted than function overloading, and as such allows the behavior to depend upon the qualifiers. That program only behaves as I said when I use my own compiler. With gcc and others that support _Generic, any 'const' attributes of the types of controlling expressions appear to be stripped away. I'm not sure why that is. It looked to be a bug in gcc, but other compilers do the same. Maybe they are all copying gcc's behaviour, but I don't what C itself says about it. With the version below, gcc et al display: int int With mine, it displays: int const int -------------------------------- #include <stdio.h> int main(void) { #define strtype(x) _Generic((x),\ int: "int",\ const int: "const int") int x; const int y; puts(strtype(x)); puts(strtype(y)); } |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Oct 22 12:04PM -0700 Bart <bc@freeuk.com> writes: [...] > I'm not sure why that is. It looked to be a bug in gcc, but other > compilers do the same. Maybe they are all copying gcc's behaviour, but > I don't what C itself says about it. [...] _Generic is a C feature that does not appear in C++. The first operand of _Generic is an expression, not an object, and it determines the type of that expression. If the expression happens to be an lvalue, it undergoes *lvalue conversion* (N1570 6.3.2.1p2), which strips any qualifiers. So if the operand of _Generic is the name of an object of type const int, the type of that *expression* is int, not const int. (Something like _Generic that operates on lvalues rather than expressions might have been useful, but I've never had a need for it.) Consider an expression like (n + 1). Would you expect it to have a different type depending on whether n was defined as const or not? C++ overloading, unlike C's _Generic, can use references to distinguish between const and non-const objects. You can't have two overloaded functions that differ only in their parameter type, int vs. const int, but you can have overloaded functions with parameters of type int& and const int&. -- 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 */ |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Oct 22 12:28PM -0700 On Thursday, October 21, 2021 at 2:54:45 AM UTC-4, David Brown wrote: > > { > > str = "hello"; // ok > > } It would have been better if std::string was immutable. > about how C++ could have been made better, I'd have preferred "const" > for all variables and required "mutable" to declare a variable that > could be modified. Note though that const does not mean immutable. Daniel |
| Bart <bc@freeuk.com>: Oct 22 08:47PM +0100 On 22/10/2021 20:04, Keith Thompson wrote: > it.) > Consider an expression like (n + 1). Would you expect it to have a > different type depending on whether n was defined as const or not? If I get my C compiler to display the type, then for 'const int n', n has type 'const int', and n+1 has type 'int'. But let me ask you, if p has type 'const int* p', do you expect 'p+1' to have a different type from 'p'? (Namely, 'int*' instead of 'const int*'.) I understand now that the const qualifiers are only removed at the top level, so only the leftmost 'const' if types were written left to right (my const int* p example would have it after 'pointer to'). This still makes the way _Generic works unintuitive. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Oct 22 01:29PM -0700 >> different type depending on whether n was defined as const or not? > If I get my C compiler to display the type, then for 'const int n', n > has type 'const int', and n+1 has type 'int'. If your C compiler displays the type using some non-standard extension, then of course that extension can do anything you like. > But let me ask you, if p has type 'const int* p', do you expect 'p+1' > to have a different type from 'p'? (Namely, 'int*' instead of 'const > int*'.) No, p+1 would have type const int* (pointer to const int). > level, so only the leftmost 'const' if types were written left to > right (my const int* p example would have it after 'pointer to'). > This still makes the way _Generic works unintuitive. I find it intuitive, but perhaps not immediately so. I had to remind myself about the lvalue conversion, and that its operand is an expression, not an object, for it to make sense. If you want to continue discussing this, I suggest starting a new thread in comp.lang.c. -- 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 */ |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 22 07:18PM -0400 On 10/22/21 5:13 AM, David Brown wrote: ... > probably remove "const" by adding "-Dconst=" to your compiler flags. It > works for gcc (maybe I should file a bug here - it is even accepted with > -std=c99 -Wpedantic). You are right - the behavior would be undefined: "The program shall not have any macros with names lexically identical to keywords currently defined prior to the inclusion of the header or when any macro defined in the header is expanded." (C standard, 7.1.2p5) As a "shall" occurring outside of a "Constraints" section, the behavior of a program that violates that rule is undefined (4p2). But it would probably work as intended on many implementations. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 22 04:50AM > - The three books I am currently reading are ???Effective c++?????????More Effective C++???and ???The Annotated STL Sources???,After reading for a while, I found that these three books are too old, some of the C++ features mentioned in them are out of date, should I continue reading or find some new books. If I should find new books, then do you have any recommendations for books? You should most definitely not stop reading them. They do not get old, and contain some of the best advice for C++ programming. The author has also written a new book for C++11, so you could get that in addition to those. |
| 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