hpyproject / hpy

HPy: a better API for Python
https://hpyproject.org
MIT License
1.02k stars 52 forks source link

MSVC designated initializer experience in C++ is poor #441

Open KubaO opened 1 year ago

KubaO commented 1 year ago

In C++ projects, MSVC only supports designated initializers when the project is compiled under C++20 standard. Such a deep change is not feasible in large projects.

Thus misc.h bombs when included in any C++ source file under MSVC.

A dirty workaround in misc.h is to have

#if defined( _MSC_VER ) && defined( __cplusplus )
static inline HPyField _py2hf( PyObject* obj )
{
    HPy h = _py2h( obj );
    return { h._i };
}

static inline PyObject* _hf2py( HPyField hf )
{
    HPy h { hf._i };
    return _h2py( h );
}

static inline HPyGlobal _py2hg( PyObject* obj )
{
    HPy h = _py2h( obj );
    return { h._i };
}

static inline PyObject* _hg2py( HPyGlobal hf )
{
    HPy h { hf._i };
    return _h2py( h );
}
#else
// existing code
#endif

Would this change be acceptable, and if not - how else should such a workaround be implemented?

fangerer commented 1 year ago

Thank you for this issue. I'm sorry for C++ incompatibilities. We are mostly testing with plain C.

However, I thought we already considered this case. If you have a look at header hpy.h:112, this already has exactly the same guard as you would introduce (i.e. #if defined( _MSC_VER ) && defined( __cplusplus )).

I'm just trying to understand the problem. Is the problem that the current misc.h does (e.g in function _py2hf) _hfconv( ._i = h._i );? Should it be just _hfconv( h._i );?