You may remember Larry and Jen from the popular (900,000+ hits)
Deep C (and C++) slide-deck.
Well, they're back - this time practising their C++ by doing the Roman Numerals problem.
Given that this is a C++ solution, I suggest you replace the use of arrays with std::array objects. To get the number of elements in the std::array, you can just call the size member function. This will eliminate the need to use the C idiom for calculating the number of elements in an array.
Hi Jon. You're right, std::array won't deduce its size from its initializer. I overlooked that. std::vector would, however, though that would require the use of heap memory, which some would find disturbing. I personally view the C mechanism for determining the number of elements in an array rather hackish, and the C++ template approach (using a template to calculate the size by binding the array to a reference) isn't any better, IMO. I think that if you need to know the number of elements in a container, your first choice should be a container that can provide that information.
These are really great slides! I have an additional remark to Scott Meyers comments. I don't like the C stuff as well. What do You think about something like this:
It is safe and can also be resolved at compile time like the C variant. In addition there could be a version for containers. The we would have a unified non-member version of size() similar to std::begin() and std::end(). So probably it's worth adding it into a future standard!?
Hi Kai, thank you for your kind comment. I'm not going to add your suggestion to the slide-deck for three reasons 1) it's a lot of work writing even a few build-by-build slides in a deck like this! 2) I don't think it fits with the story. The level of C++ in the story is deliberately quite simple. The deck is not about me making the best possible C++ code I can write... it's about trying to help the reader (who I have targetted at a certain level) as much as possible. 3) I don't want the final code to be "perfect" - in the story they deliberately leave some suggestions hanging (eg the linkage if I recall). It's not about the code; it's about their learning which carries on after the deck ends! Cheers Jon
Your slides are perfect as they are! They show in an entertaining way, how good co-working can improve the result of our work (what is not only true for programming).
I was just triggered by Scott Meyers comment and my proposal was rather an reply to him, than a comment about Your slides. Surely this is not the right place for code style discussion. I am sorry about that.
Fantastic!
ReplyDeleteGiven that this is a C++ solution, I suggest you replace the use of arrays with std::array objects. To get the number of elements in the std::array, you can just call the size member function. This will eliminate the need to use the C idiom for calculating the number of elements in an array.
ReplyDeleteHi Scott,
ReplyDeleteI must be missing something... Wouldn't the declaration of the std::array object require the size? Could you provide an example?
Thanks
Hi Jon. You're right, std::array won't deduce its size from its initializer. I overlooked that. std::vector would, however, though that would require the use of heap memory, which some would find disturbing. I personally view the C mechanism for determining the number of elements in an array rather hackish, and the C++ template approach (using a template to calculate the size by binding the array to a reference) isn't any better, IMO. I think that if you need to know the number of elements in a container, your first choice should be a container that can provide that information.
ReplyDeleteThese are really great slides!
ReplyDeleteI have an additional remark to Scott Meyers comments. I don't like the C stuff as well. What do You think about
something like this:
template
inline constexpr size_t size(const T (&)[N]) { return N; }
It is safe and can also be resolved at compile time like the C variant. In addition there could be a version for containers.
The we would have a unified non-member version of size() similar to std::begin() and std::end().
So probably it's worth adding it into a future standard!?
Cheers,
Kai
Hi Kai,
ReplyDeletethank you for your kind comment.
I'm not going to add your suggestion to the slide-deck for three reasons
1) it's a lot of work writing even a few build-by-build slides in a deck like this!
2) I don't think it fits with the story. The level of C++ in the story is deliberately quite simple. The deck is not about me making the best possible C++ code I can write... it's about trying to help the reader (who I have targetted at a certain level) as much as possible.
3) I don't want the final code to be "perfect" - in the story they deliberately leave some suggestions hanging (eg the linkage if I recall). It's not about the code; it's about their learning which carries on after the deck ends!
Cheers
Jon
Hi Jon,
DeleteYour slides are perfect as they are! They show in an entertaining way, how good co-working can improve the result of our work (what is not only true for programming).
I was just triggered by Scott Meyers comment and my proposal was rather an reply to him, than a comment about Your slides. Surely this is not the right place for code style discussion. I am sorry about that.
Cheers,
Kai