Problem with make on OSX 10.10.2

[vikash]

Following error is coming:

mkdir -p shared/common
mkdir -p shared/zend
mkdir -p shared/hhvm
c++ -Wall -c -g -std=c++11 `php-config --includes` -fpic -o shared/zend/base.o zend/base.cpp

In file included from zend/base.cpp:8:
In file included from zend/includes.h:126:
zend/constantimpl.h:131:18: error: call to member function 'property' is ambiguous
            clss.property(_name, Z_LVAL(_constant.value), Php::Const);
            ~~~~~^~~~~~~~
zend/../include/classbase.h:236:10: note: candidate function
    void property(const char *name, int16_t value, int flags = Php::Public);
         ^
zend/../include/classbase.h:237:10: note: candidate function
    void property(const char *name, int32_t value, int flags = Php::Public);
         ^
zend/../include/classbase.h:238:10: note: candidate function
    void property(const char *name, int64_t value, int flags = Php::Public);
         ^
zend/../include/classbase.h:239:10: note: candidate function
    void property(const char *name, bool value, int flags = Php::Public);
         ^
zend/../include/classbase.h:240:10: note: candidate function
    void property(const char *name, char value, int flags = Php::Public);
         ^
zend/../include/classbase.h:243:10: note: candidate function
    void property(const char *name, double value, int flags = Php::Public);
         ^
zend/../include/classbase.h:235:10: note: candidate function not viable: no known conversion from 'const long' to 'std::nullptr_t' (aka 'nullptr_t') for 2nd argument
    void property(const char *name, std::nullptr_t value, int flags = Php::Public);
         ^
zend/../include/classbase.h:241:10: note: candidate function not viable: no known conversion from 'const long' to 'const std::string' (aka 'const basic_string<char, char_traits<char>, allocator<char> >') for
      2nd argument
    void property(const char *name, const std::string &value, int flags = Php::Public);
         ^
zend/../include/classbase.h:242:10: note: candidate function not viable: no known conversion from 'const long' to 'const char *' for 2nd argument
    void property(const char *name, const char *value, int flags = Php::Public);
         ^
zend/../include/classbase.h:253:10: note: candidate function not viable: no known conversion from 'const long' to 'const getter_callback_0' (aka 'Php::Value (Php::Base::*const)()') for 2nd argument
    void property(const char *name, const getter_callback_0 &getter, const setter_callback_0 &setter);
         ^
zend/../include/classbase.h:254:10: note: candidate function not viable: no known conversion from 'const long' to 'const getter_callback_1' (aka 'Php::Value (Php::Base::*const)() const') for 2nd argument
    void property(const char *name, const getter_callback_1 &getter, const setter_callback_0 &setter);
         ^
zend/../include/classbase.h:255:10: note: candidate function not viable: no known conversion from 'const long' to 'const getter_callback_0' (aka 'Php::Value (Php::Base::*const)()') for 2nd argument
    void property(const char *name, const getter_callback_0 &getter, const setter_callback_1 &setter);
         ^
zend/../include/classbase.h:256:10: note: candidate function not viable: no known conversion from 'const long' to 'const getter_callback_1' (aka 'Php::Value (Php::Base::*const)() const') for 2nd argument
    void property(const char *name, const getter_callback_1 &getter, const setter_callback_1 &setter);
         ^
zend/../include/classbase.h:251:10: note: candidate function not viable: requires 2 arguments, but 3 were provided
    void property(const char *name, const getter_callback_0 &getter);
         ^
zend/../include/classbase.h:252:10: note: candidate function not viable: requires 2 arguments, but 3 were provided
    void property(const char *name, const getter_callback_1 &getter);
         ^
1 error generated.
make: *** [shared/zend/base.o] Error 1

[schoentoon]

What compiler are you using? c++ --version

[vikash]

Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix

[EmielBruijntjes]

I have no 32bit system here right now, but I may be able to solve it right away. Could you fetch the master branche to see if the latest commit solves your issue?

[andot]

change int16_t, int32_t, int64_t to short, int, long, long long can fix this bug.

[atvise]

@andot .. I would suggest, as in issue #57, the other way around to define every variable type as int16_t, int32_t etc. A quick quote of my posting in issue #57:

"... what i noticed is that you mixing the value type definitions (int(C/C++), int32_t(STL), int32(PHP)) could be lead to problems if some platform define f.e: int as a 64 bit type you know what i mean. I suggest that maybe if its prossible to use only one definition of one type. Furthermore accessing arrays should be done if possible with size_t or uint32_t and not with and fixed signed type like "int32_t" because it's safer [-n access] etc. and you are scaleable (under x64 size_t is 64bit - just for the future because php is only available in 32bit for now). STL containeres are also using size_t as index and return parameter. ..."

