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

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.

"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

>> 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. :-)

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 :-)