openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] use "" instead of <> for header?


From: Dennis Crowley
Subject: Re: [Openexr-devel] use "" instead of <> for header?
Date: Fri, 24 Feb 2006 20:01:54 -0800

As it appears, in this case that the standard is pretty much mute on the subject.
The next thing to consider would be the actual behavior on the supported platforms.
If the proposed change is helpful on one platform, and *at worst*, has no effect on the
others, and stays within the standard and accepted conventions, then it is certainly
worth considering.

Regarding convention, (which, of course, can be very subjective) I've always followed the convention
that "standard" includes always get <> and user and 3rd party includes always get "".
(what counts as "standard" is also subjective)

On another note, systemic changes are not to be undertaken lightly.

And of course, the maintainer's opinion trumps all.

My two cents.

Dennis.

(P.S. If this is too simple minded and dogmatic, I'd be happy to hear about it personally...
but please don't waste bandwidth on this mailing list... unless of course it pertains directly
to OpenExr. address@hidden)

On 2/23/06, Florian Kainz <address@hidden> wrote:
The C++ standard seems to say that, no matter if you include <foo>
or "foo", where compiler looks for foo is implementation-defined, and
"foo" may or may not behave the same way as <foo>.  The behavior you
want is not guaranteed.  According to section 16.2:

     A preprocessing directive of the form

         #include <h-char-sequence> new-line

     searches a sequence of implementation-defined places for a header
     identified uniquely by the specified sequence between the < and >
     delimiters [...]

     A preprocessing directive of the form

         #include <q-char-sequence> new-line

     causes the replacement of that directive by the entire contents
     of the source file identified by the specified sequence between
     the " delimiters.  The named source file is searched for in an
     implementation-defined manner if this search is not supported,
     or if the search fails, the directive is reprocessed as if it
     read

         #include <h-char-sequence> new-line

     [...]


Kai-Uwe Behrmann wrote:
> This is a request to exchange <> against "" in the public OpenEXR headers.
>
>
> The header files distributed with OpenEXR include each other with the
>
>   //OpenEXR header file
>   #include <name_of_other_exr_header.h>
>
> sheme. Thus the compiler searches in the global include search paths for
> the files. With this variant I need to fully specify the path on the
> compile line, which is extra work. I come with CinePaint compilation
> regularily around this stone, and users as well. But I think the OpenEXR
> headers should see each the other in a private sense and not a global
> one.
>
>
> Using "" instead would lead to searching in local paths:
>
>   // OpenEXR header file
>   #include "name_of_other_exr_header.h"
>
> Now the compiler finds the other OpenEXR headers from a base include
> path. There can reside many subdirectories which will be recognized, like
> for OpenEXR, FL (FLTK) or libexif.
> Thus one could simply include like follows in an application:
>
>   // my fancy app
>   #include <OpenEXR/ImfRgbaFile.h>
>
> + use one base include path on the compiler line and everything just
> works.
>
>
> regards
> Kai-Uwe Behrmann
>                                 + development for color management
>                                 + imaging / panoramas
>                                 + email: address@hidden
>                                 + http://www.behrmann.name
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>


_______________________________________________
Openexr-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/openexr-devel


reply via email to

[Prev in Thread] Current Thread [Next in Thread]