In article <7f65e4$f0u$1@shell7.ba.best.com> , ncm@nospam.cantrip.org
(Nathan Myers) wrote:

> James Kuyper wrote:
>> I believe MacOS and VMS are two such systems. DOS/Windows platforms
>> support it only by interpreting '/' as '\'.
>
> Mac systems support it by treating '/' as an ordinary filename
> character.  Thus, "sys/asm.h" is not a directory name and file
> name forming a path, but simply a single filename with a '/'
> in it.  This is sufficient to support the namespace mappings
> suggested in this thread.

In fact, the only major Mac compiler (Metrowerks) supports an option to
interpret "/" as a directory separator.
---
[ 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              ]

saroj@bear.com wrote:
: I do not have any experience in Mac. Is anybody familiar with the format I
: mentioned above? Is it irrelevant in practice? So can we now safely use
: this convention in most platforms? How about VMS?

People do use file names like "sys/socket.h" and "machine/endian.h" on the
Mac. One would have to look for those names first and then for the
subdirectory case.

I doubt 8.3 filesystems are that important for *development* environments
anymore, though standards tend to have to accomodate *anything* so maybe
they're still a concern. CDROMs can be made in "hybrid" formats so you get
longer names on systems that support it and 8.3 otherwise.

Perhaps this should transition into a discussion of a first class module
system for C++, which is something to hope for in the next version of the
standard. "First class" means many things, but perhaps the first thing is
"not textual inclusion." This need for "unique naming" could also be
addressed. One could even have a standard way of specifying unique
identifiers for the module. E.g. reserve a portion of the module namespace
such that the names in that part include a UUID or other automatically
generated unique identifier. Like
    import [UUID/80c79e02-fbe7-11d2-8912-0005029cd84f/stringutils]
Yeah its ugly, but the naming is highly robust. Obviously one wouldn't be
able to map these to filenames so trivially as we do now, but I'd also like
to see a standard "module distribution format" like Java has with Jar
files (they would not include complied content of course).

-Z-




[ 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 <zalmanFAKMDK.Bpx@netcom.com>,
  zalman@netcom.com (Zalman Stern) wrote:
>
> saroj@bear.com wrote:
> : I think Mac systems have 8+3 file names, so this kind of naming
> : scheme will lead to problems very soon on Macs. Can somebody please correct
> : me if I am wrong?
>
> If you said that in certain groups of programmers I hang out with, you'd be
> asked to leave and never come back...
>

Why? Do you get insulted by comparison with DOS? Anyway, I have heard that
certain popular CD-ROM format allows only 8+3 case-insensitive file names
(even on Unix). Now, if you give short file names and '/' stands for
directory separator, then you can safely use subdir/subdir/file convention
with DOS or the above mentioned CD-ROM format. My point is that if '/' is not
mapped to a directory separator like in Mac, then you can easily exceed 31
char. limit.

I do not have any experience in Mac. Is anybody familiar with the format I
mentioned above? Is it irrelevant in practice? So can we now safely use
this convention in most platforms? How about VMS?

(To moderator: Even though it is not exactly standard-related, but still this
 thread will be useful to use C++ in a standard manner in most platforms.)

> Mac filenames are allowed to be up to 31 characters and have extremely few
> restrictions on what characters can be used. (E.g. it is sometimes a bad
> idea to start a filename with a '.' and NULs are uncool, but other than
> that anything is fair game.)
>
> The "slash inside a filename" convention mentioned is commonly used in Mac
> development. (E.g. GUSI, the library which provides UNIX socket and file
> I/O primitives, uses it.)
>

-----------== 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              ]

Christopher Eltschka (celtschk@physik.tu-muenchen.de) wrote:
: I don't see what you mean exactly. In which way is using a
: string as file name a bias in favour of some OSs? Don't
: filenames on the Mac consist of characters?
: (BTW, streams are not a part of the STL)

