Some useful features?

[andriish]

Hi @lyskov ,

just before doing some work and creating the merge requests:

• Maybe I've missed that, but is that possible to prevent creation of bindings for certain constructors?

• It would be nice to have bindings for some constants. Of course it makes no sense to bind 'double x;', but binding 'const double zeta5=1.036927755143369926331365486457034168057080919;' makes a lot of sense. Actually I'm not sure how that would work in the general case, but at least for the fundamental types that should be OK. What is your opinion?

• It could make sense to assure that during the parsing binder defines itself, e.g. BINDER and optionally its version BINDER_MAJOR, BINDER_MINOR. Then one could write some useful constructions like

#if defined(__BINDER__) and defined(_MSC_VER ) and ...
....
#else 
...
#endif

and similar. What is your opinion?

• Not sure if many people in your field use Apple and if you have some around, but ... I've tried to compile binder with external LLVM on mac and it basically compiles. But any attempt to run binder ends up with some cryptic complains about the command line arguments.

Best regards,

Andrii

[lyskov]

Maybe I've missed that, but is that possible to prevent creation of bindings for certain constructors?

-- yes, this is already supported, one can use -function my_namespace::MyClass::MyClass(...) notation to disable bindings for certain constructors.

• It would be nice to have bindings for some constants. Of course it makes no sense to bind 'double x;', but binding 'const double zeta5=1.036927755143369926331365486457034168057080919;' makes a lot of sense. Actually I'm not sure how that would work in the general case, but at least for the fundamental types that should be OK. What is your opinion?

-- this might be useful. Implementing this for user defined types in general case might be tricky though. So starting with fundamental types seems like a good low-hanging-fruit goal. If you going to work on this then first thing would be to prototype how to extract such constant declarations from AST, - please ping me if/when you have draft that can do it so we on the same page on general implementation framework.

• It could make sense to assure that during the parsing binder defines itself, e.g. BINDER and optionally its version BINDER_MAJOR, BINDER_MINOR. Then one could write some useful constructions like

-- hmm... i am not sure how useful this will bee: If someone need to supply an extra define to distinguish between Binder-run and general code compilation then this could be done by simply using -D Clang/Binder command line option. I would say that the need for such general Binder-version-define if/when we have different Binder behavior based on it version (we do not so far).

• Not sure if many people in your field use Apple and if you have some around, but ... I've tried to compile binder with external LLVM on mac and it basically compiles. But any attempt to run binder ends up with some cryptic complains about the command line arguments.

-- we routinely use Binder on Mac's (thats how all Mac PyRosetta versions is created: http://www.pyrosetta.org/dow). Most likely issue that you hitting is that you need to to point Binder to the correct version of libc++ headers. This is because now Apple provide various Xcode versions each with separate libc++ headers. On recent MacOS/Xcode install passing -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -isystem/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 to Binder should do. Here is detailed discussion on why and how to workaround this issue: https://stackoverflow.com/questions/58278260/cant-compile-a-c-program-on-a-mac-after-upgrading-to-catalina-10-15

[andriish]

Hi @lyskov ,

thanks a lot for the answers!

-- yes, this is already supported

Ok. then there is an issue. See #142

If you going to work on this then first thing would be to prototype how to extract such constant declarations from AST, - please ping me if/when you have draft that can do it so we on the same page on general implementation framework.

I had a draft for it. But at some point I've started to think about the proper implementation of things like this:

const double zeta_2=M_PI*M_PI/6.0;
const double zeta_3=1.202;

where in the first case the M_PI is a macro and should not be preprocessed, but the whole code should be preserved 'as is'.
I will be back to it in some weeks.

this could be done by simply using -D Clang/Binder command line option.

Yes. This is what I'm doing and as well as many other people. So this is just a matter of optimization and standardisation.

I would say that the need for such general Binder-version-define if/when we have different Binder behavior based on it version (we do not so far).

Agree. Originally I thought about this part in another context: to have an option for binder to stamp the codes with something like

/// Generated  on: 20.09.2020
/// binder version: 1.0.1
/// clang  version:  6.0.0
///                 STL:   __GLIBCXX__ =20150623
//                   OS:  x86_64-redhat-linux

Most likely issue that you hitting is that you need to to point Binder to the correct version of libc++ headers. This is because now Apple provide various Xcode versions each with separate libc++ headers. On recent MacOS/Xcode install passing ...

OK. thanks! I will have a look. Hopefully this will work. My first idea was that the problem is with the installation of clang I use -- my working mac is just a secondary laptop and it is really weak and recompilation of the whole llvm is not attractive.

• i am not sure integrating (any) format checking into CI worth the trouble.

The formating with clang-format in CI or cmake is trivial. It is not that important if it is in CI, cmake or just in command line. The initial formatting is important. But when/if you do that it is up to you.

Best regards,

Andrii