[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #2114: Make CONFIG_HAVE_CXX14 an explicit config

[GitBox <gi...@apache.org>]

xiaoxiang781216 commented on a change in pull request #2114:
URL: https://github.com/apache/incubator-nuttx/pull/2114#discussion_r515756009



##########
File path: libs/libxx/Kconfig
##########
@@ -22,7 +22,7 @@ config HAVE_CXX
 
 config HAVE_CXX14
 	bool "C++14 support"
-	default n
+	default y

Review comment:
       > > > things to consider:
   > > > a. c++ versions the compiler supports
   > > > b1. c++ versions the c++ runtime supports (runtime X provides necessary functionalities to run apps written in c++Y)
   > > > b2. c++ versions the c++ runtime needs (runtime X itself needs to be built with -std=Y)
   > > 
   > > 
   > > Why b1 and b2 need difference? if you want the version v of c++ runtime, the compiler version should >= v at least.
   > 
   > i guess it depends on how the library is implemented.
   > at least the CONFIG_HAVE_CXX14 parts of NUTTX_LIBXX doesn't seem to require C++14 to build.
   > 
   > > What do you mean "c++ runtime" here? the fundmental c++ library(e.g. libsupc++, libcxxabi) provided by toolchain, or the standard c++ library(e.g. libc++, uClibc++) implementation. The first catagory is coupled with toolchain.
   > 
   > mainly the latter.
   > 
   > > > c1. c++ version to use to build c++ portions of nuttx, including c++ runtime
   > > > c2. c++ version to use to build an app
   > > 
   > > 
   > > c1 and c2 must use the same compiler version with the same option flag.
   > > > d. the compiler flag for c1/c2. (eg. -std=c++14 in case of gcc/clang)
   > > > random thoughts:
   > > > 
   > > > * c1 can be a Kconfig "choice"
   > > > * c1. is restricted by b1 and b2.
   > > >   i hope the restrictions here can be represented solely with Kconfig directives.
   > > > * right now c1 == c2. it's nicer to let users to specify c2. probably within the app's Makefile.
   > > 
   > > 
   > > c2 must be same as c1, there isn't guarantee that the object with the different compiler option can be safely linked together.
   > 
   > really?
   > while i'm not a C++ expert in any sense, i believe it's common to use a single library for multiple versions.
   > or, are you suggesting that compiling your app with -std=X does require c++ libraries built with -std=X?
   > maybe some flags can alter the abi incompatible ways. but i thought it works in many cases.
   > 
   
   Yes, it' nightmare to compile app with one version library and link with the same library with another version. C++ standard never define any binary interface. The implementation is free to add/remove the private field or even reorder the field and function sequence, which mean that the object/vtable layout can be changed as needed.
   
   > > > * a. and d. belong to Make.defs/Toolchain.defs
   > > >   probably a set of make vars like:
   > > >   CXXSTDFLAGS_cxx14=-std=c++14
   > > >   CXXSTDFLAGS_cxx17=-std=c++17
   > > 
   > > 
   > > Two method, I can come up:
   > > ```
   > > 1. Let's user hardcode c++ compiler version in Make.defs/Toolchain.defs
   > > 
   > > 2. Add Kconfig option, and let's user select which version he want in defconfig, then Make.def/Toolchain.defs add std=c++14 or std=c++17 as needed. On the other hand, if you pass version w to compiler, c++ library will adapter the implementation to confirm to w version standard automatically.
   > > ```
   > > 
   > > 
   > > But all other c++ related code(NUTTX_LIBXX, UCLIBXX, LIBCXX) should check __cplusplus not Kconfig's option.
   > > > * the current CONFIG_HAVE_CXX14 has no good use. it's simpler to check __cplusplus directly if necessary.
   > > > * right now, in case of NUTTX_LIBXX, b1. is controlled by c1. (via CONFIG_HAVE_CXX14)
   > > 
   > > 
   > > yes, NUTTX_LIBXX could directly check __cplusplus.
   
   > i remembered a use case which drove me to this PR.
   > i wanted to have C (not C++) code with #ifdef CONFIG_HAVE_CXX14.
   > it wanted to know if symbols like "_ZdaPvm" was available in the system or not, to build a symbol table.
   > as it's in C, i can't check __cplusplus.
   > i don't want to make the code to C++ either, as i don't want to introduce C++ dependency only for this.
   
   why not compile the symbol table with c++ compiler? only the global symbol table need be decorated by extern "C". then:
   
   1. You can check __cplusplus to know which function exist
   2. Reference the function directly instead _ZdaPvm(which isn't portable between compiler)




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org