I've got some legacy code here that makes use of boost::filesystem in version 1.34.1. I've isolated it into a little test program:
#include <iostream>
#include <boost/filesystem/path.hpp>
int main()
{
// note the second parameter
boost::filesystem::path p( "/tmp/foo", boost::filesystem::native );
std::cout << p.string() << std::endl;
return 0;
}
When I try to compile this code with the current (1.46.1) version of Boost, I get the following error:
test.cpp: In function ‘int main()’:
test.cpp:7: error: invalid conversion from ‘bool (*)(const std::string&)’ to ‘void*’
test.cpp:7: error: initializing argument 2 of ‘boost::filesystem3::path::path(const Source&, typename boost::enable_if<boost::filesystem3::path_traits::is_pathable<typename boost::decay<T>::type>, void>::type*) [with Source = char [9]]’
I've tried to make heads or tails of the Boost documentation, but I can't seem to figure out what that second parameter was good for, or what to replace it with. Can anybody shed some light on this?
UPDATE: I was not really clear on the requirements. For a transition period at least, I will have to support both versions (1.34.1 and 1.46.1). Is there a compatible way to cover both versions of Boost with the same code, or will I have to resort to #if BOOST_VERSION magic?
UPDATE 2: Used #if BOOST_VERSION ... as no further opinion was forthcoming. Thanks for the help.
boost::filesystem defines two formats for filenames: native, which differs from system to system, and generic which is identical across systems. Under POSIX (which appears to be what you are using) the two are identical. Under Windows the native format allows backslashes whereas the generic format does not. Under VMS (for example) the two are very different (the native format is something like [dir.subdir]file).
boost::filesystem::native appears to have been intended to indicate that the filename you are providing is in native format. I believe the current version of boost::filesystem is supposed to decide automatically, and since you're on a POSIX system it makes no difference anyway.
In short, the correct thing to do is simply to omit the parameter.
native seems to be a function now and the path constructor doesn't seem to need the native specifier. So just removing it should be fine.
Related
Coderbyte is an online coding challenge site (I found it just 2 minutes ago).
The first C++ challenge you are greeted with has a C++ skeleton you need to modify:
#include <iostream>
#include <string>
using namespace std;
int FirstFactorial(int num) {
// Code goes here
return num;
}
int main() {
// Keep this function call here
cout << FirstFactorial(gets(stdin));
return 0;
}
If you are little familiar with C++ the first thing* that pops in your eyes is:
int FirstFactorial(int num);
cout << FirstFactorial(gets(stdin));
So, ok, the code calls gets which is deprecated since C++11 and removed since C++14 which is bad in itself.
But then I realize: gets is of type char*(char*). So it shouldn't accept a FILE* parameter and the result shouldn't be usable in the place of an int parameter, but ... not only it compiles without any warnings or errors, but it runs and actually passes the correct input value to FirstFactorial.
Outside of this particular site, the code doesn't compile (as expected), so what is going on here?
*Actually the first one is using namespace std but that is irrelevant to my issue here.
I'm the founder of Coderbyte and also the guy who created this gets(stdin) hack.
The comments on this post are correct that it is a form of find-and-replace, so let me explain why I did this really quickly.
Back in the day when I first created the site (around 2012), it only supported JavaScript. There was no way to "read in input" in JavaScript running in the browser, and so there would be a function foo(input) and I used the readline() function from Node.js to call it like foo(readline()). Except I was a kid and didn't know better, so I literally just replaced readline() with the input at run-time. So foo(readline()) became foo(2) or foo("hello") which worked fine for JavaScript.
Around 2013/2014 I added more languages and used third-party service to evaluate code online, but it was very difficult to do stdin/stdout with the services I was using, so I stuck with the same silly find-and-replace for languages like Python, Ruby, and eventually C++, C#, etc.
Fast forward to today, I run the code in my own containers, but never updated the way stdin/stdout works because people have gotten used to the weird hack (some people have even posted in forums explaining how to get around it).
I know it is not best practice and it isn't helpful for someone learning a new language to see hacks like this, but the idea was for new programmers to not worry about reading input at all and just focus on writing the algorithm to solve the problem. One common complaint about coding challenge sites years ago was that new programmers would spend a lot of time just figuring out how to read from stdin or read lines from a file, so I wanted new coders to avoid this problem on Coderbyte.
I'll be updating the entire editor page soon along with the default code and stdin reading for languages. Hopefully then C++ programmers will enjoy using Coderbyte more :)
I am intrigued. So, time to put the investigation goggles on and since I don't have access to the compiler or compilation flags I need to get inventive. Also because nothing about this code makes sense it's not a bad idea question every assumption.
First let's check the actual type of gets. I have a little trick for that:
template <class> struct Name;
int main() {
Name<decltype(gets)> n;
// keep this function call here
cout << FirstFactorial(gets(stdin));
return 0;
}
And that looks ... normal:
/tmp/613814454/Main.cpp:16:19: warning: 'gets' is deprecated [-Wdeprecated-declarations]
Name<decltype(gets)> n;
^
/usr/include/stdio.h:638:37: note: 'gets' has been explicitly marked deprecated here
extern char *gets (char *__s) __wur __attribute_deprecated__;
^
/usr/include/x86_64-linux-gnu/sys/cdefs.h:254:51: note: expanded from macro '__attribute_deprecated__'
# define __attribute_deprecated__ __attribute__ ((__deprecated__))
^
/tmp/613814454/Main.cpp:16:26: error: implicit instantiation of undefined template 'Name<char *(char *)>'
Name<decltype(gets)> n;
^
/tmp/613814454/Main.cpp:12:25: note: template is declared here
template <class> struct Name;
^
1 warning and 1 error generated.
gets is marked as deprecated and has the signature char *(char *). But then how is FirstFactorial(gets(stdin)); compiling?
Let's try something else:
int main() {
Name<decltype(gets(stdin))> n;
// keep this function call here
cout << FirstFactorial(gets(stdin));
return 0;
}
Which gives us:
/tmp/286775780/Main.cpp:15:21: error: implicit instantiation of undefined template 'Name<int>'
Name<decltype(8)> n;
^
Finally we are getting something: decltype(8). So the entire gets(stdin) was textually replaced with the input (8).
And the things get weirder. The compiler error continues:
/tmp/596773533/Main.cpp:18:26: error: no matching function for call to 'gets'
cout << FirstFactorial(gets(stdin));
^~~~
/usr/include/stdio.h:638:14: note: candidate function not viable: no known conversion from 'struct _IO_FILE *' to 'char *' for 1st argument
extern char *gets (char *__s) __wur __attribute_deprecated__;
So now we get the expected error for cout << FirstFactorial(gets(stdin));
I checked for a macro and since #undef gets seems to do nothing it looks like it isn't a macro.
But
std::integral_constant<int, gets(stdin)> n;
It compiles.
But
std::integral_constant<int, gets(stdin)> n; // OK
std::integral_constant<int, gets(stdin)> n2; // ERROR wtf??
Doesn't with the expected error at the n2 line.
And again, almost any modification to main makes the line cout << FirstFactorial(gets(stdin)); spit out the expected error.
Moreover the stdin actually seems to be empty.
So I can only conclude and speculate they have a little program that parses the source and tries (poorly) to replace gets(stdin) with the test case input value before actually feeding it into the compiler. If anybody has a better theory or actually knows what they are doing please share!
This is obviously a very bad practice. While researching this I found there is at least a question here (example) about this and because people have no idea that there is a site out there who does this their answer is "don't use gets use ... instead" which is indeed a good advice but only confuses the OP more since any attempt at a valid read from stdin will fail on this site.
TLDR
gets(stdin) is invalid C++. It's a gimmick this particular site uses (for what reasons I cannot figure out). If you want to continue to submit on the site (I am neither endorsing it neither not endorsing it) you have to use this construct that otherwise would not make sense, but be aware that it is brittle. Almost any modifications to main will spit out an error. Outside of this site use normal input reading methods.
I tried the following addition to main in the Coderbyte editor:
std::cout << "gets(stdin)";
Where the mysterious and enigmatic snippet gets(stdin) appears inside a string literal. This shouldn't possibly be transformed by anything, not even the preprocessor, and any C++ programmer should expect this code to print the exact string gets(stdin) to the standard output. And yet we see the following output, when compiled and run on coderbyte:
8
Where the value 8 is taken straight from the convenient 'input' field under the editor.
From this, it's clear that this online editor is performing blind find-and-replace operations on the source code, substitution appearances of gets(stdin) with the user's 'input'. I would personally call this a misuse of the language that's worse than careless preprocessor macros.
In the context of an online coding challenge website, I'm worried by this because it teaches unconventional, non-standard, meaningless, and at least unsafe practices like gets(stdin), and in a manner that can't be repeated on other platforms.
I'm sure it can't be this hard to just use std::cin and just stream input to a program.
When compiling following program with Xcode 10 GM:
#include <iostream>
#include <string>
#include <variant>
void hello(int) {
std::cout << "hello, int" << std::endl;
}
void hello(std::string const & msg) {
std::cout << "hello, " << msg << std::endl;
}
int main(int argc, const char * argv[]) {
// insert code here...
std::variant< int, std::string > var;
std::visit
(
[]( auto parameter )
{
hello( parameter );
},
var
);
return 0;
}
I get the following error:
main.cpp:27:5: Call to unavailable function 'visit': introduced in macOS 10.14
However, if I change min deployment target to macOS 10.14, the code compiles fine and it works, even though I am running macOS 10.13.
Since std::visit is function template, and should not depend on OS version (which I proved by running the code on lower version of mac than actually supported), should this be considered as bug and reported to Apple or is this expected behaviour?
The same happens when compiling for iOS (iOS 12 is minimally expected).
All std::variant functionality that might throw std::bad_variant_access is marked as available starting with macOS 10.14 (and corresponding iOS, tvOS and watchOS) in the standard header files. This is because the virtual std::bad_variant_access::what() method is not inline and thus defined in the libc++.dylib (provided by the OS).
There are several workarounds (all technically undefined behaviour), ordered by my personal preference:
1) Grab into the Implementation
std::visit only throws if one of the variant arguments is valueless_by_exception. Looking into the implementation gives you the clue to use the following workaround (assuming vs is a parameter pack of variants):
if (... && !vs.valueless_by_exception() ) {
std::__variant_detail::__visitation::__variant::__visit_value(visitor, vs...);
} else {
// error handling
}
Con: Might break with future libc++ versions. Ugly interface.
Pro: The compiler will probably yell at you when it breaks and the workaround can be easily adapted. You can write a wrapper against the ugly interface.
2) Suppress the Availability Compiler Error ...
Add _LIBCPP_DISABLE_AVAILABILITY to the project setting Preprocessor Macros ( GCC_PREPROCESSOR_DEFINITIONS)
Con: This will also suppress other availability guards (shared_mutex, bad_optional_access etc.).
2a) ... and just use it
It turns out that it already works in High Sierra, not only Mojave (I've tested down to 10.13.0).
In 10.12.6 and below you get the runtime error:
dyld: Symbol not found: __ZTISt18bad_variant_access
Referenced from: [...]/VariantAccess
Expected in: /usr/lib/libc++.1.dylib
in [...]/VariantAccess
Abort trap: 6
where the first line unmangles to _typeinfo for std::bad_variant_access. This means the dynamic linker (dyld) can't find the vtable pointing to the what() method mentioned in the introduction.
Con: Only works on certain OS versions, you only get to know at startup time if it does not work.
Pro: Maintains original interface.
2b) ... and provide your own exception implemention
Add the following lines one of your project source files:
// Strongly undefined behaviour (violates one definition rule)
const char* std::bad_variant_access::what() const noexcept {
return "bad_variant_access";
}
I've tested this for a standalone binary on 10.10.0, 10.12.6, 10.13.0, 10.14.1 and my example code works even when causing a std::bad_variant_access to be thrown, catching it by std::exception const& ex, and calling the virtual ex.what().
Con: My assumption is that this trick will break when using RTTI or exception handling across binary boundaries (e.g. different shared object libraries). But this is only an assumption and that's why I put this workaround last: I have no idea when it will break and what the symptoms will be.
Pro: Maintains original interface. Will probably work on all OS versions.
This happens because std::visit throws an bad_variant_access exception in cases described here and since the implementation of that exception depends on an newer version of libc++ you are required to use versions of iOS and macOS that ship this new version (macOS 10.14 and iOS 12).
Thankfuly, there is a implementation path available for when c++ exceptions are turned off which doesn't depend on the newer libc++ so if possible you can use that option.
P.S.
About the case where you increased the minimum deployment target to 10.14 and were still able to run the program normally on 10.13 I'm guessing you would run into problems at the point that this new exception would be triggered (since the exception method which relies on a newer version of libc++ would not be resolved).
Here's another alternative (that won't be palatable for some). If you're already using Boost, then you can use Boost.Variant2 when targeting iOS.
#if MACRO_TO_TEST_FOR_IOS_LT_11
#include <boost/variant2/variant.hpp>
namespace variant = boost::variant2;
#else
#include <variant>
namespace variant = std;
#endif
Then you can use variant::visit in your code.
I'm still working out the kinks to test for the iOS target version (and if we're targeting iOS at all). That's why I used MACRO_TO_TEST_FOR_IOS_LT_11 above, as a placeholder.
Similarly you can also use abseil-cpp libraries to seamlessly use std::variant where it is enabled, and abseil::variant where it isn't.
Abseil is an open-source collection of C++ code designed to augment the C++ standard library.
Add
CXXFLAGS += -D_LIBCPP_DISABLE_AVAILABILITY
to your Makefile.
See some of the other posts to see details on pros and cons of this, but this will get the code to compile and run.
Even though templates generally come from headers, doesn't mean the runtime target doesn't matter. Those templates are part of a wider library, and they compile to code that must still be compatible with the rest of that library. It makes sense for the whole standard library to be of one, single version, and it makes sense for that version to be the one that'll work on the target machine. Can you imagine the chaos that would ensue otherwise?
Some of the others here have given some low-level, practical reasons why in this particular case that version unity is important. Personally I think it's best to forget about implementation details like "templates go in headers" in situations like this; you shouldn't need to care about it, plus you risk making abstraction-breaking assumptions for little benefit. Just code to contract and you'll be fine.
I'm trying to use the date/time facilities of the C++ Boost library v1.41. (Note: this is Linux, not Windows; g++ v4.4.7)
Code:
#include <boost/date_time/posix_time/posix_time.hpp>
using boost::posix_time::ptime;
using boost::date_time::microsec_clock;
:
t1 = (boost::date_time::microsec_clock::local_time()); // line 208
The error:
tom.cpp:208: error: 'template<class time_type> class boost::date_time::microsec_clock' used without template parameters
Now, there's this in boost/date_time/posix_time/posix_time_types.hpp:
#ifdef BOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK
//! A time clock that has a resolution of one microsecond
/*! \ingroup time_basics
*/
typedef date_time::microsec_clock<ptime> microsec_clock;
#endif
What I'm concluding is that BOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK is undefined, resulting in the typedef never happening, resulting in the reference to "microsec_clock" looking like it needed a template parameter.
As far as I can tell, I'm following the Boost date_time documentation to the letter. Any ideas?
I have the same problem right now.
Yesterday it worked without any problems but today I needed to delete all my compiled libraries and recompile them due to a svn corruption problem. Ever since this error occurred.
The way to fix it is rather simple.
Just use
t1 = (boost::posix_time::microsec_clock::local_time());
instead of
t1 = (boost::date_time::microsec_clock::local_time());
This will preset the time type to posix format however it will not fix the initial problem with BOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK.
I hope this was of help to you.
I'm trying to compile the following snippet of code:
#include <boost/filesystem/path.hpp>
//Other includes snipped for brevity
boost::filesystem::path inPath("C:\\PathThatDoesNotExist");
std::cout << "Folder \'" << inPath.external_directory_string()
<< "\' does not exist.";
and I'm getting this error:
.\PathCheck.cpp(31) : error C2679:
binary '<<' : no operator found which
takes a right-hand operand of type
'const
boost::filesystem3::path::string_type'
(or there is no acceptable conversion)
My research so far tells me that this means the type is not known at compile time and that I might need a typedef? but I can't quite make that work in my head or in my code. The external_directory_string() function is deprecated, so I'm also concerned that could be a factor somehow (I'm handling it with #define BOOST_FILESYSTEM_DEPRECATED).
Can someone explain string_type and recommend how to turn it into a std::string or char*? I know there are other ways to get this information from a directory path, but I'd like to understand the issue anyway. :)
RESOLVED: I have v2 of the 1.44 boost libraries, but had "#define BOOST_FILESYSTEM_VERSION 3" in my header (a co-worker using another version had added it). If I comment this directive, my code compiles correctly. Looks like we need to synchronize our libraries.
With the mods below, your code compiles OK for me. This applies with or without the #define you mentioned.
boost::filesystem::path inpath("C:\\PathThatDoesNotExist");
std::cout << "Folder \'" << inpath.external_directory_string()
<< "\' does not exist.";
What version of Boost, and what compiler are you using?
I am on Boost 1.44, Visual C++ Express 2010. external_directory_string appears to return std::string for me.
EDIT:
However, when I explicitly set the Boost Filesystem version like this, I get your error:
# define BOOST_FILESYSTEM_VERSION 3
The default version for me on VS 2010 is 2, so I would investigate why boost/filesystem/path.hpp is setting this to 3 on your build.
From the Boost docs (1.45):
This is Version 2 of the Filesystem library.
Version 3, a major revision with many
new and improved features is also
available, but breaks some existing
code.
Sounds to me like if you get your build back to v2 you will be on more solid ground.
The boost::filesystem::path typedefs external_string_type to std::string (see here http://www.boost.org/doc/libs/1_43_0/boost/filesystem/path.hpp), which would suggest the problem lies elsewhere?
I am following the quickstart guide for boost::spirit, and I get this compiler warning when I include : "This header is deprecated. Please use: boost/spirit/include/classic_core.hpp" Should I be worried about this?
(quick start guide: http://spirit.sourceforge.net/distrib/spirit_1_8_5/libs/spirit/doc/quick_start.html , with full source of the program I am trying to compile here: http://spirit.sourceforge.net/distrib/spirit_1_8_5/libs/spirit/example/fundamental/number_list.cpp)
edit: Additionally, when I try to compile with the recommended classic_core.hpp and classic_push_back_actor.hpp headers, I get the following compiler errors:
test7.cpp: In function 'bool parse_numbers(const char*, __gnu_debug_def::vector<double, std::allocator<double> >&)':
test7.cpp:18: error: 'real_p' was not declared in this scope
test7.cpp:18: error: 'push_back_a' was not declared in this scope
test7.cpp:23: error: 'space_p' was not declared in this scope
test7.cpp:23: error: 'parse' was not declared in this scope
[EDIT:] The original answer is badly out of date; in particular the link is broken. The current version of Boost (since 2012-02-24) is 1.49.0.
The warning mentioned is a result of #include <boost/spirit.hpp> which is a deprecated header; however old examples on the web use this form. To get started, try the boost tutorials. Once you see the correct includes and namespaces, most old examples can easily be converted.
[OLD ANSWER:]
You must be using boost 1.39 or later (via SVN). This presentation should help:
http://www.boostcon.com/site-media/var/sphene/sphwiki/attachment/2009/05/07/SpiritV2.pdf
In short, there's a brand new way of doing thing and these are the namespaces to use:
boost::spirit:qi (for the parser)
boost::spirit::karma (for the generator lib)
The official release is 1.40 so probably by that time the doc will be updated.
EDIT: the doc in the boost SVN repository is being worked on and probably reflect the new architecture in a more faithful manner.
When you're including the classic headers the parsers are in the boost::spirit::classic namespace. Try:
using namespace boost::spirit::classic;
When a library indicates that a class/header/method/etc. is deprecated, it means that the maintainer of the library will most likely stop maintaining the functionality, and may remove it in the future. I would recommend to switch to the suggested header sooner than later, so save yourself from headaches in the future.
The new header may have a slightly different way of handling the feature, so you may need to make some code changes.
(I don't know much about boost, this is just a general comment)