Compiler errors Visual Studio.

[nicokruithof]

#include <vu8/Module.hpp>

void test() {}

void register()
{
    vu8::Module module;
    module("print", &print)
        .Set<void(), &test>("test");
}

gives the following errors with Visual Studio 2010 x64:

1> error C2975: 'Ptr' : invalid template argument for 'vu8::Module::Set', expected compile-time constant expression
1> vu8\src\vu8/Module.hpp(74) : see declaration of 'Ptr'
1> error C2977: 'vu8::Module::Set' : too many template arguments
1> vu8\src\vu8/Module.hpp(69) : see declaration of 'vu8::Module::Set'
1> error C2780: 'vu8::Module &vu8::Module::Set(const char *,vu8::Class<T,F> &)' : expects 2 arguments - 1 provided
1> vu8\src\vu8/Module.hpp(64) : see declaration of 'vu8::Module::Set'

[insidewhy]

It seems Visual Studio is still not fully conforming to the C++ spec. Pointer to member functions are stated to be allowed as compile-time constant template parameters and yet here Visual Studio is still disallowing it with a bogus error message. Shame.

[insidewhy]

I believe that boost::multi_index_container has a hack for this in VS inside its "boost::member" class.

I'll have to look into it.

Ah Microsoft.. when they aren't making you rewrite your HTML and CSS due to their inadequacies they're making you rewrite your C++.

[nicokruithof]

Yes, I guess so. I normally use boost::bind with member functions. I can
test, but it'll probably take me much more time to dive into that it'll
take you.

On Sun, Jan 1, 2012 at 9:32 PM, nuisanceofcats <
[email protected]

wrote:

It seems Visual Studio is still not fully conforming to the C++ spec.
Pointer to member functions are stated to be allowed as compile-time
constant template parameters and yet here Visual Studio is still
disallowing it with a bogus error message. Shame.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

Nico Kruithof
nghk.nl

[insidewhy]

This isn't a case for boost::bind as I need to be able to represent the method pointer at compile time and boost::bind is a purely runtime abstraction.

At any rate I cannot fix this in Visual Studio as I cannot afford to purchase Microsoft Windows or Visual Studio.

[nicokruithof]

ok. I'll dive into boost::multi_index_container and see whether I can resolve the error.

By the way, Visual Studio has a free version (and a three month trial for the professional edition). But I'd rather work on linux as well.

[insidewhy]

It'll be a hard one I'm pushing the C++ compiler about as hard as it can go for this project.

I'd like to support Windows with all my code but I don't wish to break the law or spend that much money on a shoddy operating system.

[insidewhy]

Well breaking the law is okay but not over a stupid OS :)

[nicokruithof]

Another option for me would be to use cvv8 to generate the InvocationCallback function and then add that to the vu8::Module. I like the vu8 interface better as it is cleaner, but already had the functions generated by cvv8.

[insidewhy]

Yeah I helped the author of cvv8 out with his template work.

Now maybe he can help me get it working in VS :)

[nicokruithof]

Hi,

I got things working on windows by combining vu8 and cvv8:

v8::Handlev8::Value print(const v8::Arguments& args);
void sleep(double s);

vu8::Module module;
module("print", &print);
module.Set("sleep", cvv8::FunctionToInCa<void (double), ::sleep,
true>::Call);

Not very nice, but not too much boilerplate either.

Now I'd like to wrap some of my C++ classes with in a javascript class to
provide a way to interact with them from the javascript engine. So the
classes already exist in my application and I'd only like to create a
javascript interface to them. Do you know an example that I could use as a
starting point?

Best regards,
Nico

On Sun, Jan 1, 2012 at 10:18 PM, nuisanceofcats <
[email protected]

wrote:

Yeah I helped the author of cvv8 out with his template work.

Now maybe he can help me get it working in VS :)

---

Reply to this email directly or view it on GitHub:
#4 (comment)

Nico Kruithof
nghk.nl

[insidewhy]

Damn Visual Studio. Also I'm working on this in my fork, not my work account fork.

