I am using OpenCV 2.3.1. My language is C++.
cv::imwrite works fine if I hard code the name of the output file like this.
cv::imwrite("/home/peter/BlendedInterpolatedPlane.jpg", srcnorm);
However, I get a run time error when I try to pass the output file name as a string like this.
cv::imwrite(outputFileName.c_str(), srcnorm);
or like this
cv::imwrite(outputFileName, srcnorm);
although there is no compiler error.
outputFileName is declared as std::string and contains the output file name.
The stack trace is as follows.
org.netbeans.modules.viewmodel.TreeModelNode#1999add[Name=, displayName=__kernel_vsyscall()]
org.netbeans.modules.viewmodel.TreeModelNode#186304c[Name=, displayName=raise()]
org.netbeans.modules.viewmodel.TreeModelNode#cce801[Name=, displayName=abort()]
org.netbeans.modules.viewmodel.TreeModelNode#93b1a8[Name=, displayName=__gnu_cxx::__verbose_terminate_handler()()]
org.netbeans.modules.viewmodel.TreeModelNode#749412[Name=, displayName=Address: [#0x00554fa5]]
org.netbeans.modules.viewmodel.TreeModelNode#1a52b00[Name=, displayName=std::terminate()()]
org.netbeans.modules.viewmodel.TreeModelNode#aa277d[Name=, displayName=__cxa_throw()]
org.netbeans.modules.viewmodel.TreeModelNode#106904c[Name=, displayName=cv::error(cv::Exception const&)()]
org.netbeans.modules.viewmodel.TreeModelNode#1eb6f21[Name=, displayName=cv::imwrite_(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, cv::Mat const&, std::vector<int, std::allocator<int> > const&, bool)()]
org.netbeans.modules.viewmodel.TreeModelNode#1ccf1f3[Name=, displayName=cv::imwrite(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, cv::_InputArray const&, std::vector<int, std::allocator<int> > const&)()]
org.netbeans.modules.viewmodel.TreeModelNode#20a41d[Name=, displayName=main(argc=9,argv=0xbffff564) at main.cpp:259]
Any assistance would be greatly appreciated,
Peter
I found the problem. The output file name had an invalid suffix. Once I fixed that problem, it worked with
cv::imwrite(outputFileName, srcnorm);
where outputFileName is of type std::string.
Related
I have a Boost.python .cpp that looks like this
BOOST_PYTHON_MODULE(my_module)
{
class_<MyCustomClass>("MyCustomClass")
.def("getDict",
&MyCustomClass::getDict, // This returns std::map<std::string, std::string>
bp::return_value_policy<bp::return_by_value>()
;
}
When I try to call MyCustomClass().getDict(), I get this error:
TypeError: No to_python (by-value) converter found for C++ type: std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >
It looks like Boost doesn't attempt to make this mapping for you by default. How do you let Boost know that it's okay to make that conversion?
At the moment I'm getting around the issue by having MyCustomClass::getDict return a boost::python::dict but, because this API is meant to be used by both C++ and Python users, it'd be much preferred to return the native std::map<std::string, std::string> for the C++ API and do a proper convert in the Python bindings.
I tried adding .def(map_indexing_suite<std::map<std::string, std::string> >()) to the class_ definition but it had no effect. I still get the same TypeError, as shown above.
I am trying to follow the answer to my previous question and use boost::locale::conv::between to get a UTF-8 string from vector<char> containing UTF-16 data. My code is pretty much as in the answer (with some differences in how I get the char *:
char in[length + 1];
//... populate in with my source data
in[length] = '\0';
std::string out = boost::locale::conv::between((const char*)in, std::string("UTF-8"), std::string("UTF-16"));
This compiles fine, but during linking I get error
In function `boost::locale::conv::between(char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::locale::conv::method_type)':
/usr/local/include/boost/locale/encoding.hpp:186: undefined reference to `boost::locale::conv::between(char const*, char const*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, boost::locale::conv::method_type)'
This doesn't look right to me. On possibility I could think of is that I had boost 1.50 installed, so I installed latest 1.55 release - yet I get the same error.
Boost locale is not a header-only library, it has an actual library that you need to link with.
Adding following flag to LDFLAGS helps:
-lboost_locale
I have encountered the same problem. I think you should use the dynamic library instead of the static library.
I have a project I am working on where I have some strange behavior with the std maps.
I had my own typedef map defined which mapped strings to a pointer of a custom type. The application crashed anytime that I excess the map after I add the first pair to the map.
After a lot of messing around I changed the map to a and moved it to the first call in my application and it still crashes. I have no idea what could be going on. Any help would be appreciated.
Here is the code that crashes at the moment.
LoggerPtr syslogger(Logger::getLogger("CISInterface"));
int main(int argc, char *argv[])
{
typedef std::map<string, string> MyMapDef;
MyMapDef tmpString;
tmpString.insert(MyMapDef::value_type("0000", "d"));
tmpString.insert(MyMapDef::value_type("1111", "d")); //Crashes here.
tmpString.insert(MyMapDef::value_type("2222", "d"));
// std::string configFile;
// int c;
// if(argc < 2)
// {
// //Must have c option
// std::cout << "Usage -c configFileName" << std::endl;
// exit(EXIT_FAILURE);
// }
//Rest of main commented out.
...
And here is the stack trace -
CISInterface Debug [C/C++ Application]
gdb/mi (10/31/12 6:02 PM) (Suspended)
Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.)
6 std::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const() 0x00000032fd49c416
5 std::operator< <char, std::char_traits<char>, std::allocator<char> >() basic_string.h:2317 0x0000000000417ec7
4 std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::operator() stl_function.h:230 0x000000000041706f
3 std::_Rb_tree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_M_insert_unique() stl_tree.h:1170 0x0000000000415d00
2 std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::insert() stl_map.h:500 0x00000000004150eb
1 main() CISInterface.cpp:29 0x000000000041916d
gdb (10/31/12 6:02 PM)
/home/cillian/workspace/CISInterface/Debug/CISInterface (10/31/12 6:02 PM)
What other areas should I be looking at that could be causing problems. Could it be in the libraries that I'm linking with? I have created a second project with just these lines of code that links with the same libraries (but doesn't have any code that calls into them.) and it doesn't crash.
Problem solved.
Thought I'd add it here on the off chance anyone else ever does the same thing.
I slowly removed files in my project to try and find the offending file. I was thinking that it must be something defined in a header file that was causing issues (like a static). It took a long time but I think I've found it. I had a header file that defines a number of structs. These are serialized to the wire so I had them 1 byte aligned using #pragma pack (push) which I put at the top of the file and #pragma pack (pop) at the bottom. But I then added a couple of #include statements after the first #pragma definition meaning that these includes were aligned incorrectly and caused some nondeterministic behavior. Thanks everyone that had a look. Should probably use the attribute syntax and I wouldn't had the problem. Offending code is below for completeness.
#pragma pack (push)
#pragma pack (1)
#include <string> //Wrong place for includes!
#include <Units.h>
typedef struct
{
....
}
#pragma pack (pop)
Thanks to everyone who had a look at initial problem.
NetBeans interpret weird my code. In main function I have code:
SequenceAlignment align;
align.Alignment( local, seqs, argv[4], matrix)
But NetBeans show:
cpp:91: undefined reference to `SequenceAlignment::Alignment(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, char*, ScoreMatrix&)'
To be honest I do not know what to think. It works before, but now suddenly it doesn't.
This is a linker error indicating that the linker can't find an implementation for SequenceAlignment::Alignment. Check to see that you indeed have an implementation of this function and that the code containing that implementation is indeed being compiled and linked.
In my development environment, I'm compiling a code base using GNU C++ 3.4.6. Code is under development, and unfortunately crashes now and then. It's nice to be able to run the traceback through a demangler, and I use c++filt 3.4. The problem comes when functions have a number of STL parameters. Consider
My_callback::operator()(
Status&,
std::set<std::string> const&,
std::vector<My_parameter*> const&,
My_attribute_set const&,
std::vector<My_parameter_base*> const&,
std::vector<My_parameter> const&,
std::set<std::string> const&
)
{
// ...
}
When this function is in the traceback, the mangled output on my platform is:
(_ZN30My_callbackclER11StatusRKSt3setISsSt4lessISsESaISsEERKSt6vectorIP13My_parameterSaISB_EERK17My_attribute_setRKS9_IP18My_parameter_baseSaISK_EERKS9_ISA_SaISA_EES8_+0x76a) [0x13ffdaa]
c++filt kindly demangles it to
(My_callback::operator()(Status&, std::set<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::vector<My_parameter*, std::allocator<My_parameter*> > const&, My_attribute_set const&, std::vector<My_parameter_base*, std::allocator<My_parameter_base*> > const&, std::vector<My_parameter, std::allocator<My_parameter> > const&, std::set<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)+0x76a) [0x13ffdaa]
This is the same problem as compiler errors encountered when using templates. However, the STL is a fairly regular and recognizable package of templates. So what I'm hoping is that someone out there has created an enhanced version of c++filt which would dump something closer to the original function signature. Any hints?
STLFilt simplifies and/or reformats long-winded C++ error and warning messages, with a focus on STL-related diagnostics. The result renders many of even the most cryptic diagnostics comprehensible.