Fergus Henderson wrote in message <76t4iu$3bu$1@mulga.cs.mu.OZ.AU>...
    [snip]
>>After thinking it over, I disagree with your opinion.  C style strings
>>can be required by the language because all operating systems capable
>>of hosting a "hosted environment" can express file names as sequences
>>of C style chars.  There is no requirement that either C or C++ modify
>>the string in any way, merely hand it off to the operating system
    [snip]
>What about operating systems where the system calls require file names
>to be represented as say fixed-length space-padded byte arrays,
    [snip]
>(I don't know if there are actually any such OSs, but there may well be.)

Good point, and, to reinforce it: there have been such systems, and
they have been _extremely_ widespread: both CP/M, and DOS, were
in fact such systems (at least in releases of up to a few years ago).

Filenames had to be passed to the operating system as arrays of
exactly 11 characters, interpreted as 8+3 with an implicit dot in
between, each part space-padded if the number of "meaningful"
characters was less than 8, or 3, respectively.

I know that many CP/M conventions came from previous OSs,
so I suspect this can lead to finding other operating system using
similar approaches to naming files -- reinforcing the idea that it
is anything but a given that the C (or C++) runtime library can
avoid "modifying the filename string" before passing it on to the
OS, and yet, this was never perceived as a big problem.


>In both cases, the runtime library needs to do some preprocessing
>of the file names before handing them off to the OS, and it may
>need to reject file names which are too long.

Historically, C runtime libraries for Dos tended to silently truncate
"too-long" names, I believe, rather than rejecting them; perhaps in
imitation of the Dos commandline interpreter, which also did such
silent truncation.  Still, the point remains that quite a bit of formatting
was needed to turn a C string such as "Foo.Pe" into a Dos filename
such as "FOObbbbbPEb" (using b to represent a blank); conceptually
not very different from implicitly turning a wide-character string into
a narrow-character one, as needed to allow wchar_t for filenames
on operating systems that don't actually support that.


>>On the other hand, if all functions dealing with the names of files
>>had wide character counterparts it brings about two conditions I find
>>objectionable:
>>
>>First it implies, even if it doesn't require, that all conforming
>>applications run on platforms which provide file systems supporting
>>wide character file names.
>
>Well, that's just a matter of making the documentation for such
>functions clear.

Sorry, but I don't see that the implication holds -- if there is no
requirement, how can there be an implication?  The syntax of
allowed filenames is and remains a specific-environment issue;
that I can name a file with a wide string in no way implies that
ALL wide strings will be OK with any given environment (indeed,
it is quite reasonable to think that a given environment may only
accept a small subset of them [e.g., only those that translate
to narrow-characters] just as, today, a given environment may
only accept a small subset of strings as acceptable filenames
[e.g., only those that contain no colons, question marks, stars...]).



>>And that leaves out the fact that one could compile an application
>>which would run on NT but break on Win95/98, in your particular case.
>
>This is already possible (e.g. using the system() function).


It is also possible with fopen (or other functions/ctors taking narrow
char strings for filenames), since the syntax of allowed filenames
is somewhat wider on NT anyway; "\\\\?\\UNC\\foo\\bar" is OK
on NT but not on Win95, for example.  I don't see why such Win95
foibles should inhibit the Standard (in fact, I'm quite glad that, at
least for narrow-character string filenames, they haven't done so!).


Alex


-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
 http://www.newsfeeds.com/       The Largest Usenet Servers in the World!
-----------== Over 66,000 Groups, Plus  a  Dedicated  Binaries Server ==----------


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <772qpj$bt@sifon.cc.mcgill.ca>, Alain Magloire
<alainm@sifon.cc.mcgill.ca> writes
>You forgot the obvious, for many people posting in usenet
>english is not the native language.

and do a much better job in English than most of us native English
speakers could do in their languages.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote in message <368AF23E.B1799D00@wizard.net>...
    [snip]
>> [Note that, of course, STL has *absolutely* nothing to do with this
>> thread, which is about the C++ Standard; it WOULD be nice if
>> people just stopped using this silly 3-letter acronym, incorrectly
>> most of the time, and started talking about Standard C++ and
>> its library! ...]
>
>What does STL stand for? I thought it stood for the C++ Standard
>Template Library; i.e. that subset of the standard library which uses
>templates. wifstream is certainly in that subset.


I do not believe there is any "official" definition of "STL", because
it is a term with no "official" standing whatsoever.  Historically, it
referred to a proposal by STepanov and Lee (it's possible, of
course, that "STL" is "ST" concatenated with "L" only by sheer
coincidence), which covered the use of templates for containers,
algorithms, iterators, and functors, in ways conceptually quite
close (although different in many details) to what later ended up
in the Standard; streams and character strings, already then
in existence (not as templates), were "templatized" later (quite
independently from the "STL" functionality).  I think (but don't
know for sure) that this also applies to valarray, while facets
(again, I think) were added later.

The wide mis-application of this "STL" monicker is, IMHO, one
of the reasons to wish its use could be stamped out altogether
(given the inexplicable fascination on the human mind of three
letter acronyms, this is, of course, strictly in the "if wishes were
horses" category:-).


Alex



---== http://www.newsfeeds.com - Largest Usenet Server In The World! ==---


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matt Austern wrote in message ...
>
>"Alex Martelli" <martelli@cadlab.it> writes:
>
>> What should the C++ implementation do with my wide character
>> string emitted by wprintf, etc, if the underlying environment does not
>> support wide-character output?  Yet the C++ standard specifies
>> it must handle it.
>
>The C standard (NA1) specifies very precisely what wprintf should do,

*Exactly!*  Sorry for not making it clear enough -- what I wrote
was meant as a *rhetorical question*, arguing that the fact that
some systems don't support wide-char filenames is no good
reason for the C++ Standard not to allow such names in the
initializer (etc) for an fstream -- exactly like the fact that some
systems don't support wide-character output didn't stop C++
(and C) standards from sanctioning wprintf, etc etc.


Alex


---== http://www.newsfeeds.com - Largest Usenet Server In The World! ==---


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Alex Martelli" <alex@magenta.com> writes:

>I do not believe there is any "official" definition of "STL", because
>it is a term with no "official" standing whatsoever.  Historically, it
>referred to a proposal by STepanov and Lee (it's possible, of
>course, that "STL" is "ST" concatenated with "L" only by sheer
>coincidence), which covered the use of templates for containers,
>algorithms, iterators, and functors, in ways conceptually quite
>close (although different in many details) to what later ended up
>in the Standard; ...

The actual history is somewhat different.

Alex Stepanov and Meng Lee developed over a period of years a library
they called the "Standard Template Library", or STL for short. The
word "Standard" at that time did not refer to the C++ Standard,
but meant that it was intended as a set of standard solutions to
common programming problems. If such a thing were newly under
development today, it might be called the Template Pattern Library
instead. :-)

After the STL had undergone much development and use at Hewlett-
Packard, Stepanov and Lee (with the permission of HP, who released
it into the public domain) proposed to the C++ Committee that
it be adopted into the C++ language standard.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Alex Martelli" <alex@magenta.com> writes:

> >"Alex Martelli" <martelli@cadlab.it> writes:
> >
> >> What should the C++ implementation do with my wide character
> >> string emitted by wprintf, etc, if the underlying environment does not
> >> support wide-character output?  Yet the C++ standard specifies
> >> it must handle it.
> >
> >The C standard (NA1) specifies very precisely what wprintf should do,
>
> *Exactly!*  Sorry for not making it clear enough -- what I wrote
> was meant as a *rhetorical question*, arguing that the fact that
> some systems don't support wide-char filenames is no good
> reason for the C++ Standard not to allow such names in the
> initializer (etc) for an fstream -- exactly like the fact that some
> systems don't support wide-character output didn't stop C++
> (and C) standards from sanctioning wprintf, etc etc.

It's a very different situation, though.

The reason C specifies the behavior of wprintf is that wprintf does
*not* depend on wide-character output.  It behaves as if it converts
everything to a narrow-character sequence before performing output.
In fact, wprintf doesn't use wide-character output even if such a
thing is available.  "The external file associated with a wide-
oriented stream is a sequence of multibyte characters ... The wide-
character output functions convert wide characters to multibyte
characters and write them to the stream as if they were written by
successive calls to the fputwc function." (I'm quoting from the C
standard, Amendment 1, section 4.6.2.2.)

The designers of the C library were very careful not to rely on
behavior that's only available on a few platforms.  The C standard was
defined such that wprintf is implementable on any platform where
printf is implementable.

I'm not sure whether this is widely understood; I know that I didn't
understand it until I started reading the appropriate parts of the C
and C++ standards carefully.

So the question is: can you define what it means to open a wide-
character filename, solely in terms of narrow-character filenames?  If
so, you'd have something analogous to the situation of wprintf.  (And
perhaps something that could be considered for a future revision of
the standard.)  If not then you'd be mandating behavior that's only
meaningful on one or two specific platforms, which would be
inappropriate for a standard.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <368fedf3@news.newsfeeds.com>, Alex Martelli
<alex@magenta.com> writes
>The wide mis-application of this "STL" monicker is, IMHO, one
>of the reasons to wish its use could be stamped out altogether
>(given the inexplicable fascination on the human mind of three
>letter acronyms, this is, of course, strictly in the "if wishes were
>horses" category:-).

So what would you suggest?  You see, for some of us, STL describes a
very specific set of generic items (containers, algorithms and
iterators) that work together to achieve certain ends.  An STL container
works with an STL algorithm though the intermediacy of an STL iterator.
I know what to expect if a competent programmer states that a hash table
implementation conforms with the STL concept etc...  We need a name for
this kind of generic programming tool.



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> Alex Martelli <alex@magenta.com> writes
>>The wide mis-application of this "STL" monicker is, IMHO, one
>>of the reasons to wish its use could be stamped out altogether
>
>So what would you suggest?  You see, for some of us, STL describes a
>very specific set of generic items (containers, algorithms and
>iterators) that work together to achieve certain ends.  An STL container
>works with an STL algorithm though the intermediacy of an STL iterator.

I don't know what A.M. would suggest, but I say "Standard", or
"ISO Standard".  E.g.,

  "This is an ISO Standard-conforming Container."
  "This algorithm works with any standard Forward Iterator."

Each chapter has a specification for what conforms as a standard
component, besides providing a few examples of standard components.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.10f67762fe40f359896a1@news.concentric.net>,
  brownsta@concentric.net (Stan Brown) wrote:
> As for "STL" being misunderstood, I have to disagree with whoever
> "AllanW" might really be. I haven't made an actual count, but it seems to
> me, based on the past few months' articles posted here, that roughly the
> same number of programmers think STL does include streams or strings or
> both as know that it includes neither.

I'll concede that STL, even if it *IS* understood, is not precise.
Some things are obviously part of the STL, and some things are
obviously NOT part of the STL, but there are some ambiguous fringes.

I still maintain my overall position. Consider statements such as:

  "The STL is the least-understood section of the new standard."

Here there is no need for precision; we're talking about a group
of sections from the standard, whose boundaries do not need
precise declination. You might weakly or strongly agree or disagree
with the statement, but you probably at least know what it means.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matt Austern wrote:
>
> So the question is: can you define what it means to open a wide-
> character filename, solely in terms of narrow-character filenames?  If
> so, you'd have something analogous to the situation of wprintf.  (And
> perhaps something that could be considered for a future revision of
> the standard.)  If not then you'd be mandating behavior that's only
> meaningful on one or two specific platforms, which would be
> inappropriate for a standard.