[nicokruithof]

TSA is your work account? What kind of work do you do? Where do you live?

Nico

On Thu, Jan 19, 2012 at 1:07 PM, nuisanceofcats <
[email protected]

wrote:

Damn Visual Studio. Also I'm working on this in my fork, not my work
account fork.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

Nico Kruithof
nghk.nl

[insidewhy]

I live in the UK, TSA is my work account. I code and design software there mainly in C++.

[nicokruithof]

Is there anything I could do? Implement / test on visual studio?

[insidewhy]

Happy to accept patches for anything, thank you so much for your help.

The only reason I haven't accepted your other patches yet is because I wanted to discuss a few things about that with you, I'll leave a comment in that bug.

[nicokruithof]

I'm not quite sure how to solve the error with the const member functions.
Could you point me in the right direction?

[insidewhy]

I'm a little confused by this one too. I woulda though the code on line 161 of Class.hpp would catch the "const" specialisation with the "T const" there. Could possibly try disabling that one on visual studio, or maybe I missed something. I have spent about half an hour looking into this and nothing has been obvious to me yet. If only I had visual studio I'd be able to test it; my gcc accepts your code fine.

[insidewhy]

Yeah maybe try disabling the const or non-const specialisation of Set

[nicokruithof]

Yes, I know about gcc. It just compiles. I use both linux / os x and
windows to compile my application.

I disabled the second and third specialization and things are fine:
//template <class P, typename detail::MemFunProto<T const,
P>::method_type Ptr>
//inline Class& Set(char const *name) {
// return Method< detail::MemFun<T const, P, Ptr> >(name);
//}

//// passing v8::Arguments directly but modify return type
//template <class R, R (T::*Ptr)(const v8::Arguments&)>
//inline Class& Set(char const *name) {
//    return Set<R(const v8::Arguments&), Ptr>(name);
//}

On Sat, Jan 21, 2012 at 8:45 PM, nuisanceofcats <
[email protected]

wrote:

I'm a little confused by this one too. I woulda though the code on line
161 of Class.hpp would catch the "const" specialisation with the "T const"
there. Could possibly try disabling that one on visual studio, or maybe I
missed something. I have spent about half an hour looking into this and
nothing has been obvious to me yet. If only I had visual studio I'd be able
to test it; my gcc accepts your code fine.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

Nico Kruithof
nghk.nl

[insidewhy]

Can you try it just disabling the 2nd and not the 3rd... The 3rd provides a separate feature for vararg handling.

If that works then we can put an #ifdef around for visual studio. Do you know what symbol I should check for?

[nicokruithof]

Either one of them is not enough. I don't see how the compiler can match
the third as it explicitly defines const v8::Arguments& to be the argument
and my member function doesn't have arguments. The fourth Set is fine as it
only has one template argument.

On Sat, Jan 21, 2012 at 9:33 PM, nuisanceofcats <
[email protected]

wrote:

Can you try it just disabling the 2nd and not the 3rd... The 3rd provides
a separate feature for vararg handling.

If that works then we can put an #ifdef around for visual studio. Do you
know what symbol I should check for?

---

Reply to this email directly or view it on GitHub:
#4 (comment)

Nico Kruithof
nghk.nl

[insidewhy]

Hm, don't know what to say then. Pretty rubbish compiler really. Can you use mingw or cygwin under windows instead?

[nicokruithof]

I'm compiling against the 3.8.3 version of V8, just realized that you
download something yourself in one of our build scripts. Could that make a
difference?

[nicokruithof]

Got it compiling by renaming the last two member specializations and
disabling the second one on windows. I know it is an ugly hack to get
things working, but at least it works. I believe I sent you the commit as
well, but I'm more used to SVN than to Git.

[insidewhy]

The latest version from this account's fork has the cmake in for building against the system v8. You now have to force it to download an build v8 itself.

[tsa]

I better work around this by supplying specialisations with different names for broken compilers.

Then gcc can use the "Set" syntax and the other ones can use "SetConst" etc.