This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Standard header format.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 06 June 2004 02:18, Gabriel Dos Reis wrote:
> "Steven T. Hatton" <hattons@globalsymmetry.com> writes:
> | There are many C++ programmers who have suggested to me the best way
> | to learn what the standard headers probide is to look a them.
>
> That definitely is not the best way. It is one of the worst way.
If there are actually header files in the traditional sense that look like
this:
//http://www.itga.com.au/~gnb/wp/cd2/lib-strings.html
//http://www.itga.com.au/~gnb/wp/cd2/
struct
char_traits<char>
namespace std {
template<>
struct char_traits<char> {
typedef char char_type;
typedef int int_type;
typedef streamoff off_type;
typedef streampos pos_type;
typedef mbstate_t state_type;
static void assign(char_type& c1, const char_type& c2);
static bool eq(const char_type& c1, const char_type& c2);
static bool lt(const char_type& c1, const char_type& c2);
static int compare(const char_type* s1, const char_type* s2, size_t n);
static size_t length(const char_type* s);
static const char_type* find(const char_type* s, int n,
const char_type& a);
static char_type* move(char_type* s1, const char_type* s2, size_t n);
static char_type* copy(char_type* s1, const char_type* s2, size_t n);
static char_type* assign(char_type* s, size_t n, char_type a);
static int_type not_eof(const int_type& c);
static char_type to_char_type(const int_type& c);
static int_type to_int_type(const char_type& c);
static bool eq_int_type(const int_type& c1, const int_type& c2);
static state_type get_state(pos_type pos);
static int_type eof();
};
}
for example, then looking at the "standard headers" would be a worthwhile
means of determining what is provided by the Standard Library. I believe the
people who have suggested looking at the Standard Headers were expecting me
to find them in the form presented above. I am not saying they /should/
expect that. I'm saying they /do/ expect that.
> And note that he used that term in very specific contexts. He did not
> mean it to apply automatically to broader contexts, specifically when
> it comes to how C++ implementations done. And, reading carefully
> chapter §24 reveals that he left room for broader meaning of that word
> and he did not mean people pick the narrowest meaning and use it in
> wider contexts.
It seems to me the model he presents in §24.4 he presents exactly the kind of
approach I am suggesting.
> | It's not the
> | best overall definition of 'interface' possible, but it seemed the most
> | appropriate.
>
> No, a meaning that includes non-delarations is more appropriate.
>
> [...]
My preference is to resort the the Latin for a proper understanding of what
word means.
Inter- \In"ter-\ [L. inter, prep., among, between, a compar.
form of in in; akin to intra, intro, within, Skr. antar
between, in, and E. in. See In, and cf. Entrails,
Interior, Enter-, Exterior.]
A prefix signifying among, between, amid; as, interact,
interarticular, intermit.
Face \Face\, n. [F., from L. facies form, shape, face, perh.
from facere to make (see Fact); or perh. orig. meaning
appearance, and from a root meaning to shine, and akin to E.
fancy. Cf. Facetious.]
1. The exterior form or appearance of anything; that part
which presents itself to the view; especially, the front
or upper part or surface; that which particularly offers
itself to the view of a spectator.
> | My objective is to establish a means of increasing the usability of
> | libstdc++ by providing a more comprehensive IDE than currently exists (to
> | my knowledge).
>
> I support the abstract goal; but as I repeatedly told you, you're in a
> dead end. V3 won't expose to user any implementation details about
> where internal files get installed.
Access to the internal files is exactly what I _don't_ want. I want X in
Stroustrup's example. All I have now is X_impl.
> User has no business in that.
> If you want integration with an IDE, work with the compiler. It knows
> better than V3.
Perhaps that is an approach. I believe the reason you have not been
understanding what I've been presenting is that I am working from a different
paradigm. When I understand as 'interface' as presented in Stroustrup's
examples using header files is something that the user can access to 'see'
the form of the declarations contained therein. IOW, I can cat or grep a
header file containing a representation of user interface to see all the
signatures it provides. You seem to only view an interface as something I
can access assuming I already have a description from some other source.
- --
Regards,
Steven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQFAwuEFwX61+IL0QsMRAp2/AJ4vBVKzF6UqqXifFwsCAUAnaBNLvgCfev9L
UYzF9ODdTDVh8O7ajEs8l1U=
=ZAf3
-----END PGP SIGNATURE-----