Unable to compile CppAD with VisualStudio2019 about cppad

[bradbell]

Thanks for the bug report.

Setting up the DLL import and exports should follow the instructions on
https://gitlab.kitware.com/cmake/community/wikis/doc/tutorials/BuildingWinDLL
where MyLibrary is cppad_lib

see line 62 of
https://github.com/coin-or/CppAD/blob/master/include/cppad/local/define.hpp

it seems to me that the call to GENERATE_EXPORT_HEADER should be in
https://github.com/coin-or/CppAD/blob/master/cppad_lib/CMakeLists.txt

Where lines 47 to 54 need to be replaced by the proper cmake instructions for cmake windows dlls. Would you please try this and see if it works for you.

[bradbell]

I am currently working on this and have reproduce the problem using on a windows machine with Visual Studio 2019.

Sorry for the delay, I was working on a tool for automatically converting omhelp documentation to sphinx. I have it working for the cppad_py project and plan to eventually use it for the cppad project; see
https://bradbell.github.io/cppad_py/doc/html/xsrst/cppad_py.html

[bradbell]

@GiulioRomualdi As I understand the remark above, this is no longer an issue. If you agree, would you pllease close this issue (since you were the one to originally open it).

[bradbell]

@traversaro @GiulioRomualdi I am closing this issue. Please re-open it if it is still a problem.

[GiulioRomualdi]

Hi @bradbell, thanks for answering. The solution you proposed is required only for autogenerating the export.h file. In our case, this is not required since the macros are already defined in define.hpp

CppAD/include/cppad/local/define.hpp

Lines 59 to 72 in 650e5df

	/*!
	\def CPPAD_LIB_EXPORT
	Special macro for exporting windows DLL symbols; see
	https://gitlab.kitware.com/cmake/community/wikis/doc/tutorials/BuildingWinDLL
	*/
	# ifdef _MSC_VER
	# ifdef cppad_lib_EXPORTS
	# define CPPAD_LIB_EXPORT __declspec(dllexport)
	# else
	# define CPPAD_LIB_EXPORT __declspec(dllimport)
	# endif // cppad_lib_EXPORTS
	# else // _MSC_VER
	# define CPPAD_LIB_EXPORT
	# endif

Calling the GENERATE_EXPORT_HEADER function is useful only for autogenerating that part of the code.

I think that the only way to solve the problem is to move the decorator CPPAD_LIB_EXPORT from the definition to the declaration of the functions/structs.

I can handle this an open a PR, let me know.

[GiulioRomualdi]

This patch complitelly fixes the compilation problem on VisualStudio2019

diff --git a/cppad_lib/cppad_colpack.cpp b/cppad_lib/cppad_colpack.cpp
index dc3327053..739363292 100644
--- a/cppad_lib/cppad_colpack.cpp
+++ b/cppad_lib/cppad_colpack.cpp
@@ -17,7 +17,7 @@ in the Eclipse Public License, Version 2.0 are satisfied:
 
 # if CPPAD_HAS_COLPACK == 0
 namespace CppAD { namespace local {
-    CPPAD_LIB_EXPORT void this_routine_should_never_get_called(void)
+    void this_routine_should_never_get_called(void)
     {   CPPAD_ASSERT_UNKNOWN(false); }
 } }
 # else // CPPAD_HAS_COLPACK
@@ -52,7 +52,7 @@ the entry with index (i, adolc_pattern[i][k]) is a non-zero
 in the sparsity pattern for the matrix.
 */
 // ----------------------------------------------------------------------
