- Structured binding considered harmful - 6 Updates
- overuse of auto is dangerous - 3 Updates
- Available C++ Libraries FAQ - 1 Update
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 15 11:08AM On Sat, 2020-03-14, Öö Tiib wrote: > On Saturday, 14 March 2020 10:05:58 UTC+2, jacobnavia wrote: ... > software companies with task to deteriorate the language to non- > useful. I disliked the language changes in C++17 as well. But I may > be wrong. My coworker, who (unlike me) hangs around on HackerNews, understand it as a kind of pressure. Within a company, people lobby for doing the next project in $pet_language, because it has $feature which would be useful. So they grow C++ so it can stay competitive. Sounds more likely than a conspiracy. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: Mar 15 09:46AM -0700 On Sunday, 15 March 2020 13:08:34 UTC+2, Jorgen Grahn wrote: > next project in $pet_language, because it has $feature which would be > useful. So they grow C++ so it can stay competitive. > Sounds more likely than a conspiracy. Big part of the language features that C++11 added were vital performance improvements, others were syntax sugar (often added bordering on broken) and only very few were security and or safety features. I remember discussions how safety features like override and final were planned to be added uglified to maximum. I can live without using syntax sugar features so did not care that standards make those broken but safety and performance features I care about. However C++17 took to break performance feature constexpr (by making it undetectable) and safety feature enum class (by adding more undefined behaviors into it). Then I built impression that it is sabotage. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 15 05:50PM +0100 > What happens when the class is modified to have a new field? That's not different than with a single type you're iterating through changes. So where's the problem ? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 15 07:27PM +0100 On 15.03.2020 17:46, Öö Tiib wrote: > (by making it undetectable) and safety feature enum class (by adding > more undefined behaviors into it). Then I built impression that > it is sabotage. Which undefined behaviors for enums? What I recall is the opposite, that the introduction of `std::bool` forced a cleanup where now all enumerator values that fit within the underlying type are kosher also formally. If they have undermined the language in yet another direction it's, well, disconcerting. - Alf |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Mar 15 03:15PM -0700 > What I recall is the opposite, that the introduction of `std::bool` > forced a cleanup where now all enumerator values that fit within the > underlying type are kosher also formally. What is "std::bool"? (Since bool is a keyword, the grammar would have to be updated just to allow that.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| jacobnavia <jacob@jacob.remcomp.fr>: Mar 16 12:11AM +0100 Le 15/03/2020 à 17:50, Bonita Montero a écrit : >> What happens when the class is modified to have a new field? > That's not different than with a single type you're > iterating through changes. So where's the problem ? In this code for (auto const& e : mapCityPopulation) { char const* city = e.first.c_str(); int population = e.second; std::cout << city << ": " << population << '\n'; } Forget for a moment that map has two fields and assume a general class. When this assignment is written as such, only the fields needed are accessed. No assumptions are done about the other fields of the class. Using structured binding you have to specify the number of fields of the class and many other IRRELEVANT things that make more dependencies that make the code more prone to failure. Instead of accessing just what you need, you end up accessing ALL the class since you create an anonymous object to which "bindings" are done. All that unnecessary machinery just to give you MORE SYNTACTIC SUGAR. C++ has enough of that. Do you really need to add more? For an end result that is more complex to write and maintain? What has been gained with all that machinery? You have to write your "get" templates that receive the index of the field, the specification template for the number of fields in the claass, all that stuff! Using the more verbose but simpler code if any irrelevant field is addded to the class you do not access it and your code is inmune to those changes! You see the problem now? |
| David Brown <david.brown@hesbynett.no>: Mar 15 12:27PM +0100 On 14/03/2020 18:23, Bart wrote: >> shorter, and saves providing a name for the multi-value return type. > Does C++ still need declarations of such functions when the definition > itself is not visible? If so, what would they look like? There is no way to declare such functions. (Unless it can be done with modules - I am not familiar enough with them yet.) So you'd need to declare the return type, with a name, then use that to declare the function - just as you would with C. C++ makes it easier to have such declarations in header files, however, and ensures that if the function is generated separately rather than being expanded inline, you only have one copy in the final linked program. (Yes, having the definitions of functions in headers makes compilation slower, and yes, speed of compilation of C++ files /is/ a big issue, unlike for C. On the other hand, you can often distribute C libraries as just header files rather than header + implementation pairs. And modules will improve build times significantly.) > What I'm getting at is that such a return type will need to be known at > the call-site, at least the number and types of the multiple values. Yes, exactly. > Also I can't see that 'auto' helps that much here, since you will still > need to know the number of return values, if not their types. Functions with "auto" return type (and no trailing return type) have their real return types inferred by the compiler when it sees their definition. So you can't declare them in advance. But for a lot of functions, there is only one "return" statement and you let the compiler do the work for you. Use of inferred types is, if you like, a higher level feature. It is not always the right choice, and it is not always possible. You use inferred types when you are most interested in features of the type, rather than details of the implementation, or when you only want to assign it once. For example, if you write "auto x = foo();", then you know "x" is of a type that can hold any value that foo() might return. But if you then go on to write "x += 1;", you might not know if that is valid - perhaps the type of "x" is "int" and this overflows, and you really wanted to write "unsigned int x = foo();". "auto" really comes in handy when dealing with generic functions (templated functions or concept functions), or when you have complicated types that you don't want to have to write out manually. "auto" makes it easier to write some kinds of code error-free, and also makes it easier to make other kinds of errors. It is a helpful feature but not a magic feature. > (Your proposal also seems to allow multiple, nested return values, which > IMO is not useful and complicates matters. That would be better as a > single compound type.) My example above (foo and bar) is giving a single compound return. You can do that in C too, but you have to be more verbose and explicit. That can be a good thing and a bad thing - there are no absolutes here. (I can't stress that enough.) > void fn(int sum, int prod); > void fn(int prod, int sum) {....} > If only the declaration is visible at the call-site, it will be misleading. Yes. That is one thing I strongly dislike about the languages, and it is a big hinder to having a simple system of named parameters. However, it is also clear that there are some /good/ reasons for allowing different names for parameters. >> However, AFAIK C++ currently gives no way to use such anonymous struct >> return types in functions with separate definitions and declarations. > OK, you seem to have answered my point above... With luck, someone will answer it differently, and I'll learn something useful! > not imaginary) language has long had features such as multiple return > types, default parameter values and keyword arguments. And that sum/prod > mixup is not possible. Sometimes comparisons between languages are useful, yes. Endless "/my/ language is so much better" posts are not. There is a difference. > Example after sig. Put things before the signature if they are useful (even if they are not in the language of the group) - otherwise they get snipped. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 15 04:26PM +0100 > If you don't like a language, don't use it. You can use the language not only in one way. And auto can make the code less readable for those who've not written the code. I use it only if absolutely necessary. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Mar 15 03:41PM -0700 > On 14/03/2020 18:23, Bart wrote: [...] > is a big hinder to having a simple system of named parameters. > However, it is also clear that there are some /good/ reasons for > allowing different names for parameters. [...] Good reasons for using a different name for the same parameter in a declaration and definition of a function? I can't think of any. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Nikki Locke <nikki@trumphurst.com>: Mar 14 11:23PM Available C++ Libraries FAQ URL: http://www.trumphurst.com/cpplibs/ This is a searchable list of libraries and utilities (both free and commercial) available to C++ programmers. If you know of a library which is not in the list, why not fill in the form at http://www.trumphurst.com/cpplibs/cppsub.php Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website. |
| 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