There is no guarantee that a string like "Macintosh HD:My Files:Letter"
doesn't name more than one file. The solution to this is to encode the
volume ID into the volume name in the string if it is not unique (or always
if you want to be careful). I think GUSI solves this problem, but its been
a while since I looked at it.

If one wanted to, one could allow and alternative syntax for filename
strings that encoded volume ID, parent directory ID, filename, instead of
a pathname. I believe this would work within the confines of the standard,
but lots of code which assumes a pathname with components seperated by a
path seperator would break.

I expect VMS has worse issues than the Mac here, but I don't know.

-Z-
---
[ 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              ]

saroj@bear.com wrote:
: I think Mac systems have 8+3 file names, so this kind of naming
: scheme will lead to problems very soon on Macs. Can somebody please correct
: me if I am wrong?

If you said that in certain groups of programmers I hang out with, you'd be
asked to leave and never come back...

Mac filenames are allowed to be up to 31 characters and have extremely few
restrictions on what characters can be used. (E.g. it is sometimes a bad
idea to start a filename with a '.' and NULs are uncool, but other than
that anything is fair game.)

The "slash inside a filename" convention mentioned is commonly used in Mac
development. (E.g. GUSI, the library which provides UNIX socket and file
I/O primitives, uses it.)

-Z-



[ 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              ]

J.Barfurth wrote:
>
> saroj@bear.com schrieb in Nachricht <7f7gol$r3t$1@nnrp1.dejanews.com>...
> >In article <7f65e4$f0u$1@shell7.ba.best.com>,
> >  ncm@nospam.cantrip.org (Nathan Myers) wrote:
> >> James Kuyper wrote:
> >> > I believe MacOS and VMS are two such systems. DOS/Windows platforms
> >> > support it only by interpreting '/' as '\'.
> >>
> >> Mac systems support it by treating '/' as an ordinary filename
> >> character.  Thus, "sys/asm.h" is not a directory name and file
> >> name forming a path, but simply a single filename with a '/'
> >> in it.  This is sufficient to support the namespace mappings
> >> suggested in this thread.
> >>
> >
> >I think Mac systems have 8+3 file names, so this kind of naming
> >scheme will lead to problems very soon on Macs. Can somebody please correct
> >me if I am wrong?
>
> I'll try to keep the OS-specific stuff short:
> Mac Systems have a 31-character limit per file-/directory-name and no
> system-defined use of extensions. They use ':' as directory separator. The
> use of full pathnames is discouraged, as those may be ambiguous (no 'drive
> letters'). Instead files are specified using two ID numbers and a partial
> path.

It would be trivial for Mac systems to translate '/' into ':'
for creating relative paths. Obviously this would disallow
header files with '/', but thay are
- probably not that common anyway
- easily to replace by a subdirectory with file
- for those who _really_ want them, easily supportable by the rule
  that <xxx/yyy> _first_ looks for a file named "xxx/yyy", and
  if that search failed, looks in the relative subdirectories
  named xxx (if they exist) for files called yyy. If the whole
  name is longer than 31 chars, the first step can be omitted,
  since it won't succeed anyway.

Other systems which allow "/" in file names can proceed similar.

Moreover, on DOS (8.3), you already get problems with names
like <algorithm> - you can't directly use that as file name.
Again, a same mapping rule (just truncate to 8 chars and
add .h) is fine (another possible mapping rule would be to
translate it to algorith\m - "\" is the DOS directory
separator - or even to std0815.h).

And finally, I doubt that any relative pathname will ever get
longer than 31 chars in practise. After all, especially C/C++
programmers don't like typing too much ;-)

To get an impression how long 31 character names are,
look at the following (which has 28 characters):

#include <linear_algebra/matrix/sparse>

I guess, this would be shortened to

#include <linalg/matrix/sparse>

which has just 20 chars. So even

#include <linalg/matrix/sparse/dynamic>

with 28 characters again would fit into a mac file name.

So, no counter argument against using "/" here.

>
> But it is still true, that the naming scheme suggested by Nathan may
> overflow even such limits, when we get to longer and/or nested namespace
> names. As I suggested in another post, it might be useful to have a portable
> scheme for #include-namesapces. This should be designed in a way that
> interferes as little as possible with existing pathname-based schemes. How
> such names are mapped to files (or other containers of source code) will of
> course remain implementation-specific.

Since the mapping of <hello/world> to files is implementation
specific right now, I don't see a need, nor an advantage for
an extra directive.

>
> BTW: I always was rather unhappy with the fact, that file names are
> specified using (C-)strings when opening standard fstreams (and C FILE*s).
> This (and the text-oriented console i/o) are features of the standard, that
> can't meaningfully be used in production code on a platform like the Mac.
> While probably useful many platforms, I _have_ to write my own filebuf's to
> use that part of the STL in a portable way. I use a FileSpec class that
> hides the OS differences for file naming.
> Why was this interface left unaltered in the standard ? I know that it is
> inherently difficult to have portable file handling, but I still dislike the
> fact, that the standard shows a bias in favor of some OSs.

I don't see what you mean exactly. In which way is using a
string as file name a bias in favour of some OSs? Don't
filenames on the Mac consist of characters?
(BTW, streams are not a part of the STL)

And according to cin/cout: If your compiler doesn't provide
an useful implementation, it's a problem of the compiler.
The mac surely has a screen; therefore it would be trivial
f.ex. to pop up a window for standard IO as soon as any input
and/or output is requested by the program. This would f.ex.
be an useful feature for debugging.
I guess the language would be use quite a bit less if
there were no predefined standard in/output ;-)
---
[ 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 <7f65e4$f0u$1@shell7.ba.best.com>,
  ncm@nospam.cantrip.org (Nathan Myers) wrote:
> James Kuyper wrote:
> > I believe MacOS and VMS are two such systems. DOS/Windows platforms
> > support it only by interpreting '/' as '\'.
>
> Mac systems support it by treating '/' as an ordinary filename
> character.  Thus, "sys/asm.h" is not a directory name and file
> name forming a path, but simply a single filename with a '/'
> in it.  This is sufficient to support the namespace mappings
> suggested in this thread.
>

I think Mac systems have 8+3 file names, so this kind of naming
scheme will lead to problems very soon on Macs. Can somebody please correct
me if I am wrong?

Thanks,
Saroj Mahapatra

-----------== 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              ]