[andot]

I think that the users can decide to use intNN_t or short, int, long or long long in their php extensions. If we use short, int, long or long long in PHPCPP, and users use the intNN_t, that will not be in conflict, it will automatically map to the correct size type. And if we use intNN_t in PHPCPP, and the users use the short, int, long or long long, that will cause the conflict. Similarly, if we use intNN_t in PHPCPP, and the type of PHP returned is short, int, long or long long, also can produce conflict. Therefore, using short, int, long or long long in PHPCPP will be safer than intNN_t.

[atvise]

The problem is that you shouldn't mix any types either int with int32_t or the other way around or long with int around also you should be aware how much bytes your are actually are using but only with the define int32_t you can be shure about that. So therefore ether use only long or int or int32_t or size_t if you want to get the full advantage of 64bit.

[andot]

The short, int, long and long long are the base type in C++, other integer types (such as int32_t, size_t) are all mapped to them. So if we used short, int, long and long long in PHP-CPP, the users can use any integer types in their extensions.

[atvise]

And then they want to build their extensions on multiply plattforms on both 32bit and 64bit and then they have the same problem so why not rather say that's the interface (you can still cast n int to an int32_t if an compile error occures) and deal with it.

[andot]

If they want to build their extensions on multiply platforms on both 32bit and 64bit, and if they want some fixed size type, they can use int32_t, int64_t or size_t. There is no problem when we supplied the full of short, int, long and long long API.

[EmielBruijntjes]

AFAIK, the real issue comes from Zend. In Zend, they have been so stupid smart to use "long" as the numeric type, which causes numbers to have different limits on 32bit and 64bit systems (see https://software.intel.com/en-us/articles/size-of-long-integer-type-on-different-architecture-and-os).

You know, PHP was just developed by some guys that needed a tool to make websites interactive, without having a big master plan, and without knowing that one day it would grow out to be one of the most important web languages in the universe. They just did things. This is the cause that PHP has so many inconsistencies and strange "features". The fact that numbers in a script language behave different when the script runs on a 32bit platform than on a 64bit platform is weird - script languages are supposed to run the same everywhere, and not depend on the architecture! This is still an issue among the PHP internal girls and guys, and once in a while you see suggestions coming up to finally solve this 32bit/64bit mistake that PHP has. I don't know what the current state is.

In PHP-CPP I wanted to hide this internal PHP mistake, and only expose "stdint.h" types. PHP-CPP only works with explicit 16bit, 32bit or 64bit numbers, so for a PHP-CPP user there can be no doubt about the number of bits that is being used for a variable.

It is not going to happen that PHP-CPP is going to expose vague types like 'long' and 'int', because I do not want to make the same mistake that Zend did.

The question is: does PHP-CPP now compile on a 32bit platform? If the answer is yes, the problem is solved.

[andot]

In fact, Mac OS X 10.10.2 is 64bit platform.

[EmielBruijntjes]

I have no access to a mac, so I could really use a pull request if someone can fix it. Just a single (int64_t) cast has to be added to solve this.

[atvise]

@andot: sry but that's not true if the interface has long and you use int32_t you have the same problem as the other way around.

@EmielBruijntjes: I totaly agree with you 👍 that's my point. Under Win7 32bit it works. But nevertheless we should replace the currently not converted "int, long, etc" to "int32_t".

To the compiling problem maybe this helps:
__STDC_LIMIT_MACROS
__STDC_CONSTANT_MACROS

http://stackoverflow.com/questions/986426/what-do-stdc-limit-macros-and-stdc-constant-macros-mean

[andot]

It still can't work on Mac OS X. but my branch can works https://github.com/andot/PHP-CPP/tree/my_branches. I used short, int, long and long long instead of intNN_t.

If the interface has short, int, long and long long, when you use int32_t, there is no problem. If you don't believe me, you can try by yourself.

I think the user decides to use long, int or int32_t in their extensions is better. We should give them a choice rather than a limit. So I think using short, int, long and long long is not a bug, it's a feature, :)

[andot]

The new version can compile now. But make test can't work:

./h/../include/variables/011-012-value-casting-operators.h:23:8: error: 
      conversion from 'Php::Value' to 'long' is ambiguous
                long value1 = value;

...

/Users/andot/Git/PHP-CPP/tests/include/lib/phpcpp/class.h:479:16: error: 
      ambiguous conversion for functional-style cast from 'long' to 'Php::Value'
        return Value(obj->__toInteger()).setType(Type::Numeric);