-CPPAD_LIB_EXPORT void cppad_colpack_general(
+void cppad_colpack_general(
     CppAD::vector<size_t>&               color         ,
     size_t                               m             ,
     size_t                               n             ,
@@ -164,7 +164,7 @@ For i = 0 , ... , m-1, and for k = 1, ... ,adolc_pattern[i][0],
 the entry with index (i, adolc_pattern[i][k]) is
 in the sparsity pattern for the symmetric matrix.
 */
-CPPAD_LIB_EXPORT void cppad_colpack_symmetric(
+void cppad_colpack_symmetric(
     CppAD::vector<size_t>&               color         ,
     size_t                               m             ,
     const CppAD::vector<unsigned int*>&  adolc_pattern )
diff --git a/cppad_lib/json_parser.cpp b/cppad_lib/json_parser.cpp
index fac417d9f..ac0910cee 100644
--- a/cppad_lib/json_parser.cpp
+++ b/cppad_lib/json_parser.cpp
@@ -20,7 +20,7 @@ in the Eclipse Public License, Version 2.0 are satisfied:
 // documentation for this routine is in the file below
 # include <cppad/local/graph/json_parser.hpp>
 
-CPPAD_LIB_EXPORT void CppAD::local::graph::json_parser(
+void CppAD::local::graph::json_parser(
     const std::string& json      ,
     cpp_graph&         graph_obj )
 {   using std::string;
diff --git a/cppad_lib/json_writer.cpp b/cppad_lib/json_writer.cpp
index 250345c6e..add4b20a9 100644
--- a/cppad_lib/json_writer.cpp
+++ b/cppad_lib/json_writer.cpp
@@ -17,7 +17,7 @@ in the Eclipse Public License, Version 2.0 are satisfied:
 // documentation for this routine is in the file below
 # include <cppad/local/graph/json_writer.hpp>
 
-CPPAD_LIB_EXPORT void CppAD::local::graph::json_writer(
+void CppAD::local::graph::json_writer(
     std::string&                              json                   ,
     const cpp_graph&                          graph_obj              )
 {   using std::string;
diff --git a/include/cppad/local/cppad_colpack.hpp b/include/cppad/local/cppad_colpack.hpp
index ee96ab5fe..6dd022180 100644
--- a/include/cppad/local/cppad_colpack.hpp
+++ b/include/cppad/local/cppad_colpack.hpp
@@ -59,7 +59,7 @@ it is not the case that both
 This routine tries to minimize, with respect to the choice of colors,
 the number of colors.
 */
-extern void cppad_colpack_general(
+CPPAD_LIB_EXPORT void cppad_colpack_general(
           CppAD::vector<size_t>&         color         ,
     size_t                               m             ,
     size_t                               n             ,
@@ -91,7 +91,7 @@ The properties of this coloring have not yet been determined; see
 Efficient Computation of Sparse Hessians Using Coloring
 and Automatic Differentiation (pdf/ad/gebemedhin14.pdf)
 */
-extern void cppad_colpack_symmetric(
+CPPAD_LIB_EXPORT void cppad_colpack_symmetric(
           CppAD::vector<size_t>&         color         ,
     size_t                               n             ,
     const CppAD::vector<unsigned int*>&  adolc_pattern
diff --git a/include/cppad/local/graph/json_parser.hpp b/include/cppad/local/graph/json_parser.hpp
index 17bcc7c7e..a28d2c045 100644
--- a/include/cppad/local/graph/json_parser.hpp
+++ b/include/cppad/local/graph/json_parser.hpp
@@ -42,7 +42,7 @@ Upon return it is a $cref cpp_ad_graph$$ representation of this function.
 $head Prototype$$
 $srccode%hpp% */
 namespace CppAD { namespace local { namespace graph {
-    void json_parser(
+    CPPAD_LIB_EXPORT void json_parser(
         const std::string&  json      ,
         cpp_graph&          graph_obj
     );
diff --git a/include/cppad/local/graph/json_writer.hpp b/include/cppad/local/graph/json_writer.hpp
index 36a4cb39f..299c56cc0 100644
--- a/include/cppad/local/graph/json_writer.hpp
+++ b/include/cppad/local/graph/json_writer.hpp
@@ -41,7 +41,7 @@ This is a $code cpp_graph$$ object.
 $head Prototype$$
 $srccode%hpp% */
 namespace CppAD { namespace local { namespace graph {
-    void json_writer(
+    CPPAD_LIB_EXPORT void json_writer(
         std::string&       json        ,
         const cpp_graph&   graph_obj
     );

[bradbell]

I am having trouble building the tests using the Visual Studio 2019. I am using the CMake gui to create the 2019 solution file,loading the solution into Visual Studio. When I try to build check_example_atomic_three I get the following error:

tangent.cpp
 C:\msys64\home\bradl\repo\cppad.git\include\cppad/local/ad_tape.hpp(73,1): error C2063: 'CppAD::operator *': not a function
 C:\msys64\home\bradl\repo\cppad.git\include\cppad/core/atomic/three_afun.hpp(216): message : see reference to class template instantiation 'CppAD::local::ADTape<Base>' being compiled
with
    [
        Base=float
    ]

The corresponding line in ad_tape.hpp is

friend AD<Base> CppAD::operator * <Base>
    (const AD<Base> &left, const AD<Base> &right);

[bradbell]

The following (modification of the simple console program example) works in Visual Studio 2019:

#include <iostream>

template <class Base> class AD;
template <class Base> AD<Base> operator *
(   const AD<Base>& left, const AD<Base>& righ );

template <class Base>class AD
{   friend AD<Base> operator * <Base>
    ( const AD<Base>& left, const AD<Base>& right );
private:
    Base value_;
public:
    Base Value(void) const
    {   return value_;  }
    AD(Base value) : value_(value)
    {}
};

int main()
{   AD<int> object(2);
    std::cout << "object.Value() = " << object.Value() << "\n";
    return 0;
}

[bradbell]

Changing 'float' -> 'double' and '0.f' -> '0.' in the file example/atomic_three/tangent.cpp
changes the base type from float to double for this example.

The resulting check_example_atomic_three target build and runs in Visual Studio 2019. Thus there is something about the float base type
https://coin-or.github.io/CppAD/doc/base_float.hpp.htm
that does not work with Visual studio

[bradbell]

Changing example/atomic_three/tangent.cpp to the following program still generates the compile error:

# include <cppad/cppad.hpp>

bool tangent(void)
{   bool ok = true;
    //
    CppAD::vector< CppAD::AD<float> > ax(1);
    ax[0]     = 0.0f;
    ax[0]    += ax[0] + 0.5f;
    //
    return ok;
}

[bradbell]

This is a simpler version of example/atomic_three/tangent.cpp that generates the compile error (but not if you changes 'float' -> 'double). The class CppAD::local::ADTape is not in use API for CppAD.

# include <cppad/cppad.hpp>

bool tangent(void)
{   bool ok = true;
    CppAD::local::ADTape<float> tape;
    return ok;
}

[bradbell]

The following version of example/atomic_three/tangent.cpp generates an error on Visual Studio 2019.
If you change the '# if 0' to a '# if 1' it works in Visual Studio. Both '# if 0' and '# if 1' work on gcc.

The problem is that with '# if 1' the friend declaration does not work for the operator in the CppAD namespace. We need to figure out how to tell Visual Studio that the friend is in the CppAD namespace.

namespace CppAD {
    template <class Base> class AD;
    template <class Base> AD<Base> operator *
        (const AD<Base> &left, const AD<Base> &right);
    namespace local {
        class mytape {
# if 0
            friend AD<int> operator *
                (const AD<int>& left, const AD<int>& right);
# else
            friend CppAD::AD<int> CppAD::operator * <int>
                (const CppAD::AD<int>& left, const CppAD::AD<int>& right);
# endif
        private:
            int value_;
        public:
            mytape( int value ) : value_(value)
            { }
            int Value(void) const
            {   return value_; }
        };
    }
}

bool tangent(void)
{   CppAD::local::mytape tape(2);
    bool ok = tape.Value() == 2;
    return ok;
}

[bradbell]

The following program works with TEMPLATE_CLASS1 both 0 (false) and 1 (true) on gcc, but only false on Visual Studio 2019; i.e., Visual Studio gets confused when class1 and the corresponding operator are templated.

# include <iostream>

# define TEMPLATE_CLASS1 0

# if TEMPLATE_CLASS1
# define TEMPLATE_TYPE template <class TYPE>
# define TYPE          Type
# define CLASS1        class1<Type>
# define CLASS1_INT    class1<int>
# else
# define TEMPLATE_TYPE
# define TYPE          int
# define CLASS1        class1
# define CLASS1_INT    class1
# endif

// begin ns1
namespace ns1 {
    // begin class1
    TEMPLATE_TYPE class class1 {
    private:
       TYPE value_;
    public:
       class1(TYPE value ) : value_(value)
       { }
       TYPE Value(void) const
       {   return value_; }
    }; // end class1
    // forward declaration or operator
    TEMPLATE_TYPE CLASS1 operator * 
    (const CLASS1& left, const CLASS1& right);
    // begin ns1
    namespace ns2 {
        // begin class2
        class class2 {
# if TEMPLATE_CLASS1
            friend ns1::class1<int> ns1::operator * <int> 
            (const ns1::class1<int>& left, const ns1::class1<int>& right);
# else
            friend ns1::class1 ns1::operator * 
            (const ns1::class1& left, const ns1::class1& right);
# endif
        private:
            int value_;
        public:
            class2( int value ) : value_(value)
            { }
            int Value(void) const
            {   return value_; }
        }; // end class2
    } // end ns2
    TEMPLATE_TYPE CLASS1 operator *
    (const CLASS1& left, const CLASS1 &right)
    {	ns2::class2 one(1);
	// use private access to value_ to make sure friend statement working
	return CLASS1( one.value_ * left.Value() * right.Value() );
    }
} // end ns1

// begin main
int main(void)
{   ns1::CLASS1_INT two(2), three(3);
    ns1::CLASS1_INT six = two * three;
    std::cout << "six.Value() = " << six.Value() << "\n";
    return 0;
} // end main

[bradbell]

I have posted the problem on stackoverflow 13 days ago
https://stackoverflow.com/questions/63288453/visual-studio-2019-c-not-recognizing-template-friends
and did not get an answer.

I have just tried an MS developer community posting
https://developercommunity.visualstudio.com/content/problem/1158800/visual-studio-2019-c-not-recognizing-template-frie.html

[bradbell]

I got a reply on stackoverflow (see link above) that enabled me to get past that problem.
I also fixed some other error and warnings that occurred during make check
which currently works for me; see the commits ad9e516 and 79e1cfd .

Please check if this works for you and if so, please close this issue

[traversaro]

I got a reply on stackoverflow (see link above) that enabled me to get past that problem.
I also fixed some other error and warnings that occurred during make check
which currently works for me; see the commits ad9e516 and 79e1cfd .

Please check if this works for you and if so, please close this issue

Hi @bradbell , thanks for the follow up and sorry for the lack of feedback. @GiulioRomualdi do you think we can check in blf CI if the new version of @bradbell fixes our problem? In that case, probably we can close #61 ?

[traversaro]

I enabled the compilation with cppad's latest commit in our CI (see robotology/robotology-superbuild#544) and it is working fine, thanks for the fixes!

[bradbell]

@traversaro It seems that you are using the platform that GiulioRomualdi had the problem with. If you think this issue has been resolved, would you please close it.

[traversaro]

Hi @bradbell, thanks a lot for your support. I think that @GiulioRomualdi is a bit behind in catching notifications on GitHub, but indeed the problem is solved. Feel free to close the issue yourself, I can't close it as I was not the original creator of the issue.