saroj@bear.com wrote:
>
> In article <7f65e4$f0u$1@shell7.ba.best.com>,
>   ncm@nospam.cantrip.org (Nathan Myers) wrote:
....
> > Mac systems support it by treating '/' as an ordinary filename
> > character.  Thus, "sys/asm.h" is not a directory name and file
> > name forming a path, but simply a single filename with a '/'
> > in it.  This is sufficient to support the namespace mappings
> > suggested in this thread.
> >
>
> I think Mac systems have 8+3 file names, so this kind of naming
> scheme will lead to problems very soon on Macs. Can somebody please correct
> me if I am wrong?

I know nothing about writing programs for Mac's, but I use them
occasionally for word processing. File names appear to be free form,
including spaces and special characters, and to have a very long maximum
length. They're not 8+3.
---
[ 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              ]

saroj@bear.com schrieb in Nachricht <7f7gol$r3t$1@nnrp1.dejanews.com>...
>In article <7f65e4$f0u$1@shell7.ba.best.com>,
>  ncm@nospam.cantrip.org (Nathan Myers) wrote:
>> James Kuyper wrote:
>> > I believe MacOS and VMS are two such systems. DOS/Windows platforms
>> > support it only by interpreting '/' as '\'.
>>
>> Mac systems support it by treating '/' as an ordinary filename
>> character.  Thus, "sys/asm.h" is not a directory name and file
>> name forming a path, but simply a single filename with a '/'
>> in it.  This is sufficient to support the namespace mappings
>> suggested in this thread.
>>
>
>I think Mac systems have 8+3 file names, so this kind of naming
>scheme will lead to problems very soon on Macs. Can somebody please correct
>me if I am wrong?

