c++.stlsoft - In need of advice on directory naming scheme
- Matthew (54/54) Apr 21 2005 Some of the STLSoft functionality is a shim-aware wrapper over
- Anton Sekeris (12/83) Apr 25 2005 Most in line with the goings on in the C++ world I think would be:
- Matthew (6/93) Apr 25 2005 Hey, that's a nice idea! Thanks. :-)
- Matthew (2/31) May 17 2005 I've settled on stlsoft/std/cstring.hpp, stlsoft/std/cstdlib.hpp, stlsof...
- A.J. Sekeris (2/40) May 17 2005 any time :-)
Some of the STLSoft functionality is a shim-aware wrapper over
standard C functions.
For example, <stlsoft/stdlib.hpp> includes the following functions
template <ss_typename_param_k S>
inline int atoi(S const &s)
{
return ::atoi(stlsoft_ns_qual(c_str_ptr)(s));
}
template <ss_typename_param_k S>
inline long strtol(S const &s, char **endptr, int radix)
{
return ::strtol(stlsoft_ns_qual(c_str_ptr)(s), endptr,
radix);
}
template <ss_typename_param_k S>
inline double strtod(S const &s, char **endptr)
{
return ::strtod(stlsoft_ns_qual(c_str_ptr)(s), endptr);
}
template <ss_typename_param_k S>
inline int system(S const &s)
{
return ::system(stlsoft_ns_qual(c_str_ptr)(s));
}
These are then useful with _any_ type for which a c_str_ptr() is
defined, irrespective of whether it's std::string,
stlsoft::string_view, char const*, HWND, etc.
However, I've been expanding this to include other standard files,
e.g. stlsoft/string.hpp for string.h. However, it's dawned on me
that the _location_ of the file, i.e. directly in the stlsoft
subdirectory, is inappropriate, because I want to have a header
string.hpp for all string-related things. Obviously this clashes
with string.hpp for string.h
I'm thinking the location should be one of the following, and I'd
like some opinions on the matter:
stlsoft/c/string.hpp
stlsoft/stdc/string.hpp
stlsoft/std/c/string.hpp
c/string.hpp - no stlsoft. I think this is too
dangerous/presumptuous
It's conceivable, but less likely, that I might want to do the same
for C++ files, and so we'd also need to consider naming conventions
along the lines of
stlsoft/c++/string.hpp
stlsoft/cpp/string.hpp
stlsoft/stdcpp/string.hpp
stlsoft/std/cpp/string.hpp
stlsoft/std/c++/string.hpp
c++/string.hpp - no stlsoft. I think this is too
dangerous/presumptuous
I'd like to know what you think of these suggestions, and whether
you have any other/better suggestions.
Cheers
Matthew
Apr 21 2005
Matthew wrote:
Some of the STLSoft functionality is a shim-aware wrapper over
standard C functions.
For example, <stlsoft/stdlib.hpp> includes the following functions
template <ss_typename_param_k S>
inline int atoi(S const &s)
{
return ::atoi(stlsoft_ns_qual(c_str_ptr)(s));
}
template <ss_typename_param_k S>
inline long strtol(S const &s, char **endptr, int radix)
{
return ::strtol(stlsoft_ns_qual(c_str_ptr)(s), endptr,
radix);
}
template <ss_typename_param_k S>
inline double strtod(S const &s, char **endptr)
{
return ::strtod(stlsoft_ns_qual(c_str_ptr)(s), endptr);
}
template <ss_typename_param_k S>
inline int system(S const &s)
{
return ::system(stlsoft_ns_qual(c_str_ptr)(s));
}
These are then useful with any type for which a c_str_ptr() is
defined, irrespective of whether it's std::string,
stlsoft::string_view, char const*, HWND, etc.
However, I've been expanding this to include other standard files,
e.g. stlsoft/string.hpp for string.h. However, it's dawned on me
that the location of the file, i.e. directly in the stlsoft
subdirectory, is inappropriate, because I want to have a header
string.hpp for all string-related things. Obviously this clashes
with string.hpp for string.h
I'm thinking the location should be one of the following, and I'd
like some opinions on the matter:
stlsoft/c/string.hpp
stlsoft/stdc/string.hpp
stlsoft/std/c/string.hpp
c/string.hpp - no stlsoft. I think this is too
dangerous/presumptuous
It's conceivable, but less likely, that I might want to do the same
for C++ files, and so we'd also need to consider naming conventions
along the lines of
stlsoft/c++/string.hpp
stlsoft/cpp/string.hpp
stlsoft/stdcpp/string.hpp
stlsoft/std/cpp/string.hpp
stlsoft/std/c++/string.hpp
c++/string.hpp - no stlsoft. I think this is too
dangerous/presumptuous
I'd like to know what you think of these suggestions, and whether
you have any other/better suggestions.
Cheers
Matthew
Most in line with the goings on in the C++ world I think would be:
stlsoft/cstring.hpp
An added advantage is that you don't have to add an extra level of
directory indirection (for us lazy typers out there).
For C++ that would evolve to:
stlsoft/cppstring.hpp
At any rate I would suggest not using ++ in any pathnames prefereably.
I have a feeling that sooner on later on some platform that will cause
you grief.
Kind regards,
Anton Sekeris.
Apr 25 2005
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> "Anton Sekeris" <no.spam inter.nl.net> wrote in message news:d4jiso$2l9v$1 digitaldaemon.com...Matthew wrote:Hey, that's a nice idea! Thanks. :-)Some of the STLSoft functionality is a shim-aware wrapper over standard C functions. For example, <stlsoft/stdlib.hpp> includes the following functions template <ss_typename_param_k S> inline int atoi(S const &s) { return ::atoi(stlsoft_ns_qual(c_str_ptr)(s)); } template <ss_typename_param_k S> inline long strtol(S const &s, char **endptr, int radix) { return ::strtol(stlsoft_ns_qual(c_str_ptr)(s), endptr, radix); } template <ss_typename_param_k S> inline double strtod(S const &s, char **endptr) { return ::strtod(stlsoft_ns_qual(c_str_ptr)(s), endptr); } template <ss_typename_param_k S> inline int system(S const &s) { return ::system(stlsoft_ns_qual(c_str_ptr)(s)); } These are then useful with any type for which a c_str_ptr() is defined, irrespective of whether it's std::string, stlsoft::string_view, char const*, HWND, etc. However, I've been expanding this to include other standard files, e.g. stlsoft/string.hpp for string.h. However, it's dawned on me that the location of the file, i.e. directly in the stlsoft subdirectory, is inappropriate, because I want to have a header string.hpp for all string-related things. Obviously this clashes with string.hpp for string.h I'm thinking the location should be one of the following, and I'd like some opinions on the matter: stlsoft/c/string.hpp stlsoft/stdc/string.hpp stlsoft/std/c/string.hpp c/string.hpp - no stlsoft. I think this is too dangerous/presumptuous It's conceivable, but less likely, that I might want to do the same for C++ files, and so we'd also need to consider naming conventions along the lines of stlsoft/c++/string.hpp stlsoft/cpp/string.hpp stlsoft/stdcpp/string.hpp stlsoft/std/cpp/string.hpp stlsoft/std/c++/string.hpp c++/string.hpp - no stlsoft. I think this is too dangerous/presumptuous I'd like to know what you think of these suggestions, and whether you have any other/better suggestions. Cheers MatthewMost in line with the goings on in the C++ world I think would be: stlsoft/cstring.hppAn added advantage is that you don't have to add an extra level of directory indirection (for us lazy typers out there). For C++ that would evolve to: stlsoft/cppstring.hpp At any rate I would suggest not using ++ in any pathnames prefereably. I have a feeling that sooner on later on some platform that will cause you grief.Yes, I share the same reservations there. Cheers Matthew
Apr 25 2005
I've settled on stlsoft/std/cstring.hpp, stlsoft/std/cstdlib.hpp, stlsoft/std/string.hpp, etc. Thanks for the inspiration. :-)It's conceivable, but less likely, that I might want to do the same for C++ files, and so we'd also need to consider naming conventions along the lines of stlsoft/c++/string.hpp stlsoft/cpp/string.hpp stlsoft/stdcpp/string.hpp stlsoft/std/cpp/string.hpp stlsoft/std/c++/string.hpp c++/string.hpp - no stlsoft. I think this is too dangerous/presumptuous I'd like to know what you think of these suggestions, and whether you have any other/better suggestions. Cheers MatthewMost in line with the goings on in the C++ world I think would be: stlsoft/cstring.hpp An added advantage is that you don't have to add an extra level of directory indirection (for us lazy typers out there). For C++ that would evolve to: stlsoft/cppstring.hpp At any rate I would suggest not using ++ in any pathnames prefereably. I have a feeling that sooner on later on some platform that will cause you grief. Kind regards, Anton Sekeris.
May 17 2005
Matthew wrote:any time :-)I've settled on stlsoft/std/cstring.hpp, stlsoft/std/cstdlib.hpp, stlsoft/std/string.hpp, etc. Thanks for the inspiration. :-)It's conceivable, but less likely, that I might want to do the same for C++ files, and so we'd also need to consider naming conventions along the lines of stlsoft/c++/string.hpp stlsoft/cpp/string.hpp stlsoft/stdcpp/string.hpp stlsoft/std/cpp/string.hpp stlsoft/std/c++/string.hpp c++/string.hpp - no stlsoft. I think this is too dangerous/presumptuous I'd like to know what you think of these suggestions, and whether you have any other/better suggestions. Cheers MatthewMost in line with the goings on in the C++ world I think would be: stlsoft/cstring.hpp An added advantage is that you don't have to add an extra level of directory indirection (for us lazy typers out there). For C++ that would evolve to: stlsoft/cppstring.hpp At any rate I would suggest not using ++ in any pathnames prefereably. I have a feeling that sooner on later on some platform that will cause you grief. Kind regards, Anton Sekeris.
May 17 2005