5 ms·

> Even if you don’t need to handle several types, this can be useful to avoid repetition and make the code more compact and readable. ... > namespace1::namesp

by vitus 5y ago

> Even if you don’t need to handle several types, this can be useful to avoid repetition and make the code more compact and readable. ... > namespace1::namespace2::namespace3::ACertainTypeOfWidget Deeply nested namespaces are problematic in themselves due to namespace resolution (e.g. see https://abseil.io/tips/130 https://abseil.io/tips/130), but templates should never be an answer to "my type is too long to type out". You're hurting yourself at compile-time, and your code is now more error-prone as you can pass in any argument. Just add a using-decl (or a namespace alias if the base name isn't meaningful enough for you).

cjfd 5y ago
Yes, deeply nested namespaces are not nice. I think boost really dropped the ball on this. boost::asio::ip::tcp should have been boost::tcp. Are they trying to be as bad as java?
- tialaramex 5y ago
  As the article explains it's not "as bad as Java" it's worse, what Java does actually makes sense in Java, maybe you have to type slightly more characters but Java is already a verbose language best suited to heavy tool-assist. However it doesn't make sense in C++ because the benefits Java gets don't apply and the price is heavier. There are a bunch of things like this in C++ where superficially C++ feature X is like feature Y in another language, and so C++ programmers wrongly assume the problems with feature X must also plague feature Y. I'm sure the reverse happens too.
  - jlarocco 5y ago
    > There are a bunch of things like this in C++ where superficially C++ feature X is like feature Y in another language, and so C++ programmers wrongly assume the problems with feature X must also plague feature Y. I'm sure the reverse happens too. Yes! I've noticed this also. Several recent C++ changes are copying idioms from other languages, and sometimes the standards committee seems to have missed the point or misunderstood how the features are used in the language they're copying. The results are superficially similar, but not quite what I'd expect after knowing the feature from the source language.
  - kllrnohj 5y ago
    Your argument seems to be "Java can be bad at this because it assumes an IDE, but C++ can't because it can't assume an IDE". Which is nonsense. If anything nested namespaces make sense in C++ but don't in Java, since Java has no nesting semantics and doesn't have using aliases. In Java it's just raw noise, whereas in C++ it's actual structure. Java isn't getting "benefits" from deep package paths. Absl's arguments are that you shouldn't use that structure much, so you should avoid deep nesting (specifically deep nesting, not no nesting). But it actually does something in C++, which isn't true in Java. And that's really the core of Absl's complaints about nesting - don't copy your Java package name (which is irrelevant useless noise) to your C++ code (where it's actual structure, and collisions can result in issues)
    - tialaramex 5y ago
      I thought Titus's tip spells it out pretty well. In Java we know Doodad is some.long.package.hierarchy.Doodad and not some.Doodad or some.other.Doodad or an.entirely.different.Doodad because we explicitly wrote that down. The tooling helps you with spelling but the language provides exactly what is needed here. If you introduce ambiguity, the code won't compile. In C++ too bad, you wrote Doodad and thought you were getting ::some::new::package::hierarchy::Doodad however that doesn't actually exist, you were thinking of ::some::long::package::hierarchy::Doodad and your compiler didn't complain because it silently concludes you wanted ::some::Doodad which does exist (maybe it was added years ago and is rarely used, or maybe it was added in the new version you got last week) even though you never actually wanted anything from ::some itself. C++ loves ambiguity, because now it's your fault this happened, you were less than perfect and as such unworthy of the power and grace of C++
MauranKilom 5y ago
> templates should never be an answer to "my type is too long to type out" Eh, in some cases it's a wash. std::vector<std::unique_ptr<mynamespace::MyWidget>> objects; // ... auto it = std::find_if(objects.begin(), objects.end(), [](auto& widget) { return widget->x == 1; }); Sure, you could repeat the type `std::unique_ptr<mynamespace::MyWidget>` in the lambda, but that's just noise. You don't spell out the types like that either in, say, C#. Yes, compilation time is an epsilon slower, but that consideration loses to readability any time of day. (Otherwise you could just remove all comments and indentation from your code - that also makes compilation faster!)
- jcelerier 5y ago
  Is it really slower ? The compiler has to compute the type of the right hand side in any case. It just has one less computation to do now (type checking the conversion to the left hand type)
- adamrezich 5y ago
  I am fairly certain template expansion and skipping over whitespace while parsing are two entirely orthogonal things. using a template might make compilation an "epsilon" slower in one instance of such a use, but then those epsilons add up...
- vitus 5y ago
  When the definition is far from the use of auto, that's exactly the case where I think repeating the type is meaningful. Yes, it's noise to write: std::unique_ptr<MyWidget> widget = std::make_unique<MyWidget>(); But I don't think it's so noisy in the case you've provided. If I encountered that code, I'd wonder whether that operator-> is safe, or if you're inadvertently dropping some qualifier (e.g. is it actually a raw pointer?). And as I suggested, it's not much harder to add a using decl: using UniqueWidget = std::unique_ptr<mynamespace::MyWidget>; // ... std::vector<UniqueWidget> objects; // ... auto it = std::find_if(objects.begin(), objects.end(), [](UniqueWidget&) { return widget->x == 1; }); (I also recognize that my opinion is very heavily flavored by the Google style guide: https://google.github.io/styleguide/cppguide.html#Type_deduction https://google.github.io/styleguide/cppguide.html#Type_deduc...)