Although I haven't studied wide character stuff yet, I assume that the
standard defines some conversion between wide and regular characters,
and that the conversion from a narrow string to a wide string and back
is lossless. In this case, wifstream(wchar_t*) could still be generally
useful, as long as the wchar_t* came from some library input routine.

On a system that handles wide characters (e.g., Win32), the input
routine would know how to input them, and wifstream(wchar_t*) would know
how to pass them back to the system call that opens the file. On a
system that doesn't handle wide characters, the input routine would do
some sort of reasonable conversion from narrow characters to wchar_t*,
and then wifstream(wchar_t*) would do the reverse conversion.

That is, the result would be perfectly well defined on a system that
didn't support wide characters, as long as the wchar_t* was generated by
conversion from a regular character string.

--

Ciao,
Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote in message
    [snip]
>So what would you suggest?  You see, for some of us, STL describes a

Personally, I just talk about the "standard" (or "ISO Standard C++", if
the context doesn't already clarify that) algorithm templates, and/or
container templates (referring to either or both is frequent; functors,
iterators, adapters, allocators, etc, for some reason I find myself
referring-to with lower frequency).

>very specific set of generic items (containers, algorithms and

Nice oxymoron (generic <-> specific) -- makes one smile (which
helps fix it in mind), yet it IS precise; I think I'll steal it for the next
time I need to teach this stuff, if you don't mind:-).

>iterators) that work together to achieve certain ends.  An STL container
>works with an STL algorithm though the intermediacy of an STL iterator.

A so-called "STL" container, such as vector<>, can perfectly well
be used independently from "STL" algorithms; the latter, in turn, are
designed to be perfectly usable on "things" that are anything BUT
"STL containers", most notably plain old builtin arrays.  The iterator
"concepts" (embodied, or "modeled", by certain template classes, but
also by built-in pointers, etc) are the "glue" for the whole scheme (I do
not think it is pure chance that it's rarer for me to have to _name_
iterators, when discussing these issues -- while containers and
algorithms have to be specifically named in code, iterators often
do their magic "transparently").

To me, "STL" names a specific (and rather brilliant) library proposed
to the Standard committee a few years ago, which, with several
important modifications (the traits idiom, and allocators, being the
first that spring to mind), was integrated in the C++ Standard.  The
vector<> I use is not the one from STL (because one of the
template parameters is an allocator, etc), although it clearly
descends from it.

At the other extreme, to some people "STL" is anything in the C++
standard library having to do with templates, as evidenced by this
subject's thread -- streams, strings, the works; basically, all of the
library, except for the C legacy and a few odds and ends such as
the standard exceptions, I guess.

Austern, in his excellent book (and I have to thank you for the
glowing review on www.accu.org -- I was doubtful about buying
it *because* it had STL in the title, but that review convinced me:-),
appears to use it to describe a family of libraries -- the original
(historical) "STL", the C++ Standard version, and the current
SGI library (not _all_ of the latter, though -- "rope" doesn't seem
to be included, for example).  That is also different from your
concept of "specific set of generics", because the specificity
is lacking.  Is hash_map<> "in the STL"?  Is slist<>?  Austern
seems to think so; those who take the "S" to mean "Standard"
probably don't, since the C++ Standard doesn't bless either.


>I know what to expect if a competent programmer states that a hash table
>implementation conforms with the STL concept etc...  We need a name for
>this kind of generic programming tool.


If we do, then "STL" is a bad choice because its meaning is
quite "fragmented" by now -- see above.  I'm sure you would
know what to expect of a competent programmer claiming that
a certain hash table design (probably more relevant than the
implementation thereof:-) "conforms with C++ Standard
generics" -- you would expect begin() and end() member
functions returning forward iterators, an allocator parameter
to the class template, insert() and operator[]() similar to those
on map/set/multimap/multiset depending on choices of
key/value split and uniqueness, etc.  Presumably, "conforming
with the STL concept" has similar, though slightly vaguer,
connotations (e.g., it is less clear that an allocator parameter
would be present).  If you take STL to name a specific,
historically well-defined library, as I do, then it may be quite
acceptable to use a phrase such as "STL concepts" to name
a bundle of idioms, patterns, styles, naming choices, and
above all IDEAS -- just as it would be to talk about "Fresco
concepts", "COM concepts", "Corba concepts", and so on.

But, what DO you expect when you hear discourse about an
"STL string" rather than a "hash table conforming with the
STL concepts"?  Is the "STL string" a misname for std::string
(and/or std::basic_string<>) by someone convinced that every
template in the Standard library is "STL"?  Is it a new container,
perhaps one "conforming with the STL concepts" differently,
or more closely, than std::basic_string<> does?  Probably the
former if the speaker is some random programmer -- perhaps
the latter, if the speaker has a conception of "STL" in terms
either historical (like me) or of "specific generics" (like you);
in general, you can't tell.


Alex



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jackklein@att.net (Jack Klein) writes:

>"Alex Martelli" <martelli@cadlab.it> wrote:
>
>> Constructing a fstream with a name string of
>> (narrow-characters), say, "+++++", is fully conforming -- it will
>> succeed if the underlying environment supports this syntax
>> for a filename (and all other conditions for opening or creating
>> this funny-named file are met), it will fail if it doesn't, and this
>> causes absolutely no problem whatsoever because the C++
>> program can and should check if the stream was correctly
>> constructed anyway.  Constructing an fstream with a name
>> string of wide characters should work in EXACTLY the same
>> way -- be accepted at compile-time, succeed or fail at run
>> time just like for any other (narrow-character) string.
>>
>> I consider it a wart in the C++ Standard Library that:
>>     -- wide-chars are not accepted "everywhere" narrow-chars
>>         are, and
>>     -- std::basic_string is not accepted "everywhere" a
>>         const char*, or const wchar_t*, is.
>> Well, maybe that's _two_ warts...
>
>After thinking it over, I disagree with your opinion.  C style strings
>can be required by the language because all operating systems capable
>of hosting a "hosted environment" can express file names as sequences
>of C style chars.  There is no requirement that either C or C++ modify
>the string in any way, merely hand it off to the operating system
>which determines whether it represents the name of a file which is
>valid for the requested operation (permissions, read/write attributes,
>etc.).

What about operating systems where the system calls require file names
to be represented as say fixed-length space-padded byte arrays,
or with the length prefixed to the characters (i.e. something
along the lines of `struct { unsigned char len; char bytes[len]; }' )?
(I don't know if there are actually any such OSs, but there may well be.)
In both cases, the runtime library needs to do some preprocessing
of the file names before handing them off to the OS, and it may
need to reject file names which are too long.

>On the other hand, if all functions dealing with the names of files
>had wide character counterparts it brings about two conditions I find
>objectionable:
>
>First it implies, even if it doesn't require, that all conforming
>applications run on platforms which provide file systems supporting
>wide character file names.

Well, that's just a matter of making the documentation for such
functions clear.

>Second it requires the run-time library to do translation, and quite
>possible to determine without reference to the operating system that
>the file name is not valid, because it contains wide characters which
>have no translation into the standard char set used by the OS.

So?  This may already be the case.

>The
>biggest objection to this is that an OS upgrade could break the RTL.

An OS upgrade that preserves binary backwards compatibility won't *break*
the RTL -- it's just that the RTL may not support all the new features
of the new OS.  But that's nothing specific to the hypothetical wfopen().
The same applies to malloc(), for example -- if you take an application
compiled with an old RTL and try to run it on a new OS, you may well
find that it can only allocate 640k, even though the machine has far
more memory than that available.  And the same applies to the non-wide-char
fopen() too -- you may well find that applications compiled with an
older RTL may only support 8-character file names even though the
new OS supports much longer file names.

>And that leaves out the fact that one could compile an application
>which would run on NT but break on Win95/98, in your particular case.

This is already possible (e.g. using the system() function).

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.10f9f67563ed6a2a98a033@news3.ibm.net>,
  mtobler@no-spam-ibm.net (Michael J. Tobler) wrote:
>
> In article <MPG.10f67762fe40f359896a1@news.concentric.net>,
> brownsta@concentric.net says...
> [snip]
> > Okay, I'll bite: what's ODR? Perhaps it's new-year brain rot, but I can't
> > think of what that might mean.
>
> The ODR is the One Definition Rule. It means that an object can only be
> defined ONCE, but declared many times.

The ODR is a misnomer, because it actually concerns things (like inline
functions, class definitions, template definitions, etc.) that *must* be
defined in each translation unit.  What the ODR says is that all such
multiple definitions must be the same.  (The standard spends a fair
amount of text on this rule -- while it sounds simple, there is the
problem of specifying the appropriate definition of "same".)

--
James Kanze                                           GABI Software, S   rl
Conseils en informatique orient    objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.10f6ee73fde2aaf99897b6@news.rmi.net>, Jerry Coffin
<jcoffin@taeus.com> writes
>ou, James Kuyper and I have all (apparently) read the message
>referring to STL, and each of us seems to have a somewhat different
>idea of which parts of the current standard library would be referred
>to when "STL" was mentioned.  Just for example, I most definitely
>would NOT consider basic_string related to "STL" at all.
>
>In the end, there's no real point in trying to argue which of us (if
>any) is right or wrong -- our disagreement in itself points to the
>fact that there simply IS no right answer, and STL is a term that
>simply can't be used in a very meaningful way.
>
>I'd agree that nearly everybody around would be likely to agree that
>if somebody associated "STL" with, e.g., std::vector, that would be
>reasonable.  Likewise, we'd almost certainly agree that associating
>STL with std::logic_error would almost certainly be incorrect.
>Unfortunately, between those extremes, there's a lot of area in which
>people canNOT be depended upon to agree (at all) as to association or
>lack thereof between STL and some part of the standard library.
>

The meanings of terms is important.  That people disagree is not a
reason for giving up, by discussion we can come to closer agreement
which can then be spread through the relevant community.  For example
such terms as polymorphism, object-orientation have a spectrum of
meanings (some consider polymorphism to include function overloading
while others do not).  If possible we need to reach agreement, if not we
need to understand the differing meanings being applied and know which
one is in use.

There will always be borderline cases where we need a degree of
toleration (watch kids (or childish adults) argue about whether a
particular colour is a shade of green or a shade of blue).

Civilised discussion helps with understanding, use of supposedly
intuitively understood terms leads to fights.  The 'template' element of
STL is a classic example of a word being used that already has another
meaning in the slightly broader context.  Other examples that spring to
mind are prototype and static.

It is perhaps worth noting that books on the STL (from Muser & Saini,
through Leen Ammeraal's 'The STL for C++ Programmers' to 'Using the STL'
and Matt Austern's 'Generic Programming and the STL' seem to be about
pretty much the same thing so why is there so much misunderstanding?
Could it be that many people just assume they know what they are talking
about without doing any reading to find out?


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> Could it be that many people just assume they know what they are talking
> about without doing any reading to find out?

Most likely. The same people post messages asking how to implement a
"link list", having obviously never looked in a book to find that the
term is "linked list".

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <gRlNYKAA7ik2EwEK@robinton.demon.co.uk>,
francis@robinton.demon.co.uk says...

[ ... ]

> The meanings of terms is important.  That people disagree is not a
> reason for giving up, by discussion we can come to closer agreement
> which can then be spread through the relevant community.

I agree that meanings are important.  IMO, starting with something
that appears to mean something different to nearly every person who
hears/sees it is NOT a good way to get agreement about meaning.

The first question is whether there's a valuable distinction to be
made by having a term to refer specifically to the containers,
iterators and algorithms in the library.  Personally, I'm not sure
this is a particularly useful distinction.  Worse, there are a couple
of things (strings and streams being the most obvious) that can be
used in conjunction with iterators and such, but are generally used
separately from them.  It's not at all clear whether these should be
considered part of this distinct class of things or not.

Assuming it's decided that this distinction is a useful one, we're
left with a second question that's less related to C++: is it better
to try to take a term that many have defined in ways that disagree
with each other, and try to get everybody agree on a single
definition, or to simply start with a new term with only a single
meaning from the beginning?

> For example
> such terms as polymorphism, object-orientation have a spectrum of
> meanings (some consider polymorphism to include function overloading
> while others do not).  If possible we need to reach agreement, if not we
> need to understand the differing meanings being applied and know which
> one is in use.

I'm not convinced that either of these is analogous.  No matter how
clearly a word is defined, some people are going to abuse it.  "Object
Oriented" (and many similar/related words and phrases) has a single
meaning, and is widely abused.

By contrast, there doesn't seem to be a single definition of "STL",
nor does there appear to be a wide consensus as to what it _should_
mean.

> It is perhaps worth noting that books on the STL (from Muser & Saini,
> through Leen Ammeraal's 'The STL for C++ Programmers' to 'Using the STL'
> and Matt Austern's 'Generic Programming and the STL' seem to be about
> pretty much the same thing so why is there so much misunderstanding?
> Could it be that many people just assume they know what they are talking
> about without doing any reading to find out?

The function of a book title is less to describe the book than to help
sell it.  One author pointed out several years ago that his recent
book contained "Turbo" in the title entirely because the publisher had
found that including "Turbo" in the title increased book sales by
close to 20%.

I also believe that Matt Austern means something quite specific (and a
bit different from most others) in referring to STL -- if I'm not
mistaken, Matt maintains the direct descendent of the code that was
submitted to the standard committee and used as the basis of some
parts of the standard library.  When he uses "STL", I believe he's
referring specifically to the library he maintains.  That has the
advantage of being a specific definition, but I'm not sure how useful
it is in a wider context.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> Francis Glassborow wrote in message
> >I know what to expect if a competent programmer states that a hash table
> >implementation conforms with the STL concept etc...  We need a name for
> >this kind of generic programming tool.

In article <F52z5L.265@cadlab.it>,
  "Alex Martelli" <martelli@cadlab.it> wrote:
> If we do, then "STL" is a bad choice because its meaning is
> quite "fragmented" by now -- see above.

What is the math library? I think that some would describe it as
everything defined in <cmath> but not anything else. But this
would include atof() and exclude atoi(). At least a few people
would include atoi() in discussions about the math library.

What is the string library? Surely this must include at least
basic_string. But what about the traditional C functions, such
as strlen() and strcpy()? Most would include these, but some
would not. What about memcpy()? A few would include these as
well. What about streambuf?

In both of these cases, there is some ambiguity about the
precise definitions. There is no judge or other official to
say "yes, atoi() is part of the math library." And yet, when
discussing various issues, we can speak of programs which
make heavy use of the math library, or which avoid linking
in the string library.

The term "STL" is likewise ambiguous. Despite this, it does
have meaning. The term can be used in various conversations
whenever ambiguity is not a block to communication.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <76t8kn$5b4$1@nnrp1.dejanews.com>,
  James.Kanze@dresdner-bank.com wrote:
>
> In article <MPG.10f9f67563ed6a2a98a033@news3.ibm.net>,
>   mtobler@no-spam-ibm.net (Michael J. Tobler) wrote:
> >
> > In article <MPG.10f67762fe40f359896a1@news.concentric.net>,
> > brownsta@concentric.net says...
> > [snip]
> > > Okay, I'll bite: what's ODR? Perhaps it's new-year brain rot, but I can't
> > > think of what that might mean.
> >
> > The ODR is the One Definition Rule. It means that an object can only be
> > defined ONCE, but declared many times.
>
> The ODR is a misnomer, because it actually concerns things (like inline
> functions, class definitions, template definitions, etc.) that *must* be
> defined in each translation unit.  What the ODR says is that all such
> multiple definitions must be the same.  (The standard spends a fair
> amount of text on this rule -- while it sounds simple, there is the
> problem of specifying the appropriate definition of "same".)

If you have an electronic version of the standard, search for "ODR". You
will only find those characters twice, once in the header and once in an
example. Read that section.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <369269AE.96AC2E36@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
>
> Francis Glassborow wrote:
> > Could it be that many people just assume they know what they are talking
> > about without doing any reading to find out?
>
> Most likely. The same people post messages asking how to implement a
> "link list", having obviously never looked in a book to find that the
> term is "linked list".

This is certainly possible. But don't make the mistake of assuming that
such people are always ignorant. If they were taught the technique
verbally, it may have sounded like "link" even though the speaker
pronounced "linked." The phonics are very similar.

Further, these days even people that do know the word is "linked"
instead of "link" may not know how to spell it. In this newsgroup
and in many other places, I've seen postings that have so many
misspellings that the first impression is one of a total lack of
education. I always work at overcoming that first impression, and
often with excellent results: many of these posts show excellent
forethought and present clever ideas, however misspelled.

This is the legacy of the "new" education in the late 1960's and
early 1970's. Today, you must not assume that a lack of written
communication skills implies a lack of skills. Otherwise, your
bigotry will make you appear as ignorant as those you put down.

Those of us who learned about computers without the benefit of a
college sometimes have the opposite problem. I can't tell you how
I felt, the first time I used the word "paradigm" in a meeting.
I pronounced it the way it's spelled (pair-uh-dig-em), and the
room erupted into laughter.

Another time, I was working on a database application but I didn't
understand a reference to the "randomizer." The lead programmer,
both intelligent and kind, began what would have been an hour-long
lecture on the details and purpose of the technique. After about
20 minutes, I asked him how this differed from a concept I already
knew about: a "hash." It turns out that these two terms are synonyms,
although I didn't know it.

Even colleges that DO teach written communication skills can't
prepare you for all possible CS terms. That same database
application, which ran on IBM mainframes, made extensive use of
"datasets." The way the term was used made it obvious that it
was synonymous with "file." But up until that time, all of my
experience was in the world of large minicomputers and
telecommunications. In that world, dataset is synonymous with
"modem."

Live and learn!

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <770p9u$cjd$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:
>
> In article <369269AE.96AC2E36@acm.org>,
>   Pete Becker <petebecker@acm.org> wrote:
> >
> > Francis Glassborow wrote:
> > > Could it be that many people just assume they know what they are talking
> > > about without doing any reading to find out?
> >
> > Most likely. The same people post messages asking how to implement a
> > "link list", having obviously never looked in a book to find that the
> > term is "linked list".
>
> This is certainly possible. But don't make the mistake of assuming that
> such people are always ignorant. If they were taught the technique
> verbally, it may have sounded like "link" even though the speaker
> pronounced "linked." The phonics are very similar.

Another thing to consider is that English is not everyone's first
language.  And if you learned the concept in French, it is not
immediately apparent whether the correct English translation is "link
list" or "linked list".

--
James Kanze                                           GABI Software, S   rl
Conseils en informatique orient    objet  --
                          --  Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr          mailto: James.Kanze@dresdner-bank.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:

: In article <369269AE.96AC2E36@acm.org>,
:   Pete Becker <petebecker@acm.org> wrote:
: >
: > Francis Glassborow wrote:
: > > Could it be that many people just assume they know what they are talking
: > > about without doing any reading to find out?
: >
: > Most likely. The same people post messages asking how to implement a
: > "link list", having obviously never looked in a book to find that the
: > term is "linked list".

: This is certainly possible. But don't make the mistake of assuming that
: such people are always ignorant. If they were taught the technique
: verbally, it may have sounded like "link" even though the speaker
: pronounced "linked." The phonics are very similar.

[snip]

: This is the legacy of the "new" education in the late 1960's and
: early 1970's. Today, you must not assume that a lack of written
: communication skills implies a lack of skills. Otherwise, your
: bigotry will make you appear as ignorant as those you put down.

You forgot the obvious, for many people posting in usenet
english is not the native language.

[snip]


--
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[Note that, of course, STL has *absolutely* nothing to do with this
thread, which is about the C++ Standard; it WOULD be nice if
people just stopped using this silly 3-letter acronym, incorrectly
most of the time, and started talking about Standard C++ and
its library!  Anyway, the theme is "why cannot I construct a
wifstream with a wide-character name string", so I added
comp.std.c++ as being the right venue for the discussion]

Jack Klein wrote in message <36a5aeaf.295767008@netnews.worldnet.att.net>...
    [snip]
>Do you know of any operating systems which actually support wide
>character file names?

Only the most widespread commercial 32-bit operating system on
the planet Earth... [quite carefully phrased, please note: Linux is
not "commercial", Win95 is not "32-bit":-)].

> And if you do, how many do you know of which do not?

A lot!  So what?

>What should the C++ implementation do with your wide character
>string if the operating system does not support wide character names?

What should the C++ implementation do with my wide character
string emitted by wprintf, etc, if the underlying environment does not
support wide-character output?  Yet the C++ standard specifies
it must handle it.

>Internally convert the string to a C string?  What if some of the wide
>characters were outside the range of values which fit into type char?

Whenever I try to construct an fstream object with a name string
that does not match whatever syntax the underlying environment
specifies, the constructor is specified to fail.  This, of course, would
apply just as well to the case where the specific cause of "not
matching the syntax" is "underlying environment specifies a
narrow-character string, and the wide-character string passed
in contains characters that cannot be converted to narrow ones".



>The C++ language standard cannot include support for wide character
>names any more than it can include support for directory structures,

It could, and should, support wide character filenames (and, arguably,
some form of "directory" access too, but that's a _completely_
unrelated argument).

>because operating systems and their file systems are not under the
>control of the language standard, and not all platforms support these
>features.  If such functions were added to the language it would
>either become impossible to have a conforming implementation on
>platforms without the features, or strictly conforming code using
>these features would not be portable to all conforming
>implementations.

It just isn't so.  Constructing a fstream with a name string of
(narrow-characters), say, "+++++", is fully conforming -- it will
succeed if the underlying environment supports this syntax
for a filename (and all other conditions for opening or creating
this funny-named file are met), it will fail if it doesn't, and this
causes absolutely no problem whatsoever because the C++
program can and should check if the stream was correctly
constructed anyway.  Constructing an fstream with a name
string of wide characters should work in EXACTLY the same
way -- be accepted at compile-time, succeed or fail at run
time just like for any other (narrow-character) string.

I consider it a wart in the C++ Standard Library that:
    -- wide-chars are not accepted "everywhere" narrow-chars
        are, and
    -- std::basic_string is not accepted "everywhere" a
        const char*, or const wchar_t*, is.
Well, maybe that's _two_ warts...


Alex



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Alex Martelli wrote:
>
> [Note that, of course, STL has *absolutely* nothing to do with this
> thread, which is about the C++ Standard; it WOULD be nice if
> people just stopped using this silly 3-letter acronym, incorrectly
> most of the time, and started talking about Standard C++ and
> its library! ...]

What does STL stand for? I thought it stood for the C++ Standard
Template Library; i.e. that subset of the standard library which uses
templates. wifstream is certainly in that subset.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:


>Alex Martelli wrote:
>>
>> [Note that, of course, STL has *absolutely* nothing to do with this
>> thread, which is about the C++ Standard; it WOULD be nice if
>> people just stopped using this silly 3-letter acronym, incorrectly
>> most of the time, and started talking about Standard C++ and
>> its library! ...]

>What does STL stand for? I thought it stood for the C++ Standard
>Template Library; i.e. that subset of the standard library which uses
>templates. wifstream is certainly in that subset.

No, it stands for just "Standard Template Library", and the
"Standard" does not refer to the C++ standard. The orginal STL
was developed over a period of years for internal use at Hewlett-
Packard by Alex Stepanov and Meng Lee.  HP graciously allowed the
STL to be posted publicly.

Stepanov and Lee in 1993 proposed that their STL be added to
the C++ standard, which was at that time (still) lacking a
useful library. The C++ committee agreed in 1994 to adopt
the STL in substance. HP then even more graciously released
the STL into the public domain, allowing its adoption into the
C++ standard without legal impediments.

The STL was modified in detail for inclusion in the standard,
and I believe some features in the original STL do not appear
in the C++ standard.

What was in the original STL is not differentiated in the C++
standard.  For example, the C++ library contains items (such as
iostreams and numeric classes) that did not appear in STL, and
also classes (such as the string class) that are not properly STL
classes yet can be used with the containers and algorithms that
originated in the STL.

It is therefore unhelpful to talk about "STL" in conjunction
with the C++ standard. You cannot go the standard and find any
mention of STL, nor can you easily pick out the parts of the
standard that correspond most closely to the original STL,
especially without referring to original STL documentation.

It is reasonable to talk about "containers and alogrithms", if
that is what you mean, but the term "STL" has no well-understood
meaning when talking about Standard C++.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> Alex Martelli wrote:
> >
> > [Note that, of course, STL has *absolutely* nothing to do with this
> > thread, which is about the C++ Standard; it WOULD be nice if
> > people just stopped using this silly 3-letter acronym, incorrectly
> > most of the time, and started talking about Standard C++ and
> > its library! ...]
>
> What does STL stand for? I thought it stood for the C++ Standard
> Template Library;

Yes...

>  i.e. that subset of the standard library which uses
> templates. wifstream is certainly in that subset.

No. Basically, it's containers, iterators, and algorithms. In
particular, strings and streams are not part of STL.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> James Kuyper <kuyper@wizard.net> writes:
> >What does STL stand for? I thought it stood for the C++ Standard
> >Template Library; i.e. that subset of the standard library which uses
> >templates.

In article <76gb6o$rmm$1@engnews2.Eng.Sun.COM>,
  stephen.clamage@sun.com (Steve Clamage) wrote:
> No, it stands for just "Standard Template Library", and the
> "Standard" does not refer to the C++ standard. The orginal STL
> was developed over a period of years for internal use at Hewlett-
> Packard by Alex Stepanov and Meng Lee.  HP graciously allowed the
> STL to be posted publicly.
>
> Stepanov and Lee in 1993 proposed that their STL be added to
> the C++ standard, which was at that time (still) lacking a
> useful library. The C++ committee agreed in 1994 to adopt
> the STL in substance. HP then even more graciously released
> the STL into the public domain, allowing its adoption into the
> C++ standard without legal impediments.
>
> The STL was modified in detail for inclusion in the standard,
> and I believe some features in the original STL do not appear
> in the C++ standard.
>
> What was in the original STL is not differentiated in the C++
> standard.  For example, the C++ library contains items (such as
> iostreams and numeric classes) that did not appear in STL, and
> also classes (such as the string class) that are not properly STL
> classes yet can be used with the containers and algorithms that
> originated in the STL.
>
> It is therefore unhelpful to talk about "STL" in conjunction
> with the C++ standard. You cannot go the standard and find any
> mention of STL, nor can you easily pick out the parts of the
> standard that correspond most closely to the original STL,
> especially without referring to original STL documentation.
>
> It is reasonable to talk about "containers and alogrithms", if
> that is what you mean, but the term "STL" has no well-understood
> meaning when talking about Standard C++.

I believe that most C++ programmers understand "The STL" to mean
that part ofthe C++ Standard Library which originated in HP's
Standard Template Library, as amended, perhaps (depending on
context) including additions such as basic_string. For those that
do not have access to this somewhere (not even the web), I would
approximate it by referring to the standard's containers,
iterators, algorithms, and function objects.

To say that the phrase is unhelpful and not well-understood is
akin to saying the same thing about the C++ "ODR". It too, does
not have a definition in the standard. And yet I've seen many
programmers refer to the ODR with a clear expectation that
others will understand them.

Unlike the phrase STL, the phrase ODR does occur in the standard
in two places. But both of these are non-normative: One is in
the heading "3.2 One Definition Rule [basic.def.odr]" and the
other is in a comment in the last example in that section.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <368AF23E.B1799D00@wizard.net>, James Kuyper
<kuyper@wizard.net> writes
>
>Alex Martelli wrote:
>>
>> [Note that, of course, STL has *absolutely* nothing to do with this
>> thread, which is about the C++ Standard; it WOULD be nice if
>> people just stopped using this silly 3-letter acronym, incorrectly
>> most of the time, and started talking about Standard C++ and
>> its library! ...]
>
>What does STL stand for? I thought it stood for the C++ Standard
>Template Library; i.e. that subset of the standard library which uses
>templates. wifstream is certainly in that subset.

NO.  The STL is a subset of those parts that use templates that provides
a very specific set of facilities (containers and algorithms glued
together with iterators) with performance guarantees and requirements
for extensions.  I.e. once I understand the requirements I can write a
hash table that works with standard algorithms.

There are other templates in the Standard C++ Library that are not
designed to work as containers/algorithms.  They may be containers but
they lack the essential characteristics that support the algorithms, or
they might be algorithms that lacked the mechanisms to work on STL
containers (though none spring to mind)


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> wrote:
>Alex Martelli wrote:
>>
>> .... STL has *absolutely* nothing to do with this
>> thread, which is about the C++ Standard; it WOULD be nice if
>> people just stopped using this silly 3-letter acronym, incorrectly
>> most of the time, and started talking about Standard C++ and
>> its library!
>
>What does STL stand for? I thought it stood for the C++ Standard
>Template Library; i.e. that subset of the standard library which uses
>templates. wifstream is certainly in that subset.

There is no STL in the Standard C++ Library.  "STL" is a name assigned
to a set of components designed by Alexander Stepanov and Meng Lee.
Its components were adopted into the Standard, with changes.  Matt
Austern maintains a (more-or-less standard-conforming but extended)
implementation of those components at SGI, and calls the implementation
"STL".  It has containers, algorithms, iterators, and adaptors.  It does
not have iostreams, which is what the question was about.

You would be hard-pressed to find any significant part of the Standard
C++ Library which does not "use templates", so distinguishing parts of
it on that basis would be silly.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:

>> James Kuyper <kuyper@wizard.net> writes:
>> >What does STL stand for? I thought it stood for the C++ Standard
>> >Template Library; i.e. that subset of the standard library which uses
>> >templates.

>In article <76gb6o$rmm$1@engnews2.Eng.Sun.COM>,
>  stephen.clamage@sun.com (Steve Clamage) wrote:
>> No, it stands for just "Standard Template Library", and the
>> "Standard" does not refer to the C++ standard. ...
>>
>> It is therefore unhelpful to talk about "STL" in conjunction
>> with the C++ standard. You cannot go the standard and find any
>> mention of STL, nor can you easily pick out the parts of the
>> standard that correspond most closely to the original STL,
>> especially without referring to original STL documentation.
>>
>> It is reasonable to talk about "containers and alogrithms", if
>> that is what you mean, but the term "STL" has no well-understood
>> meaning when talking about Standard C++.

>I believe that most C++ programmers understand "The STL" to mean
>that part ofthe C++ Standard Library which originated in HP's
>Standard Template Library, as amended, perhaps (depending on
>context) including additions such as basic_string.

You wouldn't know it from the kinds of comments seen in C++
newsgroups and other places (including the comment above from
James Kuyper, who is certainly not a novice). We get comments on
our customer support line where programmers use "STL" to mean all
sorts of things. Based on my personal experience, I'd have to take
issue with your characterization that "most programmers" have a
common understanding of what "STL" means.  Maybe you meant "most
readers of this newsgroup."

>For those that
>do not have access to this somewhere (not even the web), I would
>approximate it by referring to the standard's containers,
>iterators, algorithms, and function objects.

OK, but I prefer never to use the term STL when referring to
standard C++.

>To say that the phrase is unhelpful and not well-understood is
>akin to saying the same thing about the C++ "ODR". It too, does
>not have a definition in the standard. And yet I've seen many
>programmers refer to the ODR with a clear expectation that
>others will understand them.

Ummm, section 3.2 is entitled "One definition rule", and
two pages are devoted to discussing the one-definition rule.
I'll agree that the acronym "ODR" might not be familiar, but
once the acronym is spelled out, it can be found easily in the
standard or in reference books.

By contrast, neither the acronym "STL" nor the phrase "template
library" appears anywhere in the standard. (At least, a text
search failed to show an instance.) Existing reference material
using the term STL would almost certainly refer to the original STL,
and not the the C++ standard.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:
>
> James Kuyper <kuyper@wizard.net> wrote:
....
> >What does STL stand for? I thought it stood for the C++ Standard
> >Template Library; i.e. that subset of the standard library which uses
> >templates. wifstream is certainly in that subset.
....
> You would be hard-pressed to find any significant part of the Standard
> C++ Library which does not "use templates", so distinguishing parts of
> it on that basis would be silly.

According to footnote 1, "With [some] qualifications ... the Standard C
Library is a subset of the Standard C++ Library." Thus, there is a large
part of the Standard C++ Library that doesn't use templates.

I had been under the impression that the C++ library consisted of "C
library" + STL + "not much else". Since the consensus seems to be that
this is not what STL means, I'm at a loss for a convenient name for the
non-C part of the library.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In newsgroup comp.std.c++, article <76gln2$8mg$1@nnrp1.dejanews.com>, the
AllanW@my-dejanews.com (AllanW@my-dejanews.com) wrote:
>To say that the phrase is unhelpful and not well-understood is
>akin to saying the same thing about the C++ "ODR". It too, does
>not have a definition in the standard. And yet I've seen many
>programmers refer to the ODR with a clear expectation that
>others will understand them.

Okay, I'll bite: what's ODR? Perhaps it's new-year brain rot, but I can't
think of what that might mean.

As for "STL" being misunderstood, I have to disagree with whoever
"AllanW" might really be. I haven't made an actual count, but it seems to
me, based on the past few months' articles posted here, that roughly the
same number of programmers think STL does include streams or strings or
both as know that it includes neither.

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                      http://www.concentric.net/%7eBrownsta/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <76gln2$8mg$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
says...

[ ... ]

> I believe that most C++ programmers understand "The STL" to mean
> that part ofthe C++ Standard Library which originated in HP's
> Standard Template Library, as amended, perhaps (depending on
> context) including additions such as basic_string. For those that
> do not have access to this somewhere (not even the web), I would
> approximate it by referring to the standard's containers,
> iterators, algorithms, and function objects.

You, James Kuyper and I have all (apparently) read the message
referring to STL, and each of us seems to have a somewhat different
idea of which parts of the current standard library would be referred
to when "STL" was mentioned.  Just for example, I most definitely
would NOT consider basic_string related to "STL" at all.

In the end, there's no real point in trying to argue which of us (if
any) is right or wrong -- our disagreement in itself points to the
fact that there simply IS no right answer, and STL is a term that
simply can't be used in a very meaningful way.

I'd agree that nearly everybody around would be likely to agree that
if somebody associated "STL" with, e.g., std::vector, that would be
reasonable.  Likewise, we'd almost certainly agree that associating
STL with std::logic_error would almost certainly be incorrect.
Unfortunately, between those extremes, there's a lot of area in which
people canNOT be depended upon to agree (at all) as to association or
lack thereof between STL and some part of the standard library.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 31 Dec 1998 02:54:31 GMT, "Alex Martelli" <martelli@cadlab.it>
wrote:

>
> [Note that, of course, STL has *absolutely* nothing to do with this
> thread, which is about the C++ Standard; it WOULD be nice if
> people just stopped using this silly 3-letter acronym, incorrectly
> most of the time, and started talking about Standard C++ and
> its library!  Anyway, the theme is "why cannot I construct a
> wifstream with a wide-character name string", so I added
> comp.std.c++ as being the right venue for the discussion]
>
> Jack Klein wrote in message <36a5aeaf.295767008@netnews.worldnet.att.net>...
>     [snip]
> >Do you know of any operating systems which actually support wide
> >character file names?
>
> Only the most widespread commercial 32-bit operating system on
> the planet Earth... [quite carefully phrased, please note: Linux is
> not "commercial", Win95 is not "32-bit":-)].
>
> > And if you do, how many do you know of which do not?
>
> A lot!  So what?
>
> >What should the C++ implementation do with your wide character
> >string if the operating system does not support wide character names?
>
> What should the C++ implementation do with my wide character
> string emitted by wprintf, etc, if the underlying environment does not
> support wide-character output?  Yet the C++ standard specifies
> it must handle it.
>
> >Internally convert the string to a C string?  What if some of the wide
> >characters were outside the range of values which fit into type char?
>
> Whenever I try to construct an fstream object with a name string
> that does not match whatever syntax the underlying environment
> specifies, the constructor is specified to fail.  This, of course, would
> apply just as well to the case where the specific cause of "not
> matching the syntax" is "underlying environment specifies a
> narrow-character string, and the wide-character string passed
> in contains characters that cannot be converted to narrow ones".
>
>
>
> >The C++ language standard cannot include support for wide character
> >names any more than it can include support for directory structures,
>
> It could, and should, support wide character filenames (and, arguably,
> some form of "directory" access too, but that's a _completely_
> unrelated argument).
>
> >because operating systems and their file systems are not under the
> >control of the language standard, and not all platforms support these
> >features.  If such functions were added to the language it would
> >either become impossible to have a conforming implementation on
> >platforms without the features, or strictly conforming code using
> >these features would not be portable to all conforming
> >implementations.
>
> It just isn't so.  Constructing a fstream with a name string of
> (narrow-characters), say, "+++++", is fully conforming -- it will
> succeed if the underlying environment supports this syntax
> for a filename (and all other conditions for opening or creating
> this funny-named file are met), it will fail if it doesn't, and this
> causes absolutely no problem whatsoever because the C++
> program can and should check if the stream was correctly
> constructed anyway.  Constructing an fstream with a name
> string of wide characters should work in EXACTLY the same
> way -- be accepted at compile-time, succeed or fail at run
> time just like for any other (narrow-character) string.
>
> I consider it a wart in the C++ Standard Library that:
>     -- wide-chars are not accepted "everywhere" narrow-chars
>         are, and
>     -- std::basic_string is not accepted "everywhere" a
>         const char*, or const wchar_t*, is.
> Well, maybe that's _two_ warts...
>
>
> Alex

<Jack>

After thinking it over, I disagree with your opinion.  C style strings
can be required by the language because all operating systems capable
of hosting a "hosted environment" can express file names as sequences
of C style chars.  There is no requirement that either C or C++ modify
the string in any way, merely hand it off to the operating system
which determines whether it represents the name of a file which is
valid for the requested operation (permissions, read/write attributes,
etc.).

If a platform doesn't support such a file system, then at best it can
support a freestanding implementation.

On the other hand, if all functions dealing with the names of files
had wide character counterparts it brings about two conditions I find
objectionable:

First it implies, even if it doesn't require, that all conforming
applications run on platforms which provide file systems supporting
wide character file names.

Second it requires the run-time library to do translation, and quite
possible to determine without reference to the operating system that
the file name is not valid, because it contains wide characters which
have no translation into the standard char set used by the OS.  The
biggest objection to this is that an OS upgrade could break the RTL.
And that leaves out the fact that one could compile an application
which would run on NT but break on Win95/98, in your particular case.

</Jack>
--
Do not email me with questions about programming.
Post them to the appropriate newsgroup.
Followups to my posts are welcome.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

brownsta@concentric.net (Stan Brown) writes:

> Okay, I'll bite: what's ODR? Perhaps it's new-year brain rot, but I can't
> think of what that might mean.

One-Definition Rule. The principle that each thing (object, function,
template) may be defined at most once, although it can be declared
more than once.

The section on ODR actually explains a lot more: The thing has to be
defined exactly once if it is used (and there is an elaborate
definition of 'being used'). The thing may be defined more than once
if it is an inline function or the like, provided that all copies of
the inline function are identical (with a definition of 'being
identical').

Regards,
Martin


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Alex Martelli" <martelli@cadlab.it> writes:

> What should the C++ implementation do with my wide character
> string emitted by wprintf, etc, if the underlying environment does not
> support wide-character output?  Yet the C++ standard specifies
> it must handle it.

The C standard (NA1) specifies very precisely what wprintf should do,
regardless of whether the underlying operating system has a notion of
wide streams.  The wide-character string is converted to a narrow
multibyte string as if by using wcstombs (using whatever locale is
currently in force), and then that multibyte string is sent to the
appropriate output device.  The C standard very carefully doesn't
require anything exotic like wide output devices.

The C++ standard is very similar.  Again, it specifies very precisely
just how a wide filebuf interacts with the narrow external world.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.10f67762fe40f359896a1@news.concentric.net>,
brownsta@concentric.net says...
[snip]
> Okay, I'll bite: what's ODR? Perhaps it's new-year brain rot, but I can't
> think of what that might mean.

The ODR is the One Definition Rule. It means that an object can only be
defined ONCE, but declared many times.

--
<<<<<<<<<<  Blue Skies  >>>>>>>>>>>
<        Michael J. Tobler        >
<     mtobler@no-spam-ibm.net     >
< remove "no-spam-" when replying >
<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]