File size

File size

File size

File size

File size

1.3 GB

In Part 7, STL teaches us about Usual Arithmetic Conversions, Template Metaprogramming, and shares some of the STL internal implementation ( some of it not yet released ). Many of you have asked for some treatment of TMP and STL delivers! Merry Christmas. Here's hoping you all have a wonderful 2013.

Merry Christmas, great effort once again. Channel9 is my one stop destination to listen and watch this and all the other videos on C++/STL/Haskell and so on and so forth. Thank you Mr. Stephan T. Lavavej, Charles and all the other nice people at Channel9.

A great video as usual, and this time for a too often ignored subject that I care very much about.

Just to be sure I'm on the right path: in your example about the case of a "-2 billion" signed long to be added to a "-7 billion" signed long long (@ around 30:20 in the video), the conversion of the "-2 billion" should be to a LL not a ULL, right?

Just wanted to join in the chorus. Thanks so much for all the hard work. I really enjoy these lectures. They taught me a lot about the core language and the Standard Template Library and Visual Studio's implementation there of. They gave me lots of insights I'm really using in my day-to-day work. Stephan, you are my hero!

I would be of the opinion that a programmer trying to pass a value outside of a type's range deserves the spanking that the compiler would hand out.

Well it seems now at least the STL will give those (us?) bad programmers a pass due to its use of template metaprogramming. Talking of which, I would like to see more lectures about/including the arcane and mysterious world of template metaprogramming.

abigagli> in your example about the case of a "-2 billion" signed long to be added to a "-7 billion" signed long long (@ around 30:20 in the video), the conversion of the "-2 billion" should be to a LL not a ULL, right?

Argh, I simultaneously misspoke and scribbled the wrong thing on the whiteboard. (I might have been distracted by correcting myself from saying "promoted" to saying "converted" earlier.) You're absolutely correct - the signed long is widened to signed long long. I should have said "signed long long" and scribbled "sll" on the whiteboard at that moment. I correctly said "value preserving" and "negative 9 billion" immediately afterwards.

I apologize for the confusion, and thank you for the valuable correction.

Philhippus> I would be of the opinion that a programmer trying to pass a value outside of a type's range deserves the spanking that the compiler would hand out. Well it seems now at least the STL will give those (us?) bad programmers a pass due to its use of template metaprogramming.

The Standard says that comparing a signed char to an unsigned long long must compile (although the compiler can warn about anything if it wants to). Similarly, passing a range of signed char and a value of unsigned long long to std::find() must compile.

I would characterize this as "squirrelly", but the rules are the rules, and the STL has to follow them.

> Talking of which, I would like to see more lectures about/including the arcane and mysterious world of template metaprogramming.

I'll look for more places to mention it. I really don't like presenting template metaprogramming in the absence of realistic context, because that makes it seem bizarre and pointless. find() is a great example because we have good reasons to do lots of template metaprogramming:

* We need to determine when the stars align for the memchr() optimization, which requires detecting when the iterator (after "unwrapping") is a pointer to a possibly-const byte, and the value is integral.

* Then we need a 4-way test for all combinations of signed/unsigned ranges and signed/unsigned values.

* Plus a fifth case for when a small negative element could be equal to a huge unsigned value.

* Plus a special case for bool (mostly to avoid compiler warnings but also to avoid programmer headaches - there's enough going on here already).

// The following headers are required for all allocators.#include <stddef.h> // Required for size_t and ptrdiff_t#include <new> // Required for placement new and std::bad_alloc#include <stdexcept> // Required for std::length_error

// The following headers contain stuff that Mallocator uses.#include <stdlib.h> // For malloc() and free()#include <iostream> // For std::cout#include <ostream> // For std::endl

size_type max_size() const NOEXCEPT { // The following has been carefully written to be independent of // the definition of size_t and to avoid signed/unsigned warnings. return (static_cast<size_type>(0) - static_cast<size_type>(1)) / sizeof(T); }

// The return value of allocate(0) is unspecified. // Mallocator returns NULL in order to avoid depending // on malloc(0)'s implementation-defined behavior // (the implementation can define malloc(0) to return NULL, // in which case the bad_alloc check below would fire). // All allocators can return NULL in this case. if (n == 0) { return nullptr; }

// Allocators are not required to be assignable, so // all allocators should have a private unimplemented // assignment operator. Note that this will trigger the // off-by-default (enabled under /Wall) warning C4626 // "assignment operator could not be generated because a // base class assignment operator is inaccessible" within // the STL headers, but that warning is useless.private: Mallocator& operator=(const Mallocator&);};

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.