- Structured binding considered harmful - 16 Updates
- std::array is packed, unpadded and can be casted? - 2 Updates
| Sam <sam@email-scan.com>: Mar 19 07:23PM -0400 Bonita Montero writes: > When you didn't write the code you usually have to check the > type of the container. When you haven't looked at the code for > a long time you might also. But if you know C++, and the code was well-written, even if it was well- written by someone else you rarely need to do that. But only as long as you actually know C++. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 20 09:18AM +0100 >> a long time you might also. > But if you know C++, and the code was well-written, even if it > was well-written by someone else you rarely need to do that. You know it only if you read the part where container was defined or declared. That's often superfluous if you don't use auto. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 20 05:31AM -0700 On Friday, March 20, 2020 at 4:19:00 AM UTC-4, Bonita Montero wrote: > > was well-written by someone else you rarely need to do that. > You know it only if you read the part where container was defined > or declared. That's often superfluous if you don't use auto. If know C++, you often don't need to know the exact type, and therefore don't need to read the part where the container was defined or declared. That's particularly true if, as specified, the code was well-written. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 20 01:40PM +0100 > If know C++, you often don't need to know the exact type, and > therefore don't need to read the part where the container was > defined or declared. ... Usually not. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 20 08:50AM -0700 On Friday, 20 March 2020 14:40:21 UTC+2, Bonita Montero wrote: > > defined or declared. That's particularly true if, as specified, > > the code was well-written. > Usually not. We have indeed seen that your code is usually not well written, but ... it is not fault of ours. Try harder? |
| Daniel <danielaparker@gmail.com>: Mar 20 09:30AM -0700 On Friday, March 20, 2020 at 11:51:12 AM UTC-4, Öö Tiib wrote: > > Usually not. > We have indeed seen that your code is usually not well written, > but ... it is not fault of ours. Nonetheless, Bonita's point, that while usually not necessary to know the exact type, sometime it is, is valid. Looking only at for (const auto &v:container) { without knowing more about the container, it is not possible to know by inspection whether type deduction rules via auto will do the right thing. Daniel |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 20 05:41PM +0100 >> Usually not. > We have indeed seen that your code is usually not well written, > but ... it is not fault of ours. Try harder? It doesn't depend on how good the code is written. You would have to have a crystal bulb to guess the type auto refers to in this case. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 20 10:13AM -0700 On Friday, 20 March 2020 18:31:12 UTC+2, Daniel wrote: > > but ... it is not fault of ours. > Nonetheless, Bonita's point, that while usually not necessary to know the > exact type, sometime it is, is valid. It was not the point, the point was that it is *usually* important to explicitly tell exact type of container and exact type of the element of it. While more common in bad code is that the container's and its element's types are very well known since both are stuttered explicitly both in types and in names of variables all over the place ad nausea. > without knowing more about the container, it is not possible to know > by inspection whether type deduction rules via auto will do the right > thing. And that is the other property of bad code, things named "iter", "ptr", "data", "buf", "container" and other such "foo" and "poo". Like I already wrote here you wont be in any better understanding from: for (std::pair<std::string, int> e : container) { std::cout << e.first << ": " << e.second << '\n'; } To what bonita replied that at least you know that it is std::pair<std::string, int>. So what? The code is still bad to read. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 20 05:30PM On Fri, 2020-03-20, Daniel wrote: ... > without knowing more about the container, it is not possible to know > by inspection whether type deduction rules via auto will do the right > thing. Do you have any examples of containers where that doesn't do the right thing? (Assuming the loop just wants to visit the elements in sequence, and not try to modify 'container' or anything.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Daniel <danielaparker@gmail.com>: Mar 20 10:36AM -0700 On Friday, March 20, 2020 at 1:13:35 PM UTC-4, Öö Tiib wrote: > And that is the other property of bad code, things named "iter", "ptr", > "data", "buf", "container" and other such "foo" and "poo". I would use "it", for a local iterator variable :-) Also i/j/k for indices. > for (std::pair<std::string, int> e : container) { > std::cout << e.first << ": " << e.second << '\n'; > } I disagree. From that, you _know_ that e is not a proxy type. Daniel |
| Daniel <danielaparker@gmail.com>: Mar 20 10:49AM -0700 On Friday, March 20, 2020 at 1:30:23 PM UTC-4, Jorgen Grahn wrote: > Do you have any examples of containers where that doesn't do the right > thing? (Assuming the loop just wants to visit the elements in > sequence, and not try to modify 'container' or anything.) A trivial example is #include <vector> #include <iostream> void f(bool) { std::cout << "bool!\n"; } template <class T> void f(T) { std::cout << "not bool!\n"; } int main() { std::vector<bool> v = { true,false }; for (const auto& item : v) { f(item); } } Output: not bool! not bool! More generally, with proxied containers, all bets are off, think expression templates or lazy initialization. Daniel |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 20 06:47PM On Fri, 2020-03-20, Daniel wrote: >> Do you have any examples of containers where that doesn't do the right >> thing? (Assuming the loop just wants to visit the elements in >> sequence, and not try to modify 'container' or anything.) ... > std::vector<bool> ... > More generally, with proxied containers, all bets are off, think expression > templates or lazy initialization. Ah, thanks. I don't think I've ever seen any of those in the wild. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Sam <sam@email-scan.com>: Mar 20 06:05PM -0400 Bonita Montero writes: >> therefore don't need to read the part where the container was >> defined or declared. ... > Usually not. In your case, definitely. But not in the case of those who have above- average C++ skills and experience. |
| Sam <sam@email-scan.com>: Mar 20 06:06PM -0400 Bonita Montero writes: >> but ... it is not fault of ours. Try harder? > It doesn't depend on how good the code is written. You would have to > have a crystal bulb to guess the type auto refers to in this case. No, the type it refers to is very obvious. |
| Daniel <danielaparker@gmail.com>: Mar 20 03:57PM -0700 On Friday, March 20, 2020 at 6:05:17 PM UTC-4, Sam wrote: > In your case, definitely. But not in the case of those who have above- > average C++ skills and experience. Bm7 | E7 | He's Trolling G F#m7 And he hopes you like trolling too |
| Ian Collins <ian-news@hotmail.com>: Mar 21 12:06PM +1300 On 21/03/2020 06:36, Daniel wrote: >> And that is the other property of bad code, things named "iter", "ptr", >> "data", "buf", "container" and other such "foo" and "poo". > I would use "it", for a local iterator variable :-) Also i/j/k for indices. One of the first things I encourage my peers to change (and certainly the first thing I change) when modernising a loop is the iterator variable name. Using the likes of "it" or "i" may have been natural before, where the variable was an iterator, but with a ranged for the variable as a type and should be maned as such. So we have the likes of for( const auto& line : lines ) rather than for( std::vector<std::string>::const_iterator it = lines.begin(); it != lines.end(); ++it ) -- Ian. |
| Sam <sam@email-scan.com>: Mar 19 07:26PM -0400 Frederick Gotham writes: > *reinterpret_cast<array<char,4> *>(&abc[8]) > ); > } Well, you can do that only in a sense that a C++ compiler might produce some code that does something. What it actually does, who knows. So the real answer is: no, you can't. This might actually produce the expected results – and is likely to do so with most C++ implementations, but you can't really do that. > I might go back to normal arrays if there's no nice way of doing this in > C++11. You probably should. Containers are not a solution to every problem. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Mar 20 03:44AM > ); > } > I might go back to normal arrays if there's no nice way of doing this in C++11. reinterpret cast is bad and ugly, don't use it if not necessary. Also you have to cast back before use ;) -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| 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