I'll try to keep the OS-specific stuff short:
Mac Systems have a 31-character limit per file-/directory-name and no
system-defined use of extensions. They use ':' as directory separator. The
use of full pathnames is discouraged, as those may be ambiguous (no 'drive
letters'). Instead files are specified using two ID numbers and a partial
path.

But it is still true, that the naming scheme suggested by Nathan may
overflow even such limits, when we get to longer and/or nested namespace
names. As I suggested in another post, it might be useful to have a portable
scheme for #include-namesapces. This should be designed in a way that
interferes as little as possible with existing pathname-based schemes. How
such names are mapped to files (or other containers of source code) will of
course remain implementation-specific.

BTW: I always was rather unhappy with the fact, that file names are
specified using (C-)strings when opening standard fstreams (and C FILE*s).
This (and the text-oriented console i/o) are features of the standard, that
can't meaningfully be used in production code on a platform like the Mac.
While probably useful many platforms, I _have_ to write my own filebuf's to
use that part of the STL in a portable way. I use a FileSpec class that
hides the OS differences for file naming.
Why was this interface left unaltered in the standard ? I know that it is
inherently difficult to have portable file handling, but I still dislike the
fact, that the standard shows a bias in favor of some OSs.
---
[ 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:

>
> I believe MacOS and VMS are two such systems. DOS/Windows platforms
> support it only by interpreting '/' as '\'.

I do this all the time on VMS.  It works fine.

Bruce Visscher
---
[ 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:
> I believe MacOS and VMS are two such systems. DOS/Windows platforms
> support it only by interpreting '/' as '\'.

Mac systems support it by treating '/' as an ordinary filename
character.  Thus, "sys/asm.h" is not a directory name and file
name forming a path, but simply a single filename with a '/'
in it.  This is sufficient to support the namespace mappings
suggested in this thread.

--
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 <37138327.A4688182@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> ? You could always have files without the ".h" suffix, regardless of the
> directory (assuming your implementation itself didn't restrict you
> otherwise). The ".h" convention was only a convention, not something
> enforced as part of the language. While I've seen code editors and
> 'make' programs that treated .h files differently, I've never seen a
> C/C++ implementation that enforced it as a restriction (I'm sure some
> exist, but I doubt they're common).

I didn't think of it before, but something you said just now gave me
this idea (maybe this is what you were leading up to). You could use
non-standard extensions other than .h -- for instance, for Rogue Wave,
you could use
    #include <date.rw>
    #include <string.rw>
and so on. This ought to work on every compiler tha understands file
extensions (aka file types).

----
Allan_W@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              ]

Siemel Naran<sbnaran@uiuc.edu> wrote:
>The relative path approach is good for documentation too, and it lets
>you have header files without the ".h" suffix.
>   #include <roguewave/date> /* hypothetical */

I usually point out in cases like this that embedding a company or
product name in a path or namespace name is an extremely bad idea.
It means that management or marketing whims break your code.

--
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              ]

On 13 Apr 99 05:30:20 GMT, AllanW {formerly AllanW@my-dejanews.com}

>unknown other packages from unknown vendors. Naming tricks such as
>"rwdate.h" can help with this.

Theoretically this is not a good solution because the next version of
C may include a file called <rwdate.h>.  In practice, this is
unlikely, so file "rwdate.h" is ok.

The relative path approach is good for documentation too, and it lets
you have header files without the ".h" suffix.
   #include <std/vector>
   #include <blitz/tinyvec> /* but blitz uses tinyvec.h */
   #include <roguewave/date> /* hypothetical */
   #include <qt/pushbutton>
I didn't know that there exist operating systems that don't support
this construct.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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              ]

Siemel Naran wrote:
>
> On 13 Apr 99 05:30:20 GMT, AllanW {formerly AllanW@my-dejanews.com}
>
> >unknown other packages from unknown vendors. Naming tricks such as
> >"rwdate.h" can help with this.
>
> Theoretically this is not a good solution because the next version of
> C may include a file called <rwdate.h>.  In practice, this is
> unlikely, so file "rwdate.h" is ok.
>
> The relative path approach is good for documentation too, and it lets
> you have header files without the ".h" suffix.

? You could always have files without the ".h" suffix, regardless of the
directory (assuming your implementation itself didn't restrict you
otherwise). The ".h" convention was only a convention, not something
enforced as part of the language. While I've seen code editors and
'make' programs that treated .h files differently, I've never seen a
C/C++ implementation that enforced it as a restriction (I'm sure some
exist, but I doubt they're common).

>    #include <std/vector>
>    #include <blitz/tinyvec> /* but blitz uses tinyvec.h */
>    #include <roguewave/date> /* hypothetical */
>    #include <qt/pushbutton>
> I didn't know that there exist operating systems that don't support
> this construct.

I believe MacOS and VMS are two such systems. DOS/Windows platforms
support it only by interpreting '/' as '\'.
---
[ 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 {formerly AllanW@my-dejanews.com} wrote:
> C++ compilers must already support this functionality in order to suppo=
rt
> code with
> =

>     #include <sys/stat.h>
> =

> This is an old C-language header file, and even though it probably
> isn't in the C standard (and therefore isn't incorporated by reference
> into C++), processing this is mandatory for a compiler vendor that
> wants to support old UNIX C programs. Since the name stat.h doesn't
> collide with any standard header, a compiler vendor could support this
> by simply ignoring anything before the slash character, but AFAIK no
> compiler that's hosted on an OS with named subdirectories has ever
> done it this way.
> =

> For compilers that do support subdirectory names, there's no reason
> that vendors can't supply header files intended to be included that
> way. This makes support for
> =

>     #include <rw/string.h>
> =

> so common that one can call it a de-facto standard. Other than a
> minor syntax variance, this is identical to your proposal.

But using slashes ('/') as path delimiters is still OS specific. For inst=
ance,
using the same approach on MacOS would require something like #include
<rw:string.h>. To port a large program might then involve changing _many_=

#includes directed at headers of a supposedly portable library. =

OTOH I've seen (on a Mac) support for old your UNIX C code by having a fi=
le
named "sys/stat" - no subdirectories involved. But when you get down to n=
ested
namespaces, you could easily produce filenames that transcend OS-specific=

limits on length of file names.
As the original post cited JAVA as an example: to be portable to some OSs=
, you
have to restrict the length of your JAVA package and class names.

If I understand the original poster's problem correctly, we need a way to=

specify "header file namespaces" in a way that would be portable to any
reasonable OS. The propasal to use =

 #include<outer_namespace::inner_namespace::headername.h>
would put insignificant limits on possible header file names (no '::'
allowed). But it would allow the mapping from such a directive to actual
on-disk structures (subdirectories or other) to be implementation defined=
=2E
This would put OS-dependency where it belongs - into the implementation i=
nstance.

-- J=F6rg
---
[ 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              ]

Joerg Barfurth <jbarfurth@vossnet.de> writes:

>AllanW {formerly AllanW@my-dejanews.com} wrote:
>
>> For compilers that do support subdirectory names, there's no reason
>> that vendors can't supply header files intended to be included that
>> way. This makes support for
>
>>     #include <rw/string.h>
>
>> so common that one can call it a de-facto standard. Other than a
>> minor syntax variance, this is identical to your proposal.
>
>But using slashes ('/') as path delimiters is still OS specific. For instance,
>using the same approach on MacOS would require something like #include
><rw:string.h>.

Not necessarily.  Another approach is to modify the compiler to support
using "/" as path delimiters in #include directives.  (This approach is
of course easier if you're using an open-source compiler ;-)

>The propasal to use
> #include<outer_namespace::inner_namespace::headername.h>
>[...] would allow the mapping from such a directive to actual
>on-disk structures (subdirectories or other) to be implementation defined.

The mapping between the names used in #include statement and filenames
is _already_ implementation defined [1].

References to the C++ standard:
[1] See 16.2 - Source file inclusion [cpp.include], paragraphs 2 and 3.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ 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 <slrn7gkifh.hq9.sbnaran@bardeen.ceg.uiuc.edu>,
  sbnaran@KILL.uiuc.edu wrote:
> I'm currently using
>    #include <vector> /* std header in namespace 'std' */
>    #include <myspace/fvector> /* my own header in namespace 'myspace' */
> This works on Egcs under Linux.  Does it work in MSVC under Windows?

Oh, yes. I suspect that this works on all *current* compilers which
are hosted on computers with named "directories" (or "folders" or
what have you).

But this is probably the very reason why a namespace-style solution
wasn't applied to header files. Given that we can't guarantee path
names, how can we hope to guarantee that an include file named
"stdio.h" won't conflict with the standard C version?

> The trick is to go with this directory layout
>    /usr/local/include/
>    /usr/local/include/myspace/           # empty directory
>    /usr/local/include/myspace/fvector    # header file
>
> In your Makefile, don't include the directory
> "/usr/local/include/myspace/", as then you would have to write
>    #include <fvector>
>
> Instead, include the directory "/usr/local/include/" and write
>    #inlcude <myspace/fvector>

This is usually known as "relative path" or something similar.
It's been used since the earliest UNIX days (for sys/xxx.h files),
so it should be emulated in most existing compilers.

The catch is that not all compilers are hosted on computers with
named paths. Even if these systems equate "translation unit" with
"source file" (which is not required), there is no requirement
that the "source files" have to have named paths. For instance,
old RSTS computers have one directory per logged-in account with
no subdirectories. I didn't use C back then, but I imagine that
they solved this problem by looking for
   #include "file.h"
in the current source directory and either
   #include <file.h>    or
   #include <sys/file.h>
in some other, specific directory that the administrator could
configure. Filename prefixes other than sys/ would either be
ignored, or would generate an error.

For programs that must be compatible on 100% of compliant compilers
(rather than just the 99% that have named paths), you are going to
have to select include files that don't conflict with standard C or
C++ (not too hard, there aren't that many of them!) or with
third-party vendors. That last part can get tricky, if you're a
library vendor yourself and trying to run on unknown platforms with
unknown other packages from unknown vendors. Naming tricks such as
"rwdate.h" can help with this.

----
Allan_W@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 <01be7f71$0d296040$7d9cd4c7@danielp.interlog.com>,
  "Daniel Parker" <danielp@no_spam.com> wrote:
> Articles and books by Koenig, Stroustrup and others discuss namepaces as if
> they solved the problem of name collisions.  However, they solve only half
> the problem.  Before the days of namespaces, careful library vendors not
> only named their classes RWString, but they either named their header files
> rwstring.h or used a relative pathname rw/string.h.  The problems of class
> name collisions and header filename collisions are two aspects of the same
> problem.
>
> In JAVA, names of classes and include files are treated symmetrically with
> the dot notation.  Did the standards committee ever consider supporting
>
> #include <namespace::headerfile>
>
> where "namespace::headerfile" could resolve into a relative pathname
> appropriate to the operating system, where "namespace" could be either the
> namespace name or an alias?

C++ compilers must already support this functionality in order to support
code with

    #include <sys/stat.h>

This is an old C-language header file, and even though it probably
isn't in the C standard (and therefore isn't incorporated by reference
into C++), processing this is mandatory for a compiler vendor that
wants to support old UNIX C programs. Since the name stat.h doesn't
collide with any standard header, a compiler vendor could support this
by simply ignoring anything before the slash character, but AFAIK no
compiler that's hosted on an OS with named subdirectories has ever
done it this way.

For compilers that do support subdirectory names, there's no reason
that vendors can't supply header files intended to be included that
way. This makes support for

    #include <rw/string.h>

so common that one can call it a de-facto standard. Other than a
minor syntax variance, this is identical to your proposal.

----
Allan_W@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              ]

Siemel Naran <sbnaran@bardeen.ceg.uiuc.edu> wrote in article
<slrn7gkifh.hq9.sbnaran@bardeen.ceg.uiuc.edu>...
>
> I'm currently using
>    #include <vector> /* std header in namespace 'std' */
>    #include <myspace/fvector> /* my own header in namespace 'myspace' */
> This works on Egcs under Linux.  Does it work in MSVC under Windows?

Yes.
>
This is more or less what we do, except we don't use the real namepace name
for reasons given below.  I find it interesting, though, that _none_ of the
articles or books I've read advocate this approach.  I've also observed
that this is rarely done in practice.

Lakos, in Large Scale C++ Software development, raises two objections to
doing so:

(i.)  In some implementations, compiler generated symbols with external
linkage are based on the file name.

(ii.)  On most systems, compile times are much faster when all header files
reside in a small number of directories (while a project could be organized
into a large number of namespaces.)

Also, some writers (Nathan Myers) have recommended using long namespace
names (unrelated to company names) with adornments to guarantee uniquenes,
which would make them unsuitable as names to use in include statements in
programs.  Being able to use aliases here would be nice, but that would
require language support.

Lastly, there is the issue of whether all operating system environments
would recognize "myspace/fvector.h."

Regards,
Daniel Parker danielp@no_spam.anabasis.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              ]

