www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - In need of advice on directory naming scheme

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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
parent reply "Anton Sekeris" <no.spam inter.nl.net> writes:
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
next sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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
Apr 25 2005
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
 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
parent "A.J. Sekeris" <no.spam inter.nl.net> writes:
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 :-)
May 17 2005