by vitus 5y ago

cjfd 5y ago

Yes, deeply nested namespaces are not nice. I think boost really dropped the ball on this. boost::asio::ip::tcp should have been boost::tcp. Are they trying to be as bad as java?

tialaramex 5y ago
As the article explains it's not "as bad as Java" it's worse, what Java does actually makes sense in Java, maybe you have to type slightly more characters but Java is already a verbose language best suited to heavy tool-assist. However it doesn't make sense in C++ because the benefits Java gets don't apply and the price is heavier. There are a bunch of things like this in C++ where superficially C++ feature X is like feature Y in another language, and so C++ programmers wrongly assume the problems with feature X must also plague feature Y. I'm sure the reverse happens too.
- jlarocco 5y ago
  > There are a bunch of things like this in C++ where superficially C++ feature X is like feature Y in another language, and so C++ programmers wrongly assume the problems with feature X must also plague feature Y. I'm sure the reverse happens too. Yes! I've noticed this also. Several recent C++ changes are copying idioms from other languages, and sometimes the standards committee seems to have missed the point or misunderstood how the features are used in the language they're copying. The results are superficially similar, but not quite what I'd expect after knowing the feature from the source language.
- kllrnohj 5y ago
  Your argument seems to be "Java can be bad at this because it assumes an IDE, but C++ can't because it can't assume an IDE". Which is nonsense. If anything nested namespaces make sense in C++ but don't in Java, since Java has no nesting semantics and doesn't have using aliases. In Java it's just raw noise, whereas in C++ it's actual structure. Java isn't getting "benefits" from deep package paths. Absl's arguments are that you shouldn't use that structure much, so you should avoid deep nesting (specifically deep nesting, not no nesting). But it actually does something in C++, which isn't true in Java. And that's really the core of Absl's complaints about nesting - don't copy your Java package name (which is irrelevant useless noise) to your C++ code (where it's actual structure, and collisions can result in issues)
  - tialaramex 5y ago
    I thought Titus's tip spells it out pretty well. In Java we know Doodad is some.long.package.hierarchy.Doodad and not some.Doodad or some.other.Doodad or an.entirely.different.Doodad because we explicitly wrote that down. The tooling helps you with spelling but the language provides exactly what is needed here. If you introduce ambiguity, the code won't compile. In C++ too bad, you wrote Doodad and thought you were getting ::some::new::package::hierarchy::Doodad however that doesn't actually exist, you were thinking of ::some::long::package::hierarchy::Doodad and your compiler didn't complain because it silently concludes you wanted ::some::Doodad which does exist (maybe it was added years ago and is rarely used, or maybe it was added in the new version you got last week) even though you never actually wanted anything from ::some itself. C++ loves ambiguity, because now it's your fault this happened, you were less than perfect and as such unworthy of the power and grace of C++

MauranKilom 5y ago

> templates should never be an answer to "my type is too long to type out" Eh, in some cases it's a wash. std::vector<std::unique_ptr<mynamespace::MyWidget>> objects; // ... auto it = std::find_if(objects.begin(), objects.end(), [](auto& widget) { return widget->x == 1; }); Sure, you could repeat the type `std::unique_ptr<mynamespace::MyWidget>` in the lambda, but that's just noise. You don't spell out the types like that either in, say, C#. Yes, compilation time is an epsilon slower, but that consideration loses to readability any time of day. (Otherwise you could just remove all comments and indentation from your code - that also makes compilation faster!)

jcelerier 5y ago
Is it really slower ? The compiler has to compute the type of the right hand side in any case. It just has one less computation to do now (type checking the conversion to the left hand type)
adamrezich 5y ago
I am fairly certain template expansion and skipping over whitespace while parsing are two entirely orthogonal things. using a template might make compilation an "epsilon" slower in one instance of such a use, but then those epsilons add up...
vitus 5y ago
When the definition is far from the use of auto, that's exactly the case where I think repeating the type is meaningful. Yes, it's noise to write: std::unique_ptr<MyWidget> widget = std::make_unique<MyWidget>(); But I don't think it's so noisy in the case you've provided. If I encountered that code, I'd wonder whether that operator-> is safe, or if you're inadvertently dropping some qualifier (e.g. is it actually a raw pointer?). And as I suggested, it's not much harder to add a using decl: using UniqueWidget = std::unique_ptr<mynamespace::MyWidget>; // ... std::vector<UniqueWidget> objects; // ... auto it = std::find_if(objects.begin(), objects.end(), [](UniqueWidget&) { return widget->x == 1; }); (I also recognize that my opinion is very heavily flavored by the Google style guide: https://google.github.io/styleguide/cppguide.html#Type_deduction https://google.github.io/styleguide/cppguide.html#Type_deduc...)