Dlib: Matlab mex class example cannot build under VS2015

[asbe]

All examples in the dlib/matlab folder builds under VS2015, save the example_mex_class.cpp.

I believe the problem lies in mex_wrapper.cpp line 4831 where a tuple of function pointers is made:
auto mex_class_methods = std::make_tuple(FOR_EACH(MEX_CLASS_ANNOTATE, MEX_CLASS_METHODS));

This triggers C3539: a template-argument cannot be a type that contains 'auto' - I think this is code that will compile under GCC, but is bending the standard a bit? Also it seems that the compiler infers the auto to be 'int' at a later stage, which may not be correct.

My C++-skills are not up to the level of fixing this. Is this auto absolutely needed?

By the way: Thanks for your time and for sharing a very well written and coherent library!

[davisking]

Yes, the auto is needed. If the version of visual studio you are using
can't deal with auto then it's seriously broken. Maybe you need to get the
updates to visual studio? There are updates on microsoft's web page, I
think the latest is called "update 3". Also, there have been multiple
versions of "update 3" which makes it confusing.

[asbe]

I've tested with the cumulative service patch for Update 3, version number 14.0. 25431.01, released on 09/14/2016 - which I believe to be the newest update. I just tested with VS 2017 RC, and got the same issue.

[davisking]

Huh, don't know then. I haven't tested it with visual studio lately, only
on linux.

[asbe]

Ok. I'll try to figure out a workaround and will submit a pull request if I manage to fix it.

[asbe]

Tried to use the FOR_EACH macro with decltype to avoid auto. After failing this with a couple variants I'd expect to work I looked at the preprocessor output. The line 4831 expands to

auto mex_class_methods = std::make_tuple(&example_class::do_stuff, do_other_stuff, print_state, saveobj, load_obj);

That can't be right.

[davisking]

Yeah that's not right. Probably a bug in visual studio's preprocessor.

[asbe]

Yep. Apparently MSVC does not expand __VA_ARGS__ into several elements. Trying to fix inspired by http://stackoverflow.com/a/11994395/

[asbe]

After fixing the VA_ARGS issue the line in question preprocess correctly, i.e. to

auto mex_class_methods = std::make_tuple(&example_class::do_stuff,&example_class::do_other_stuff,&example_class::print_state,&example_class::saveobj,&example_class::load_obj);

However, now compilation breaks at line 4857 - which I do think is completely unrelated.

MSVC seems to parse the "typedef typename" incorrectly. I cannot understand why - since this looks valid C++ to me.

template
struct tuple_element_default_void
{
typedef typename tuple_element::type type;
};

I understand that you don't have ready access to VS (or necessarily the time to work out this bug) - but I you have any ideas or pointers I'd be very grateful!

[davisking]

I'm not sure what the problem is. But generally speaking, I've always found these kinds of weird bugs in visual studio where they don't quite conform to the C++ standard. I would just permute the code until you find a way to avoid the bug in visual studio. Sometimes simple stuff like making an intermediate type makes visual studio not barf. e.g.

typedef uple_element<i,T> temp_t;
typedef typename temp_t::type type;

You never know with visual studio. It used to be one of my favorite compilers (a long time ago) but now it's far and away the worst. Whenever I'm trying to work around some bug or non-conformity to the C++ standard it's almost always in visual studio.

[dashesy]

@asbe try changing that to:

    using type = tuple_element<i,T>::type;

[asbe]

@dashesy Thanks for the tip, I've tried several variants of using, and intermediate variables as @davisking suggested. Unfortunately it will still not compile under MSVC 2015 using /std:c++latest (14, I believe) and language extensions turned on. I actually gave up and coded my own class wrapper - but this cannot efficiently use the marshalling in dlib.

We may as well close this for the time being?

[davisking]

Yeah, might as well. Visual studio still doesn't support all of C++11. I regularly run into C++11 code that makes visual studio crash even. Hopefully it will be C++11 compliant at some point in the not too distant future.