Closed Dapid closed 8 years ago
Quick question: Are you compiling develop or master? Short answer is that I believe this has been fixed on develop and I can port that to master. Long answer, this arises from a bug with alias templates in GCC that was resolved between GCC 4.8 and GCC 4.9 and above. Consider the program:
#include <iostream>
#include <typeinfo>
#include <cstdlib>
template <typename U,template <typename> class T>
struct foo{
static void print() {
std::cerr << "Undefined for type: "<< typeid(T <U>).name()
<< std::endl;
exit(EXIT_FAILURE);
}
};
// Create a dummy templated class
template <typename T>
struct bar {};
// Create a template alias based on this class
template <typename T> using bar_alias = bar <T>;
template <typename T>
struct foo <T,bar> {
static void print() {
std::cout << "This is bar" << std::endl;
}
};
int main() {
foo <double,bar>::print();
foo <double,bar_alias>::print();
}
In GCC 4.9, this produces:
$ ./alias_template
This is bar
This is bar
In GCC 4.8 this produces:
$ ./alias_template
This is bar
Undefined for type: 3barIdE
Anyway, the result from GCC 4.9 and later is the correct result. Prior to my use of newer versions of GCC, I didn't know this was the case and I used an old work around that was incorrect, which I'm pretty sure is what the error above is. Technically, that code I attached is something slightly different, but I believe it to be a manifestation of the same bug.
I do have a fix and I can back port it into master. That being said, my preference would be to just fix up a couple of existing documentation issues and then do a new release, which would also fix things. In the immediate future:
By the way, develop is now using C++14, so your CMake options will need to change slightly. In terms of when there's a new release, I do intend to do so soon. I could probably do that this week.
I was compiling master, sorry I forgot to specify, and thank you for your detailed explanation. You know you are doing fancy stuff when you start hitting compiler bugs... Indeed, disabling the unit tests works on master.
On a side note: in both master and develop I had to manually set the C++ flavour flag, shouldn't they be there by default? I have the environment variable $CCFLAGS set to my architecture, and Cmake is picking it up, which is nice, but I wonder if it is overriding the setting.
I am not planning to use it in the immediate future, so I can wait for the new release. Also, I can test it in my boxes to make sure it runs smoothly before the release.
Sounds great. I'm grinding through some code at the moment, but I'll send a message by in the next few days.
Good call on the autodetect C++ versions. I updated the CMake scripts to auto set the C++14 compiler flags in commit 37bf35d230222236e653bece7f23b64d70c2c549. It looks like this came out with CMake 3.1 and I updated all of the required versions accordingly.
I'll wait to close this issue out when everything is pushed to master.
I'm going to close this out since the issue was fixed and open a new ticket with the list of things I need to do before pushing everything to master. Mostly, I'm trying to stay organized.
I am getting the following errors when compiling. I am using release mode, and I have manually included the
--std=c++11
flag. The OS is Fedora 22, GCC 5.1.1, (c)cmake 3.3.2: