If I instantiate a mapped_file_source (boost 1.46.1 ) with a narrow character string as in the following I don't have a problem:
boost::iostreams::mapped_file_source m_file_( "testfile.txt" );
However if I try to use a wide string:
boost::iostreams::mapped_file_source m_file_( L"testfile.txt" );
I get the following compiler error in VC2010 SP1:
P:\libs\boost_1_46_1\boost/iostreams/device/mapped_file.hpp(128): error C2248: 'boost::iostreams::detail::path::path' : cannot access private member declared in class 'boost::iostreams::detail::path'
P:\libs\boost_1_46_1\boost/iostreams/detail/path.hpp(111) : see declaration of 'boost::iostreams::detail::path::path'>
P:\libs\boost_1_46_1\boost/iostreams/detail/path.hpp(37) : see declaration of 'boost::iostreams::detail::path'
If I instead try to pass the constructor a boost::filesystem::path I get the following error:
P:\libs\boost_1_46_1\boost/iostreams/device/mapped_file.hpp(128): error C2664: 'boost::iostreams::detail::path::path(const std::string &)' : cannot convert parameter 1 from 'const boost::filesystem3::path' to 'const std::string &'
Reason: cannot convert from 'const boost::filesystem3::path' to 'const std::string'
I feel like I'm missing something obvious, but I'm just running around in circles trying to figure out what the compiler is trying to tell me, but I'm just getting lost. That palm to forehead moment is just not happening.. What is it that I am doing incorrectly?
The constructor defined in mapped_file.hpp looks like the following:
// Constructor taking a parameters object
template<typename Path>
explicit mapped_file_source(const basic_mapped_file_params<Path>& p);
The basic_mapped_file_params class constructors look like this:
// Construction from a Path
explicit basic_mapped_file_params(const Path& p) : path(p) { }
// Construction from a path of a different type
template<typename PathT>
explicit basic_mapped_file_params(const PathT& p) : path(p) { }
Where the template class is defined as:
// This template allows Boost.Filesystem paths to be specified when creating or
// reopening a memory mapped file, without creating a dependence on
// Boost.Filesystem. Possible values of Path include std::string,
// boost::filesystem::path, boost::filesystem::wpath,
// and boost::iostreams::detail::path (used to store either a std::string or a
// std::wstring).
template<typename Path>
struct basic_mapped_file_params
: detail::mapped_file_params_base
{
There is some additional help in the header that says:
// For wide paths, instantiate basic_mapped_file_params
// with boost::filesystem::wpath
If I take this approach with:
boost::iostreams::basic_mapped_file_params<boost::filesystem::wpath> _tmp(L"test.txt");
boost::iostreams::mapped_file_source m_file_( _tmp );
I get the same C2664 error mentioned above..
I know the compiler is telling me what the problem is, but looking at the header source and the comments leads me to believe that what I'm trying to accomplish is supported, it's just my approach that is incorrect. Am I misinterpreting what the header file is telling me? I know there is probably a good lesson about template instantiation and explicit/implicit conversion in here somewhere.
Interestingly enough, upgrading my boost install to 1.47.0 seems to cleared up C2664 error but I'm still getting the C2248 error about access to the private member.
With boost 1.48 I can do something like this.
#include <boost/filesystem.hpp>
#include <boost/iostreams/device/mapped_file.hpp>
#include <iostream>
int main()
{
boost::filesystem::path p(L"b.cpp");
boost::iostreams::mapped_file file(p); // or mapped_file_source
std::cout << file.data() << std::endl;
}
or you can do this with mapped_file_params(used create new file)
boost::filesystem::path p(L"aa");
basic_mapped_file_params<boost::filesystem::path> param; // template param
param.path = p;
param.new_file_size = 1024;
It's telling you that boost::iostreams::mapped_file_source's constructor does not take a wchar_t*, nor does it take a boost::filesystem::path. It only takes std::string, or types convertible to std::string. Or, to put it another way, you can't use UTF-16 paths with this object.
It looks like the documentation for mapped_file is pretty old and does not reflect what is in the header or in the header comments. In order to instantiate a boost::iostreams:mapped_file_source object with a wide character string you need to explicity pass in the boost::iostreams::detail::path like this:
boost::iostreams::mapped_file_source m_file_( boost::iostreams::detail::path(boost::filesystem::path(L"testfile.txt")) );
I was able to get this to compile by stepping thought the error messages and determining how the template classes were being instantiated and finally saw that boost::iostreams::detail::path had a private constructor that took a &std::wstring as a parameter which is where the code was failing to compile.
Related
I'm now dealing with template in c++ with PCL (Point Cloud Library) and I encountered something that I'm not able to solve (I searched before on the internet and on Stack)
I have a template class called Features.
my hpp file:
#ifndef KeyFeatures_hpp
#define KeyFeatures_hpp
// Declarations and includes
typedef pcl::PointXYZRGB PointTypeRGB;
template<typename FeatureType>
class Features {
public:
Features(const int typeDescriptor);
void setDescriptorExtractor(typename pcl::Feature<PointTypeRGB, FeatureType>::Ptr extractor);
private:
typename pcl::Feature<PointTypeRGB, FeatureType>::Ptr m_descriptor_extractor;
};
#endif /* Features_hpp */
In the cpp file I have a constructor which will checks what kind of type is it and then perform some action.
template <typename FeatureType>
Features<FeatureType>::Features(const int type){
//Some code
if (type == DESCRIPTOR_SHOT){
pcl::SHOTEstimationOMP<PointTypeRGB, pcl::Normal, pcl::SHOT352>* shot = new pcl::SHOTEstimationOMP<PointTypeRGB, pcl::Normal, pcl::SHOT352>;
shot->setRadiusSearch (0.02f);
pcl::Feature<PointTypeRGB, pcl::SHOT352>::Ptr descriptor_extractor (shot);
descriptor_extractor->setSearchMethod (pcl::search::Search<PointTypeRGB>::Ptr (new pcl::search::KdTree<PointTypeRGB>));
this->m_descriptor_extractor = descriptor_extractor;//ERROR
setDescriptorExtractor(descriptor_extractor);//ERROR
// Some code
}
The error appeared in the last two lines when I try without success to fill in my variable member.
Each time I have the following error x 10 (corresponding to my 10 kind of type)
error: no matching conversion for functional-style cast from 'const shared_ptr<pcl::Feature<pcl::PointXYZRGB, pcl::SHOT352> >'
to 'this_type' (aka 'shared_ptr<pcl::Feature<pcl::PointXYZRGB, pcl::ShapeContext1980> >')
However at the end of my cpp file I put all my template class. For example:
template class Features<pcl::SHOT352>;
In my main function I called this class by using:
Features<pcl::SHOT352> feature_SHOT(type);
It seems that it's not able to perform the conversion..
Can someone might be able to help me ?
Thank
Apparently you are instantiating Features<pcl::ShapeContext1980> so its m_descriptor_extractor has the type pcl::Feature<pcl::PointXYZRGB, pcl::ShapeContext1980>::Ptr which is shared_ptr<pcl::Feature<pcl::PointXYZRGB, pcl::ShapeContext1980>>.
But inside the constructor you are still using pcl::Feature<pcl::PointXYZRGB, pcl::SHOT352>::Ptr, that is shared_ptr<pcl::Feature<pcl::PointXYZRGB, pcl::SHOT352>> - a totally different type.
And as a side note, you generally don't implement templates in .cpp files.
Firstly, the official term is a "class template" - a template for creating classes.
You appear to have created a class called Features<pcl::ShapeContext1980>.
This has m_descriptor_extractor of type shared_ptr<pcl::Feature<pcl::PointXYZRGB, pcl::ShapeContext1980> >
You are trying to assign a shared_ptr<pcl::Feature<pcl::PointXYZRGB, pcl::SHOT352>> to it.
They are completely unrelated types, so it fails at compile time.
I'm trying to compile a project that has the following header:locale.h;
locale.h:
class LOG4CXX_EXPORT Locale
{
public:
...
protected:
Locale(const Locale&);
Locale& operator=(const Locale&);
const LogString language; <-- error
const LogString country; <-- error
const LogString variant; <-- error
}; // class Locale
Could anyone give me some suggestions ?
I'm getting this error. I am not sure
what is the problem.
/LOGGER/include/log4cxx/helpers/locale.h:42:41: error: field ‘language’ has incomplete type
const LogString language;
^
/LOGGER/include/log4cxx/helpers/locale.h:43:41: error: field ‘country’ has incomplete type
const LogString country;
^
/LOGGER/include/log4cxx/helpers/locale.h:44:41: error: field ‘variant’ has incomplete type
Consider the following code:
class MyClass;
int method1(const MyClass& param);
MyClass& method2();
const MyClass instance; // <- error here
The declaration of MyClass is a forward declaration. All the compiler know is that the class exists (it doesn't know its members, size...), that's why it is called an incomplete type. You can use references or pointers of that class, but that's it. See more info here When can I use a forward declaration?
So it seems that in your code, you only have a forward declaration of LogString type, and not a full declaration. Check your include files and include order so you get the full declaration of this class.
You are using std::basic_string, but there is no include for the appropriate header file:
#include <string>
What AnT wrote in a comment is the solution to the problem:
<clocale> is including your <locale.h> instead of the system one it ought to do; your locale is trying to include <string>, which again includes <clocale>.
So in the end, you get a circular include as I described in your other question https://stackoverflow.com/questions/32379927/header-file-does-not-compile-locale-h, just the chain being longer...
You need to break this inclusion circle. You can do this by removing the directory the file resides in from the inclusion directories you pass to gcc (I suppose this is -I"/LOGGER/include/log4cxx/helpers"). Instead, you can give a path to the parent directory (-I"/LOGGER/include/"). Instead of #include <locale.h> you would have to use #include <log4cxx/helpers/locale.h>.
Actually, I recommend keeping "/LOGGER/include" as the only directory you give gcc and have all other files you need included via the corresponding subpath - provided the rest of the log4cxx files allow that (which I would assume).
Apart from that, the only other way to solve the problem is indeed renaming your 'locale.h' file to something else (apart from changine the include path division, such as -I"/LOGGER/include/log4cxx" and #include <helpers/locale.h>; the one I chose, however, is the most natural one IMO).
I'm facing an interesting problem: I had an MFC application project in Visual C++ 6.0. Since there are many changes either in MFC or in C++ standard, I wanted to port my application to Visual Studio 2010. It was fine, but I am facing a warning now, which I can't handle.
The header file has the following class definition:
template <class T>
class foo : public CObject
{
// ...
// other stuff
// ...
private:
CTypedPtrMap<CMapWordToPtr, const long, T*> oElementMap;
void some_stuff();
}
In the source file there is:
template <class T>
void foo::some_stuff()
{
// ...
// other stuff
// ...
int nIndex = 0;
// ...
// other stuff
// ...
oElementMap.RemoveKey(nIndex);
}
When I try to compile this, I get the following warnings:
Warning 1 warning C4244: 'argument' : conversion from 'const long' to
'WORD', possible loss of data c:\programme\microsoft visual studio
10.0\vc\atlmfc\include\afxtempl.h 2066
It comes definetly from the above mentioned "RemoveKey" line: if I just simply comment out that line, I won't get this warning.
I know, the main problem is, that CTypedPtrMap object uses const long as key type, but CMapWordToPtr would have WORD (unsigned short) instead of it. But the fact is: I need const long as key type, since I am processing regulary about 1 million data entries in this map, so with unsigned short the class would not be capable to do it's job furthermore.
I tried to nest either the "RemoveKey" line or the include of stdafx.h into the following expressions, but neither worked:
#pragma warning (disable: 4244)
// expression
#pragma warning (default: 4244)
Please share me any ideas about this issue, how could I resolve this warning WITHOUT changing the container's oElementMap definition and behaviour, and WITHOUT supress/disable this warning globally in the project settings as well as WITHOUT changing the afxtempl.h file supplied by VS2010.
Thanks for help:
Andrew
I've replaced it's definition to: CMap<long, long&, T*, T*&> oElementMap;. I was not sure it is the "long-counterpart" of the old map definition, therefore I did several test to compare them.
The solution was finally this.
So I'm playing around with stacks and I've filled one in my main function, but now I want to pass it to my other functions so I can traverse through it. I'm not sure what kind of data type to put into the prototype though so that it accepts it. Suggestions? Here's what I have:
Main.cpp
#include <iostream>
using namespace std;
#include "stack.h"
void displayStack(char &stackRef);
int main()
{
Stack<char> stack;
stack.push('a');
stack.push('b');
stack.push('c');
return 0;
};
void displayStack(char starRef)
{
// Cannot Get here - Errors!
};
It's telling me I have too many arguments and it doesn't match argument list.
This should suffice:
void displayStack(const Stack<char>& stack);
The name DisplayStack indicates that the function only displays the stack, not changing it in any way. So then the argument can be a reference to const. However, the suffix Stack in the name is redundant since it is implied by the argument, so I’d do it like this:
#include <iostream>
using namespace std;
#include "stack.h"
typedef Stack< char > CharStack;
void display( CharStack const& stack )
{
// ... Display the stack
}
int main()
{
CharStack stack;
for( auto const ch : { 'a', 'b', 'c' } )
{
stack.push( ch );
}
display( stack );
}
Note that …
The function has been moved above main. No silly pure declaration required then, less work. DRY: Don't Repeat Yourself.
Incorrect semicolons after the function definitions, have been removed. Well, at least I think they’re incorrect. Whether they are or not, they’re totally superfluous.
Superfluous return 0; in main has been removed, because that is the default. However, some programmers prefer to have it explicit.
On the downside, while the C++11 loop compiles nicely with g++ 4.7.2, it causes an Internal Compiler Error (ICE) with Visual C++ 11.0:
[d:\dev\test]
> cl foo.cpp
foo.cpp
foo.cpp(7) : warning C4100: 'stack' : unreferenced formal parameter
foo.cpp(16) : error C2059: syntax error : '{'
foo.cpp(16) : error C2143: syntax error : missing ';' before '}'
c1xx : fatal error C1063: INTERNAL COMPILER ERROR
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
[d:\dev\test]
> _
Oh well.
Do that your way. ;-)
Compiler bug reported to Microsoft.
If you do not want to modify contents of the stack inside the function:
void displayStack(const Stack<char> &starRef)
If you want to modify the contents of the stack inside the function:
void displayStack(Stack<char> &starRef)
Points to note:
The type of the variable being passed must be the type you mention in function prototype.
In C/C++, by default all arguments to function are passed by copy, i.e: A copy of the argument rather than the argument itself is passed to the function. The overhead is the copy. You pass by reference to avoid overhead of a copy of variable being passed.
You use const qualifier on the argument if you want the passed variable to be immutable in the function.
Change your displayStack function to:
void displayStack(Stack<char> &stackRef)
I'm playing around with implementing functional-style stuff in C++. At the moment, I'm looking at a continuation-passing style for enumerating files.
I've got some code that looks like this:
namespace directory
{
void find_files(
std::wstring &path,
std::function<void (std::wstring)> process)
{
boost::filesystem::directory_iterator begin(path);
boost::filesystem::directory_iterator end;
std::for_each(begin, end, process);
}
}
Then I'm calling it like this:
directory::find_files(source_root, display_file_details(std::wcout));
...where display_file_details is defined like this:
std::function<void (std::wstring)>
display_file_details(std::wostream out)
{
return [&out] (std::wstring path) { out << path << std::endl; };
}
The plan is to pass a continuation to find_files, but to be able to pass composed functions into it.
But I get the error:
error C2248: 'std::basic_ios<_Elem,_Traits>::basic_ios' :
cannot access private member declared in
class 'std::basic_ios<_Elem,_Traits>'
What am I doing wrong? Am I insane for trying this?
Note: my functional terminology (higher-order, continuations, etc.) is probably wrong. Feel free to correct me.
In display_file_details, you need to take your wostream by reference. iostream copy constructors are private.
Upon looking more deeply into the compiler output, I found this:
This diagnostic occurred in the compiler generated function
'std::basic_ostream<_Elem,_Traits>::
basic_ostream(const std::basic_ostream<_Elem,_Traits> &)'
It turns out that basic_ostream doesn't have an available copy constructor.
Changing std::wostream out to std::wostream & out fixes it. At least to the point that I get a bunch of other errors. These were easily fixed by:
std::for_each(begin, end,
[&process] (boost::filesystem::directory_entry d)
{ process(d.path().wstring()); });