-
-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return std::string / C++ implementation #9
Comments
See the I don't believe it makes it easier or less error-prone though. |
Well I'd make it a lot simpler: Just Easier because: 1 simple call to |
This is just your opinion.
I don't understand why you're mentioning
There are many situations where people want to have control of memory allocations and are willing to do so. They won't make mistakes. |
If you're thinking about the standard not mandating |
Yes, therefore the "IMO". Reasoning would be that there are many libraries that can do path handling already (boost, C++17, ...) so I would not include it in a library whose purpose is getting the executable path. Of course it might be convenient for users not wanting to use an extra library, no question there.
Yes: Line 94 in 7896790
and yes I also agree that the STL implementations all use contiguous storage. But I heard, that some may have used linked lists, extra copy on access, shared pointers etc. and there is lots of discussion on whether using &std::string[0] is safe (prior C++11) so I wanted to mention it. Just "what-if" someone comes along an old, proprietary library that tried to be very clever?
Ok, explicit memory control is a good reason. But often you don't need that, that's why I was suggesting the C++ interface. Did not see the wip branch, so thanks for pointing that out. |
The C++17 filesystem library is well, available from C++17 only. And AFAIK it comes from Boost which is seen as overly bloated and over-engineered by a non negligible fraction of C++ developers. Given that, it was a little effort to add a way to report the dirname part of the executable or module path.
Well, maybe such an STL exists in the wild. I've never seen one in production so far. Hence the choice. I started the |
The current implementation works with raw pointers. How about porting this to C++ returning a std::string instead (at least as a wrapper) for easier and less error-prone usage?
The text was updated successfully, but these errors were encountered: