Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
April 22, 2005 In need of advice on directory naming scheme | ||||
---|---|---|---|---|
| ||||
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 |
April 25, 2005 Re: In need of advice on directory naming scheme | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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.
|
April 25, 2005 Re: In need of advice on directory naming scheme | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anton Sekeris | "Anton Sekeris" <no.spam@inter.nl.net> wrote in message news:d4jiso$2l9v$1@digitaldaemon.com... > 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 Hey, that's a nice idea! Thanks. :-) > 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. Yes, I share the same reservations there. Cheers Matthew |
May 17, 2005 Re: In need of advice on directory naming scheme | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anton Sekeris | >> 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.
I've settled on stlsoft/std/cstring.hpp, stlsoft/std/cstdlib.hpp, stlsoft/std/string.hpp, etc.
Thanks for the inspiration. :-)
|
May 17, 2005 Re: In need of advice on directory naming scheme | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | Matthew wrote:
> >> 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.
>
> I've settled on stlsoft/std/cstring.hpp, stlsoft/std/cstdlib.hpp, stlsoft/std/string.hpp, etc.
>
> Thanks for the inspiration. :-)
any time :-)
|
Copyright © 1999-2021 by the D Language Foundation