Articles and books by Koenig, Stroustrup and others discuss namepaces as if
they solved the problem of name collisions.  However, they solve only half
the problem.  Before the days of namespaces, careful library vendors not
only named their classes RWString, but they either named their header files
rwstring.h or used a relative pathname rw/string.h.  The problems of class
name collisions and header filename collisions are two aspects of the same
problem.

In JAVA, names of classes and include files are treated symmetrically with
the dot notation.  Did the standards committee ever consider supporting

#include <namespace::headerfile>

where "namespace::headerfile" could resolve into a relative pathname
appropriate to the operating system, where "namespace" could be either the
namespace name or an alias?  They must have at least discussed this issue,
since they would have faced the same problem in the standard library
itself, or at least they would have until the .h's got dropped from the new
header files, but that must have been for some other reason, right?

I'd be curious about what the aforementioned authors (and others) have in
mind about the problem of header file name clashes, how they would handle
that, what advise they would give.

Daniel Parker, danielp@no_spam.anabasis.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              ]

On 06 Apr 99 07:00:31 GMT, Daniel Parker <danielp@no_spam.com> wrote:

>Articles and books by Koenig, Stroustrup and others discuss namepaces as if
>they solved the problem of name collisions.  However, they solve only half
>the problem.  Before the days of namespaces, careful library vendors not
>only named their classes RWString, but they either named their header files
>rwstring.h or used a relative pathname rw/string.h.  The problems of class
>name collisions and header filename collisions are two aspects of the same
>problem.

At least they solved the larger half :).


>In JAVA, names of classes and include files are treated symmetrically with
>the dot notation.  Did the standards committee ever consider supporting
>
>#include <namespace::headerfile>

I'm currently using
   #include <vector> /* std header in namespace 'std' */
   #include <myspace/fvector> /* my own header in namespace 'myspace' */
This works on Egcs under Linux.  Does it work in MSVC under Windows?

The trick is to go with this directory layout
   /usr/local/include/
   /usr/local/include/myspace/           # empty directory
   /usr/local/include/myspace/fvector    # header file

In your Makefile, don't include the directory
"/usr/local/include/myspace/", as then you would have to write
   #include <fvector>

Instead, include the directory "/usr/local/include/" and write
   #inlcude <myspace/fvector>

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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              ]

The first thing that comes to mind is that the feature you describe is
already available if library vendors would use it:

#include <namespace/headerfile>




[ 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              ]