Experimental Physics and
Industrial Control System

"J. Lewis Muir" <[email protected]> · Wed, 7 Jan 2015 13:37:01 -0600

On 1/7/15 7:18 AM, Mark Rivers wrote:
> Why is it necessary to include string only on OSX Yosemite, and not on
> Linux, Windows, vxWorks, or earlier versions of OSX?

Hi, Mark.

I think it's because of a difference between Clang and GCC (or another
compiler) or the C++ standard library that comes with the compiler.
On OS X Yosemite, asyn is being compiled with Clang, but on those
other systems, GCC or some other compiler is probably being used.  The
difference could also be between the version of Clang on OS X Yosemite
and an older version of Clang which might explain why it worked on a
previous version of OS X (assuming nothing else has changed; I haven't
tried compiling asyn R4-25 on a previous version of OS X).

Looking at line 75 of asyn/asynPortClient/asynPortClient.h from R4-25,
it is creating a new string instance via the std::string constructor,
but the string header is not included in asynPortClient.h.  The only C++
standard include at the top of asynPortClient.h is the stdexcept header:

  #include <stdexcept>

My guess is that including stdexcept using some compilers will cause
the string header to be included while on others, like Clang on OS X
Yosemite, it won't, hence the compile failure.

I created the following simple C++ program:

=== main.cc ===
1    #include <stdexcept>
2
3    int main(int argc, char *argv[])
4    {
5      return (argc >= 2) ? std::string(argv[1]).length() : 0;
6    }
===============

On an OS X Yosemite machine, it fails to compile as follows:

=== console ===
$ /usr/bin/clang++ -Wall -ansi -pedantic -o main main.cc
main.cc:5:24: error: implicit instantiation of undefined template
      'std::__1::basic_string<char, std::__1::char_traits<char>,
      std::__1::allocator<char> >'
  return (argc >= 2) ? std::string(argv[1]).length() : 0;
                       ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iosfwd:188:33: note: 
      template is declared here
    class _LIBCPP_TYPE_VIS_ONLY basic_string;
                                ^
1 error generated.
===============

If I comment out the stdexcept header include on line 1 of main.cc, it
also fails to compile, but with a different error message:

=== console ===
$ /usr/bin/clang++ -Wall -ansi -pedantic -o main main.cc
main.cc:5:24: error: use of undeclared identifier 'std'
  return (argc >= 2) ? std::string(argv[1]).length() : 0;
                       ^
1 error generated.
===============

Finally, if I replace line 1 of main.cc with the string header include
("#include <string>"), it compiles cleanly:

=== console ===
$ /usr/bin/clang++ -Wall -ansi -pedantic -o main main.cc
===============

Repeating the same three tests on a RHEL 5 machine using GCC produces a
different result for the first test but the same result for the other
two.

For the original main.cc, it compiles cleanly (unlike Clang):

=== console ===
$ /usr/bin/g++ -Wall -ansi -pedantic -o main main.cc
===============

When I comment out the stdexcept header include in line 1, it fails
(like Clang):

=== console ===
$ /usr/bin/g++ -Wall -ansi -pedantic -o main main.cc
main.cc: In function ‘int main(int, char**)’:
main.cc:5: error: ‘string’ is not a member of ‘std’
===============

And finally, replacing line 1 with the string header include, it
compiles cleanly (like Clang):

=== console ===
$ /usr/bin/g++ -Wall -ansi -pedantic -o main main.cc
===============

The OS X Yosemite machine is x86_64 hardware running OS X Yosemite
(10.10.1) with Xcode 6.1.1 and clang++ reporting the following version:

=== console ===
$ /usr/bin/clang++ --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
===============

The RHEL 5 machine is x86_64 hardware running Red Hat Enterprise Linux
Client 5.11 and GCC reporting the following version:

=== console ===
$ /usr/bin/g++ --version | head -1
g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
===============

Regards,

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System