Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable CXX by default #198

Merged
merged 2 commits into from Jul 30, 2018

Conversation

@jschueller
Copy link
Collaborator

commented Jul 26, 2018

It's silly not to provide all algorithms by default,
c++ compiler are easy to find these days, worst case it can still be disabled

Also remove lib suffix

@stevengj

This comment has been minimized.

Copy link
Owner

commented Jul 26, 2018

https://github.com/stevengj/nlopt/blob/master/doc/docs/NLopt_Installation.md also needs to be updated.

Does the Matlab plugin work with the C++ version? The mex file may need to end in .cpp for Matlab to use the C++ linker.

Enable CXX by default
It's silly not to provide all algorithms by default,
c++ compiler are easy to find these days, worst case it can still be disabled

Also remove lib suffix

@jschueller jschueller force-pushed the jschueller:cxx branch from 7e51f9a to bbea90f Jul 27, 2018

@jschueller

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 27, 2018

I think cmake has what it takes to link to c++ when nlopt_lib is c++ enabled, but I did not test yet.

@@ -142,14 +142,13 @@ Note, however, that if you do this then Guile may not know where to load the `nl
NLopt with C++ algorithms
-------------------------

NLopt, as-is, is callable from C, C++, and Fortran, with optional Matlab and GNU Octave plugins (and even installs an `nlopt.hpp` C++ header file to allow you to call it in a more C++ style). By default, it includes only subroutines written in C (or written in Fortran and converted to C), to simplify linking. If you configure with:
NLopt, as-is, is callable from C, C++, and Fortran, with optional Matlab and GNU Octave plugins (and even installs an `nlopt.hpp` C++ header file to allow you to call it in a more C++ style). By default, it includes subroutines written in C (or written in Fortran and converted to C) and as well in C++. If you configure with:

This comment has been minimized.

Copy link
@stevengj

stevengj Jul 27, 2018

Owner

"and as well" is redundant, and "in" is misplace. Just say "and C++"


The `libnlopt_cxx` has the *same* interface as the ordinary NLopt library, and can *still* be called from ordinary C and Fortran programs. However, to use it you must also *link* with the C++ standard libraries. The easiest way to do this is to link with the C++ linker: compile your source files into `.o` object files, and then call the C++ compiler to link these `.o` files with `-lnlopt_cxx` into your executable program.
The resulting library has the *same* interface as the ordinary NLopt library, and can *still* be called from ordinary C, C++, and Fortran programs. However, to use it doesnt have to *link* with the C++ standard libraries.

This comment has been minimized.

Copy link
@stevengj

stevengj Jul 27, 2018

Owner

"However, one no longer has to link with the C++ standard libraries, which can sometimes be convenient for non-C++ programs, and allows libnlopt to be compatible with multiple C++ compilers simultaneously."

@stevengj

This comment has been minimized.

Copy link
Owner

commented Jul 27, 2018

Not having this on by default was never about C++ compilers being hard to find. The problems were:

  • There are too many C++ compilers, and they are often incompatible with one another — the pure C NLopt library works with any C++ compiler, but the C++ NLopt may only work with the C++ compiler it was built with. But these days there is a lot less diversity in C++ standard libraries.

  • Callers from Fortran and C may have to know to link with -lstdc++. That situation is somewhat improved these days because some systems (e.g. GNU/Linux) automatically recognize shared-library dependencies if the library is built correctly.

I'm still a bit worried about the latter — if we merge this, some people's Makefiles may break.

@stevengj

This comment has been minimized.

Copy link
Owner

commented Jul 27, 2018

(It used to be that Matlab only shipped with lcc on Windows, so out-of-the-box it only worked with pure-C plugins. I'm not sure what the situation is these days.)

@jschueller jschueller force-pushed the jschueller:cxx branch from d78b073 to 1411acf Jul 27, 2018

@jschueller

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 27, 2018

I just tested with matlab; it builds and loads fine, I guess it's fine on windows too at least when using cmake.

@jschueller

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 27, 2018

I also updated the doc.

@jschueller jschueller closed this Jul 30, 2018

@stevengj

This comment has been minimized.

Copy link
Owner

commented Jul 30, 2018

Why was this closed?

@jschueller jschueller reopened this Jul 30, 2018

@jschueller

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 30, 2018

I thought you were not too found of this change.

@stevengj

This comment has been minimized.

Copy link
Owner

commented Jul 30, 2018

I have mixed feelings, but I’m inclined to think that the pros outweigh the cons nowadays thanks to .so dependencies.

@stevengj stevengj merged commit 8da50d5 into stevengj:master Jul 30, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@jschueller jschueller deleted the jschueller:cxx branch Jul 30, 2018

@stevengj stevengj referenced this pull request Mar 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.