Angular.js + CORS + IE11 + invalid URL = "SCRIPT7002: XMLHttpRequest: Network Error 0x7b..."

This time something completely different. I just hope that in future this post might save 2 hours of debugging.

In Nokia I'm the creator of internal search engine (but I actually do this in my leisure time). Something like Google, but only for our intranet. As you may expect it would be an overkill to employ C++ in front-end. Therefore I used Angular.js to do the job. And it does it's job pretty well.

However, recently one user came to me with a complain that he cannot log in into the site. I requested a log from console and got following.

SCRIPT7002: XMLHttpRequest: Network Error 0x7b, The filename, directory name, or volume label syntax is incorrect.

File: *************

Error: Unable to connect to the target server.

   at Anonymous function (https://******/bower_components/angular/angular.min.js:80:237)
   at t (https://******/bower_components/angular/angular.min.js:76:22)
   at Anonymous function (https://******/bower_components/angular/angular.min.js:73:367)
   at J (https://******/bower_components/angular/angular.min.js:100:404)
   [...]

At first glance I thought that this is some kind of bug in IE11 related to missing Origin header in XHR requests (this header is needed if you use CORS (Cross-Origin Resource Sharing)). During debugging this it turned out that the problem is completely different. And quite kinky one.

In some front-end configuration I used following URL.

https:///******

Note that there are three forward slashes. Do you think that IE11 can handle that?

Apparently no. The worst thing is that this part of URL was not present in JavaScript console in the browser.

Removing one forward slash fixed the bug, but 2 hours were wasted anyway.

TypeId using constexpr objects

Today we had another interesting conversation at the office. It all started with me explaining to my colleague what static keyword does in respect to free functions. At that time I was wondering whether the same rules apply to variables defined in the scope of translation unit. And... no surprise (luckily not today). However the conversation evolved... and I ended up trying to implement my own compile-time TypeId functionality with no memory footprint (one that vanishes from binary). Please don't ask me how we jumped from static keyword to TypeId ;) It just happened and I'd like to share some thoughts about it with you.

TypeId? Wait.. what exactly is it?
With moderate Google-fu (or having this knowledge before) it takes less than minute to find out typeid operator which is available since C++98. It returns std::type_info which contains some information about type provided as an argument. It is worth noticing that returned value is a lvalue and it lives till the end of your application. What does it mean? Yes, you're right. It all happens in run-time. Since this is not what I wanted to have, this solution was unacceptable.
Even if it would be acceptable - this type information is not available if you don't compile your program with RTTI (Run Time Type Information, -frtti switch for Clang/GCC). It means that there's performance penalty. We have to pay for it, but we'd rather like not to. What do we do, then?

Black magic applied
To solve this problem in compile-time we have to somehow map distinct types to some unique identifiers. I believe there are a lot of approaches over there, but my favorite one is to employ function addresses. Why function addresses? Because every two distinct functions are guaranteed to have different (unique) addresses. In other words two functions can't share one address in memory. Compiler must do this that way, for sure.
However, how can we make use of this fact to create identifier↔type mapping? It's easy - we'll treat addresses of static member functions from class templates as our identifiers. Following snippet illustrates this idea.

1 using TypeId = uintptr_t;
2 
3 template <typename T>
4 struct TypeIdGenerator {
5     static TypeId GetTypeId() {
6         return reinterpret_cast<uintptr_t>(&GetTypeId);
7     }
8 };

So now you may be asking yourself a question about this weird uintptr_t type. Why this particular type? Why not simply integer? It is all because size of a pointer (in this scenario pointer to method) can be of bigger size than other types like int or long. Actually C++ standard does not say a word about size of embedded types, but this is topic for other blog post ;-). The size of unitptr_t is guaranteed to be the same as size of pointers - and that saves us a day.
There's also one more caveat here, though. Unlike POSIX, C++ standard does not support casting pointers to functions to other pointers or scalar types. It is because code may (theoretically) be located in different kind of memory (with different size of words etc.) than data. That is the main reason why I was forced to use reinterpret_cast in above example.

Back to functions
Okay, but still there is one problem with presented code snippet. It leaves trace in assembly (and thus also in binary file):

 1 # g++-4.9.1, -std=c++14 -Os
 2 .LHOTB0:
 3     #        TypeIdGenerator<int>::GetTypeId()
 4     .weak    _ZN15TypeIdGeneratorIiE9GetTypeIdEv
 5     .type    _ZN15TypeIdGeneratorIiE9GetTypeIdEv, @function
 6 _ZN15TypeIdGeneratorIiE9GetTypeIdEv:
 7 .LFB2:
 8     .cfi_startproc
 9     movl    $_ZN15TypeIdGeneratorIiE9GetTypeIdEv, %eax
10     ret
11     .cfi_endproc

To overcome this I tried to use constexpr functions from C++11. I thought it is a good direction because these functions can be both compile-time and run-time. So maybe compile-time version will have some kind of compile-time address that we can use? And maybe this address will not be present in run-time binary? Let's see.

1 using TypeId = uintptr_t;
2 
3 template <typename T>
4 constexpr inline void GetTypeId() {}

Now we can get address of this free function, but unfortunately it still has to have some room in memory. So I was very wrong. However, we already limited implementation of this function to single ret instruction. At least that ;-).

1 _Z9GetTypeIdIiEvv:
2 .LFB2:
3     .cfi_startproc
4     ret
5     .cfi_endproc

Mission failed. I'm sorry. Maybe you have some other ideas how to achieve what I want? Nevertheless I decided to check one last thing - constexpr objects.

Constexpr objects
This was my last resort, but I knew it's not gonna work...

 1 using TypeId = uintptr_t;
 2 
 3 template <typename Type>
 4 struct GetTypeId {
 5     constexpr GetTypeId() {};
 6 };
 7 
 8 int main(void) {
 9     constexpr GetTypeId<int> object;
10     return reinterpret_cast<TypeId>(&object);
11 }

I know it is merely valid, because of returning reference to auto variable. Also, because this variable is auto and not static, identifiers will vary, depending on in which function this constexpr object was created (on the stack). Too bad. However, it gave very interesting output, presented on following assembly snippet.

1 main:
2 .LFB1:
3     .cfi_startproc
4     leaq    -1(%rsp), %rax
5     ret
6     .cfi_endproc

As you can see, there is nothing related to this object variable. At least we don't see this at first glance. GCC is just using the fact that the object is located "above" on the stack. Therefore leaq instruction is used. I was curious whether Clang would behave similarly in this situation:

1 main:                                   # @main
2     .cfi_startproc
3 # BB#0:
4     movl    $_ZZ4mainE6object, %eax
5     retq

In clang the object has some other address which is not relative to the stack. Interesting. It means that Clang will always allocate space in binary to accommodate this constexpr object. Even if it's not static!
I don't know whether this is a bug in Clang or a bug in GCC. If time permits I'll investigate this further.

Code::Dive conference

Code::dive conference is over. Emotions subsided. In this post I'd like to summarize this conference from my personal point of view.

There were a lot of extremely interesting talks about C++ and not only. Undoubtedly we had one C++ star on the board - Scott Meyers and I'm going to start with it.

Scott gave two talks CPU Caches and why you care and Support for embedded programming in C++11 and C++14. Both of them were meaningful from perspective of a modern C++ engineer. I encourage you to watch these videos!

Besides Scott we had our rising C++ stars from Poland: Andrzej Krzemieński and Bartosz Szurgot. Andrzej was talking about bugs in C++ applications. Bartek's talk was about common pitfalls that occur when we do threading in C++. These two talks were also very inspiring so go watch them as well ;)

I also gave a talk on this conference. My presentation was about Metaprogramming in C++ - from 70's to C++17. As other speaker said - the first time always sucks. And indeed it was my first performance in English. However people are saying that it went quite good so if you have time to waste you can go watch my presentation ;). For the record, slides are here: slideshare.

The last thing I'd like to mention was organisation of this conference. It was first that big conference in Wrocław and I can really say that it went perfectly. Big thanks to organizers!

Article on Clang internals & Code::Dive conference

Hi, there are two things that I'd like to share with you.

How it's made: Clang C++ compiler

The first one is that I produced one more article for polish developers journal "Programista". This time it is about Clang C++ compiler - how does it work and what's under the bonnet. Unfortunately, it is in Polish, but I promise I'll try to write sth in English soon.

Besides my scribbles you can also find two other interesting articles in current release:

1. Lightweight and portable dispatcher implementation in C++14
This article was written by my workmate Bartosz Szurgot (blog). Not only it describes near-ideal implementation - it also gives some overview on performance issues (useful research, IMHO).

2. C++ Exceptions in details
This in turn is written by Gynvael Coldwind (blog), famous IT security engineer. It is worth reading if you'd like to see how C++ exceptions are really working - in deep details.

Code::Dive

The second thing is my contribution to Code::Dive conference organised by Nokia. The conference is held in Wrocław and I'm going to speak about template metaprogramming in C++. You can find details on the official site.

Using static_assert in class-scope

Recently I was working on some presentation (I'm going to post more about this in separate post) and I needed to verify some facts about static_assert in C++11. I decided to look straight in the proposal. Besides information I needed I found that static_assert can be applied in three scopes:

1. namespace scope
2. class scope
3. block scope

I must admit that I only knew about the last option. It took me less than a minute to find out that class scope can be useful in case of my project - compile-time state machine (cfsm).

One example from cfsm is about ATMs. You can find similar code piece in there.

 1 namespace cfsm { // cfsm/Transition.hpp
 2     template <class StateType, StateType From, StateType To> class Transition;
 3 }
 4 
 5 enum class State {
 6     Welcome,
 7     SelectLanguage,
 8     CardError,
 9     // ...
10     PrintConfirmation,
11     Invalid
12 };
13 
14 template <State From, State To> struct AtmTransition : private cfsm::Transition<State, From, To> { };
15 
16 template <> struct AtmTransition<State::Welcome, State::SelectLanguage> { };
17 template <> struct AtmTransition<State::Welcome, State::CardError> { };
18 // ...
19 template <> struct AtmTransition<State::PrintConfirmation, State::Welcome> { };

Goal of this piece is to ensure that only defined transitions are possible. If a programmer makes a mistake, the compiler will yell that there's no specialization for given transition. After all, it is a lot better to catch such errors in compile-time, isn't it?

However, there are some drawbacks of this mechanism - compiler error messages aren't very readable. Compiler just complains about missing specialization. If the user knows what may be the cause it's not a problem. Otherwise he will be forced to go read header files, which are overloaded with templates. What can we do about it?

This is place where class-scope static_assert kicks in. Instead of not providing body for non-specialized transition template we can put one line with some message. It's going to look like following.

1 namespace cfsm { // cfsm/Transition.hpp
2     template <class StateType, StateType From, StateType To> class Transition {
3         static_assert(From == To && From != To, "Illegal transition or missing specialization.");
4     }
5 }

Note: Unfortunately we need to use such weird condition. Otherwise (e.g. in case of simple false) the compiler would do the assertion ad hoc.

There's one more problem to solve. Although custom error message says what the problem is, it doesn't contain enumerator values. This can be split into two separate issues:

1. Assertion message should be somehow joined by the compiler, basing on multiple constant strings
2. Enumerator values need to be represented as strings

It turns out that the later issue is addressed by another C++ proposal - N3815, so let's keep our fingers crossed! Anyway, the first problem is not going to be solved at the moment, which is obviously a bad thing.

With this little effort we gained an error message that tells almost everything about the core problem:

static.cpp: In instantiation of ‘class cfsm::Transition<State, (State)0, (State)4>’:

static.cpp:16:40:   required from ‘struct AtmTransition<(State)0, (State)4>’

static.cpp:25:51:   required from here

static.cpp:12:5: error: static assertion failed: Illegal transition or missing specialization.

     static_assert(From == To && From != To, "Illegal transition or missing specialization.");

Undesirable implicit conversions

Recently Andrzej Krzemienski published a post on his blog about inadvertent conversions. Basically the problem is that sometimes compiler performs implicit conversions (and, as of C++ standard it is allowed to perform at most one) that aren't desired by programmers. In my post I'd like to summarize all solutions that I'm aware of with ones that appeared in comments.

Classical source of such undesirable conversions are non-explicit constructors accepting exactly one non-default parameter. However, in this example there's a need to disable particular converting constructors while still accepting desired ones. Consider following piece of code:

1 struct C {
2     C(int const n) {}
3 };
4 
5 int main(void) {
6     C fromInt = 5;      // Okay
7     C fromDouble = 5.5; // Potentially not desired
8 }

This kind of problem occurs in boost::rational library, as Andrzej mentions. Okay, so what are the solutions? The first one is pretty obvious - let's explicitly delete all constructors accepting double as parameter.

1 struct C {
2     C(int const n) {}
3     C(double const x) = delete;
4 };
5 
6 int main(void) {
7     C fromInt = 5;      // Okay
8     C fromDouble = 5.5; // Illegal!
9 }

The solution is pretty straightforward and it addresses the problem basing on type, not type traits - which can be a problem in some contexts. There is another solution that lacks this particular problem. It employs enable_if to make sure only integral types can be used with our converting constructors.

 1 #include <type_traits>
 2 using namespace std;
 3 
 4 struct C {
 5     template <typename T, typename enable_if<is_integral<T>::value, int>::type = 0>
 6     C(T const n) {}
 7 };
 8 
 9 int main(void) {
10     C fromInt = 5;      // Okay
11     C fromDouble = 4.0; // Illegal!
12 }

It is elegant and it does the job well. However, in my humble opinion there's one area of improvement - diagnostics and readability. If we used static_assert error message produces by the compiler would be a lot more readable to the programmer. Also, the code would become more clear and the intentions would be visible at first sight.

1 #include <type_traits>
 2 using namespace std;
 3 
 4 struct C {
 5     template <typename T>
 6     C(T const n) {
 7         static_assert(is_integral<T>::value, "Only integral values are supported!");
 8     }
 9 };
10 
11 int main(void) {
12     C fromInt = 5;
13 
14     // error: static_assert failed "Only integral values are supported!"
15     C fromDouble = 4.0;
16 }

Do you know any issues that can appear with last solution? If yes please share them in comments, please ;)

Interestingly, when you compile example from the first listing on Clang (3.5, trunk 196051) you'll get an warning that implicit conversion is being used. GCC (4.8.2) stays quiet about that. This is another proof that clang is more user-friendly compiler.

Pointers to class members and their addresses

Today I was trying to help my work mate to design sort of unit testing helper. Basically it was about function pointers to virtual methods. Pointers to functions take virtuality into account when they are called with a reference or a pointer to the base class. The thing is that before I made my point, we have decided to check one simple thing.
So here's a puzzle for you. Given following code (and without using a compiler) try to answer following questions.

 1 #include <iostream>
 2 using namespace std;
 3 
 4 struct A {
 5     virtual void foo() {}
 6 };
 7 
 8 struct B : A {
 9     virtual void foo() {}
10 };
11 
12 int main(void) {
13     cout << hex << &A::foo << endl;
14     cout << hex << &B::foo << endl;
15 }

1. Will this code compile?
2. If yes, what will be the addresses of A::foo and B::foo methods, respectively?
3. If yes, what will be the output of this program?

Did you think about it? Remember... there's no hurry ;-).

Answer to the first question is positive as the code is well-formed C++. What about addresses of methods? C++ requires that every method has it's own unique place to live - an address (or offset). Virtuality does not change anything here, so we can assume that these addresses are some integers, let's say a and b.
The last question is the most tricky one. While intuition suggests that the output might look like following, it's not true at all.

  0x00c0d150
  0x00c0d15c

The real output of the program is:

  1
  1

What a surprise, right? The catch in above code fragment is that there's no overloaded function accepting function pointer for ostream. What the compiler can do instead? It can use implicit conversion. It turns out that there's implicit conversion from function pointer to a boolean. This would spill out if we used std::boolalpha flag, but who knew?

I'd like to ask you one more question: what if we used reinterpret_cast<void*> against member pointers in lines 13-14? Would the output have gotten right then?
Surprisingly, the code would not compile then. The reason for that are some machines that hold code and data memory in different locations. Therefore, it's hard to specify a portable way to convert between pointers to the data and pointers to the code.
The funny fact is that clang does not compile it, while GCC only issues a warning.