How can I recognize the dest Op and the Src Op in a MachineInstr?
the MachineOperand.h provides two function [isDef] and [isUse] ?
can I use these function to recognize the destOp and SrcOp ?
Related
I'm working on code that involves loading a file from a path which is constructed as a concatenation of a given "base" path and a secondary relative path, loaded from another file. For example (and where I'm running into an issue), the base path is "assets/models/", and the secondary path is "maps\map.png".
Straight concatenation of these two strings gives "assets/models/maps\map.png". When running on POSIX systems this fails to load. Up to now I've been sorting this out by just replacing the backslashes with forward slashes with
std::replace( path.begin(), path.end(), '\\', '/' );
but I'd like to use C++17's std::filesystem::path to do this instead.
The description of std::filesystem::path::make_preferred() suggests that it should replace the separators:
"Converts all directory separators in the generic-format view of the path to the preferred directory separator.
For example, on Windows, where \ is the preferred separator, the path foo/bar will be converted to foo\bar"
When implemented in the code, however, it doesn't convert anything. I've also verified that std::filesystem::path::preferred_separator is as expected - '/'.
Am I misunderstanding the purpose of make_preferred()? Or am I just using it wrong?
Here's a cut down version of the code that doesn't work (this isn't the implemented code, but is close enough to it):
const char * loadedPath = "maps\\map.png"
std::string loadedPathStr = std::string( loadedPath );
auto wPath = std::filesystem::path( loadedPathStr );
wPath = wPath.make_preferred();
basePath = std::filesystem::path( "./a/b/" );
auto totalPath = basePath / wPath;
auto wStr = totalPath.generic_string();
std::cout << wStr << std::endl;
This outputs "./a/b/maps\\map.png"
When debugging the implemented code, it looks like wPath is optimised out; there's no way of inspecting it.
Strangely, when I compile and run this standalone test program, it works as expected:
int main(){
assert( std::filesystem::path::preferred_separator == '/' );
const char * cPath = "maps\\map.png";
std::string path = std::string( cPath );
auto wPath = std::filesystem::path( path );
wPath = wPath.make_preferred();
std::string wStr = wPath.generic_string();
std::cout << wStr << std::endl;
}
This outputs "maps/map.png". I can't read. This also outputs the incorrect value.
Anyone know whats going on here?
EDIT:
Tried compiling with clang (using gcc before), and it works as expected (separator is converted). Ignore this, made a mistake in recompiling.
I'm running this on Linux, and the path exists.
Am I misunderstanding the purpose of make_preferred()?
Not entirely, but subtly yes. A directory separator (in the generic format) is either the preferred separator, or the fallback separator: /. On systems where the preferred separator is / (e.g. POSIX), directory separator is only /. On such systems make_preferred doesn't modify the path, which explains why it would be optimised out completely.
The simplest way to replace back slashes with forward slashes is std::replace. However, do note that back slashes are valid characters in file names in POSIX, so such conversion may break the use of file names that use it.
If you want to write cross-platform code with filesystem, you should try to stick with the generic format. The behavior of all other formats of filesystem strings is implementation-dependent.
An implementation that allows alternative directory separators will treat them as directory separators. But other, perfectly valid, implementations that don't recognize those separators will not recognize them. "/" is always a directory separator; whether "\" is a separator or not depends on the implementation.
make_preferred converts from the implementation's path format into the generic format. As such, it's behavior is implementation-dependent.
The main reason behind dealing in non-generic formats is when you're getting path strings from the native OS API. Such path strings will likely be in the implementation's format, so path needs to be able to recognize them and work with them. For string literals built into your program, you should always prefer the generic format (unless your application is OS-specific, or you are selecting different strings based on the OS your code is being used on).
i try to find out way to get exe file name of the application using cross platform POCO c++ lib .
tryed with :
char* FileName ;
FileName = const_cast<char*>(Application::name());
but all i get in the FileName char * is "Application"
what do i do wrong here ?
The documentation says:
application.name: the file name of the application executable
And there's a name() method:
https://github.com/pocoproject/poco/blob/develop/Util/src/Application.cpp#L179 :
const char* Application::name() const
{
return "Application";
}
Which I find a bit confusing. However, the docs are right:
The right way to deal with this is getting the config (Application::config()) and retrieving the data from therein.
Still, πάντα ῥεῖ's comment on your original question is right: No need to use a "portable" library for something that comes with the language. The main function's argv[0] is defined to contain the executable name.
I'm using v1.6.2 of the jsoncpp library on a Win32 platform. All's well, I'm able to parse json and access Json:Values successfully using v.["firstname"] etc.
Q: How do I find a Json:Value by name in a json structure? In the documentation I've found:
Value const * Json::Value::find ( char const *key,char const *end ) const
but it doesn't specify what 'end' is. I've tried "", but it's not returning anything I can use.
Should I even be trying to find things this way?
I'm finding the documentation pretty sparse, so some jsoncpp program examples would be very helpful.
Thanks
To search for a key in a json structure, you can use std::find:
if (std::find(v.begin(), v.end(),"key") != v.end())
printf("Found it!\n");
v is your Json:Value objetct
Or, another solution without STL:
if (root.isMember("key"))
printf("Found it!\n");
I am having an odd issue when using the file_size method from the boost library. If the path that I try to dereference using a directory iterator is not the current path where the executable is, then I get a value of 0 for any file sizes I try to return. So if my path variable is instantiated to "." for the current folder it will return byte sizes no problem but if I go one folder up or a path anywhere on the C drive the byte size of files is not returned. Is this an issue with scope or is there something I'm missing?
Turns out that if you are using a directory_iterator and are trying to find the file_size( dirIter->path() ) it will only work for the current folder the executable is in. However, if you concatenate the path of the directory you are searching using the variable name you assigned (for instance path p = "." ) it will return byte sizes for any file in any folder searched (an example of how to make it work would be file_size( p / dirIter->path() ) where the / is the overloaded concatenation operator in the boost library).
I am using the CvANN_MLP functions from the machine learning libraries in OpenCV, and I want to write my trained network to a file. I have been able to do this fine with cv::FileStorage for keypoints and descriptors when using SIFT, but when I try to do it here it does not work.
The header for the machine learning uses CvFileStorage throughout, but I cannot declare this object without getting a "CvFileStorage fs has initializer but incomplete type" error, and passing in a cv::FileStorage is no help at all.
I figured maybe this is because I don't have the most recent build of OpenCV, but I checked in the SVN repository, and it still has CvFileStorage in its prototypes.
Solution written by Will, originally posted as part of their question.
Hidden in the cv::FileStorage class is the following:
// returns the underlying CvFileStorage*
CvFileStorage* operator *() { return fs; }
const CvFileStorage* operator *() const { return fs; }