C++ Internals: STL Vector, Part 3(gahcep.com)
gahcep.com
C++ Internals: STL Vector, Part 3
http://www.gahcep.com/cpp-internals-stl-vector-part-3/
7 comments
The scrolling experience on this page is awful on my retina MacBook Pro.
I'm curious why anyone would reimplement scrolling in a webpage when the browser already does it. It's not even an interesting problem...
I guess the author/library is unable to detect users for which this would worsen things. For me, it does actually work as an improvement on my non-smooth-scroll mousewheel.
Not sure it reimplements scrolling; it just looks like there are CSS styles applied to browsers supporting ::webkit-scrollbar-* selectors and coloring/thinning the scrollbar.
The author (gahcep) and Stephan (STL, stl maintainer for microsoft) are on r/cpp.
https://www.reddit.com/r/cpp/comments/3gd29t/c_internals_stl...
https://www.reddit.com/r/cpp/comments/3gd29t/c_internals_stl...
It's amusing to see somebody going through work I did 8 years ago!
As someone that uses Microsoft's STL, I just wanted to let you know I appreciate your work. Stepping through the STL (whether on purpose or via accidental F11 instead of F10) has made me a better programmer. I mean it sincerely!
Yes, I went through because I wanted to know the details. It's nice, you were amused.
I know this is a nitpick, but "auto main() -> int" seems weird to me. "int main()" is not only more understandable, but also shorter.
Yep, that's a totally counterproductive use of trailing return types. There are several reasons to use trailing return types, but that's not one of them. (The major use is when you have to refer to function parameters with decltype. Additional uses are when the return type would have to be qualified on the left but can be shorter on the right, or when you're returning something like a function pointer or reference to array and you don't have a convenient typedef/alias.)
One could argue that trailing return types are more consistent and allow you to switch between return type deduction and explicit return types easier.
In addition, it's also more consistent with lambda syntax, lets you use decltype on parameter arguments, allows your function names to line up nicely in header files, and my favorite feature, is scoped for member functions. Ex:
I do kind of wish you could say "function" instead of "auto" here, but of course that wasn't a reserved keyword so it would have broken existing code.
For the ubiquitous main, "auto main() {}" return type deduction works pretty well. But I need a wrapper around main() anyway thanks to Windows corrupting argv[] when you pass in non-ANSI (Unicode) characters. So for my case, I have:
MessageWindow::Response MessageWindow::question(...);
MessageWindow::Icon MessageWindow::getIcon() { return _icon; }
...
auto MessageWindow::question(...) -> Response;
auto MessageWindow::getIcon() { return _icon; }
I do kind of wish you could say "function" instead of "auto" here, but of course that wasn't a reserved keyword so it would have broken existing code.
For the ubiquitous main, "auto main() {}" return type deduction works pretty well. But I need a wrapper around main() anyway thanks to Windows corrupting argv[] when you pass in non-ANSI (Unicode) characters. So for my case, I have:
#include <nall/main.hpp>
auto nall::main(vector<string> args) { ... }
> In addition, it's also more consistent with lambda syntax, lets you use decltype on parameter arguments, allows your function names to line up nicely in header files...
Great points for the repurposing of auto present in the latest standard... Not for use in defining main.
Your case regarding Windows and wrapping main I'm sure is valid. But is not the case with the article's definition.
Great points for the repurposing of auto present in the latest standard... Not for use in defining main.
Your case regarding Windows and wrapping main I'm sure is valid. But is not the case with the article's definition.
I didn't realize it was scoped this way, that's a nice bonus.
One could present that argument, yes, but would be questioned as to why the argument is needed for the canonical main function definition.
Usage of this syntax for main not only deviates from expected form, its presence in defining the one function every C++ developer knows by heart is self-defeating.
Usage of this syntax for main not only deviates from expected form, its presence in defining the one function every C++ developer knows by heart is self-defeating.
What a long winded way to say "that syntax is weird" while totally ignoring that my main point was consistency.
[deleted]
And just a few lines below that: "for (auto item : { 1, 2, 3, 4, 5, 6, 7, 8, 9 })". Why?? It's an almost comical abuse of C++11 for the sake of it.
> And just a few lines below that: "for (auto item : { 1, 2, 3, 4, 5, 6, 7, 8, 9 })". Why?? It's an almost comical abuse of C++11 for the sake of it.
This comment is very interesting. His syntax reminds me of Python syntax of:
This comment is very interesting. His syntax reminds me of Python syntax of:
for i in [1,2,3]:
> Isn't that what the future C++ is trying to achieve? Simplified syntax?
I think your question was rhetorical, in any case the answer is yes. In fact the proposed C++ pythy syntax tries go even further http://pfultz2.github.io/Pythy/ . IIRC its Clang only. Its author hangs out on HN sometimes and would be able to provide more information
I think your question was rhetorical, in any case the answer is yes. In fact the proposed C++ pythy syntax tries go even further http://pfultz2.github.io/Pythy/ . IIRC its Clang only. Its author hangs out on HN sometimes and would be able to provide more information
It's worse in every way to:
for (int i = 1; i != 10; ++i)Even in that example, wouldn't it be better to simply write
for i in range(1,4):Why? Because that's the most concise way in general to iterate over an arbitrary list of enumerated values. There's no "abuse" here, just a particular example that could have been written more concisely.
It's not the most concise way to iterate over a sequence of numbers from 1 to 9. Worse than that, it suggests that there may be a number missing somewhere in the middle. You have to scan the entire sequence with your eyes to be sure.
for (int i = 1; i <= 9; ++i)
That the data he chose can be expressed as a range is utterly inconsequential. The values are never even used. In all likelihood, the author just wrote
for (auto item : {})
>That the data he chose can be expressed as a range is utterly inconsequential
It could be, but we don't know that. And that's exactly my point. The syntax he uses forces us to think and even speculate about that. So for the particular sequence he chose for his example, it would be less ambiguous to generate the range algorithmically.
It could be, but we don't know that. And that's exactly my point. The syntax he uses forces us to think and even speculate about that. So for the particular sequence he chose for his example, it would be less ambiguous to generate the range algorithmically.
The point of using this sort of syntax for scrapcode is that you can just textually replace the the {...} with a real container variable.
If you should be so inclined later.
If you should be so inclined later.
Damn, too much confusion was made. I didn't pay enough attention to these things, my bad. Got rid of it.
Couldn't it even just have been "auto main()" and nothing in c++14?
No, that was forbidden by the resolution of Core Issue 1669, see: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html...
Using a custom allocator with standard collections can be highly useful, as the article points out. I do recommend defining your own container deriving from a type such as std::vector using private inheritance, and exposing the base definitions via the "using" keyword and replicating applicable typedefs/constructors.
Doing so will help prevent "interesting" behaviour and help expose assumptive template definitions in a code base.
Doing so will help prevent "interesting" behaviour and help expose assumptive template definitions in a code base.