You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-users@xerces.apache.org by Javier Gálvez Guerrero <du...@gmail.com> on 2007/11/27 23:49:24 UTC
Including directive fails at compilation time
Hi everyone,
When I try to compile a C++ class with its includes in the .h header like
this:
#include <xercesc/dom/DOM.hpp>
#include <xercesc/dom/DOMImplementation.hpp>
#include <xercesc/dom/DOMImplementationLS.hpp>
#include <xercesc/dom/DOMWriter.hpp>
#include <xercesc/util/PlatformUtils.hpp>
The compiler fails saying there's no such file or directory. If I change <>
for "" the compiling error dissapears for these included files, but appear
for those included in them (for instance, DOMAttr.hpp). Actually, I think
that something is going wrong because <> should not be changed, but I am
unable to guess what I am doing wrong. Obviously, the xerces folder is where
it must be (so that the errors dissapear when <> are changed by "").
Can anybody help me, please?
Thank you very much,
Javi
Re: Including directive fails at compilation time
Posted by Vitaly Prapirny <ma...@mebius.net>.
David Bertoni wrote:
> Vitaly Prapirny wrote:
>> David Bertoni wrote:
>>> I'm not saying it would ever happen. I simply made a statement about
>>> what the C and C++ standards say a conforming implementation could do.
>>
>> That's your words: "Standard C++ reserves <> for system headers, and
>> Xerces-C violates that." But standard does not restrict <>-headers
>> to only system headers. All it says is that ""-headers are source files
>> only but <>-headers are not. Usage of the <> form is the common practice
>> in other libraries (look at the boost library for example).
>
> Yes, and I made it clear in subsequent posts that I wasn't clear about
> what I was trying to say.
>
> You also just said the standards makes the distinction between "headers"
> and "files." Since Xerces-C, which is not part of the implementation,
> uses "files," a conforming implementation might no be able to find
> Xerces-C's _files_ with #include<>. That was my point.
Yes, standard makes distinction between "header" and "file". "Header" is
broader concept than "file". "File" in #include is always "header", but
there could be "headers" that not "files". And #include<> should be able
to work with files because '#include "file"' fallback to '#include
<file>' according to the standard. And conforming implementation might
not be able to find Xerces-C's files with #include<> only because of
not searching in Xerces-C's folders but not because they are files. And
#include"" have the same imperfection.
> Whether it's "common practice" or not, code shouldn't rely on
> non-standard behavior to work. Especially when there's no tangible
> benefit from doing so.
I imply that it's "common practice" (and used in the boost library)
because it's standard conformant usage.
Good luck!
Vitaly
Re: Including directive fails at compilation time
Posted by David Bertoni <db...@apache.org>.
Vitaly Prapirny wrote:
> David Bertoni wrote:
>> I'm not saying it would ever happen. I simply made a statement about
>> what the C and C++ standards say a conforming implementation could do.
>
> That's your words: "Standard C++ reserves <> for system headers, and
> Xerces-C violates that." But standard does not restrict <>-headers
> to only system headers. All it says is that ""-headers are source files
> only but <>-headers are not. Usage of the <> form is the common practice
> in other libraries (look at the boost library for example).
Yes, and I made it clear in subsequent posts that I wasn't clear about what
I was trying to say.
You also just said the standards makes the distinction between "headers"
and "files." Since Xerces-C, which is not part of the implementation, uses
"files," a conforming implementation might no be able to find Xerces-C's
_files_ with #include<>. That was my point.
Whether it's "common practice" or not, code shouldn't rely on non-standard
behavior to work. Especially when there's no tangible benefit from doing so.
Dave
Re: Including directive fails at compilation time
Posted by Vitaly Prapirny <ma...@mebius.net>.
David Bertoni wrote:
> I'm not saying it would ever happen. I simply made a statement about
> what the C and C++ standards say a conforming implementation could do.
That's your words: "Standard C++ reserves <> for system headers, and
Xerces-C violates that." But standard does not restrict <>-headers
to only system headers. All it says is that ""-headers are source files
only but <>-headers are not. Usage of the <> form is the common practice
in other libraries (look at the boost library for example).
> You and Vitaly insisted that the algorithm you stated is somehow
> codified in the standard, and I stated that it's not.
That's my words: "(both search algorithms are implementation defined
according to the standard)". So no, I'm not insisted that the search
algorithm is somehow codified in the standard. Point of my all post was
that <> search doesn't fallback to "" search as Alberto said, but
quite opposite.
Good luck!
Vitaly
Re: Including directive fails at compilation time
Posted by David Bertoni <db...@apache.org>.
Alberto Massari wrote:
> Hi David,
> don't take it wrong, but my head is now spinning. My interpretation of
> this thread is that you are worried by the fact that a (unnamed, maybe
> not existent) compiler that interprets the C++ specs in a strict way
> would not be able to compile Xerces because it uses <> in the headers.
> Also, if Xerces used "", maybe this would not happen (I don't have the
> specs, so I cannot check what that "very different" section says).
I'm not saying it would ever happen. I simply made a statement about what
the C and C++ standards say a conforming implementation could do. You and
Vitaly insisted that the algorithm you stated is somehow codified in the
standard, and I stated that it's not.
In the past, I have experienced compilers that implemented different search
algorithms for #include<> and include "" and the solution was to simply
right the code with #include "" unless you're trying to get one of the
standard headers or a implementation-defined header.
>
> If this is true, who cares? Nobody ever complained about this compiler.
> Xerces used to be compiled on AS/400, that should potentially be one of
> these compilers, and it did have the <>-style includes...
I care, but I probably don't care enough to change the Xerces-C code. I
also wouldn't change it unless all the committers agreed that we should do it.
>
> Allow me to turn your "That's the point I was trying to make -- we are
> relying on implementation-defined behavior for no tangible benefit"
> question into:
>
> Why should we rewrite our headers for no tangible benefit, if the
> implementation-defined behavior for all the used compilers are fine with
> it?
Again, why are you assuming I'm saying we should do this? I never said
anything of the sort. I only pointed out that there's no tangible benefit
to use #include <> with non-implementation files, and you risk some
compiler in the future refusing to play with you if you do so.
Dave
Re: Including directive fails at compilation time
Posted by Alberto Massari <am...@datadirect.com>.
Jesse,
I agree that we should not write code that is not conforming with the
specs; but this can be said about the scope of variables declared in a
'for' loop, signed/unsigned, 32 vs 64 bit... here we are talking about
something that would break 99,99% of the existing C++ code, and such a
compiler would never be considered "conforming", but only "picky".
Anyhow, to close the discussion: Xerces needs people that write code to
fix its bugs, and replacing #include <...> with #include "..." is just
wasting their time (unless GCC 5.x, cl 14.x or CC 13.x change their mind).
Alberto
Jesse Pelton wrote:
> David may have a different answer, but as someone who spends a lot of
> time wrestling with the issues on the Web caused by the sort of
> reasoning you're using, I place a high value on code that conforms to
> specifications. It may not be of much benefit today, but it can save
> all kinds of trouble when you encounter some new processor of your code
> (whether C++, HTML, or something else). If you write code in accordance
> with the specification, you'll work with any new processor that
> correctly implements the specification. If your code relies on existing
> implementations as "de facto" standards, you're at the mercy of both
> incorrect existing processors and correct future processors.
>
> To paraphrase RFC 760: be liberal in what you accept, strict in what you
> write.
>
>
> -----Original Message-----
> From: Alberto Massari [mailto:amassari@datadirect.com]
> Sent: Thursday, November 29, 2007 10:39 AM
> To: c-users@xerces.apache.org
> Subject: Re: Including directive fails at compilation time
>
> Hi David,
> don't take it wrong, but my head is now spinning. My interpretation of
> this thread is that you are worried by the fact that a (unnamed, maybe
> not existent) compiler that interprets the C++ specs in a strict way
> would not be able to compile Xerces because it uses <> in the headers.
> Also, if Xerces used "", maybe this would not happen (I don't have the
> specs, so I cannot check what that "very different" section says).
>
> If this is true, who cares? Nobody ever complained about this compiler.
> Xerces used to be compiled on AS/400, that should potentially be one of
> these compilers, and it did have the <>-style includes...
>
> Allow me to turn your "That's the point I was trying to make -- we are
> relying on implementation-defined behavior for no tangible benefit"
> question into:
>
> Why should we rewrite our headers for no tangible benefit, if the
> implementation-defined behavior for all the used compilers are fine with
> it?
>
> Alberto
>
> David Bertoni wrote:
>
>> Alberto Massari wrote:
>>
>>> Hi David,
>>> I think you are interpreting the specs in a very strict way. As I
>>> read it, "it searches a sequence of implementation-defined places for
>>>
>
>
>>> a header" means that some compilers could look for an INCLUDE
>>> environment variable, or process a list of command line options like
>>> /I, or (like Borland) read the content of a bcc.cfg configuration
>>> file; but, regardless of the method each compiler chooses, there is a
>>>
>
>
>>> list of folders somewhere to search in.
>>>
>> You are reading it too liberally. Notice that user of the term
>> "header" rather than source file, and the fact that the standard uses
>> both the term "header" and "source file," and that "source file" is
>> never used in the section I quoted.
>>
>>
>>> As for recognizing only a fixed set of header names, that would be
>>> stupid; why have a set of folders where to search, if you only
>>> recognize string.h?
>>>
>> Why would it be stupid? Some platforms don't implement their system
>> headers as files.
>>
>>
>>> Anyhow, assuming there is a compiler that doesn't allow the
>>> specification of the "sequence of implementation-defined places" and
>>> so only allows for a predefined set of header names between the <>,
>>> the user would be forced to write in his CPP file something like
>>>
>>> #include "/usr/include/xercesc/dom/DOM.hpp"
>>>
>>> or
>>>
>>> #include "../../../xercesc/dom/DOM.hpp"
>>>
>> Not necessarily. You are conflating <> and "", but I was only talking
>>
>
>
>> about <>. The section in the standard for the #include "" directive
>> is very different.
>>
>>
>>> and I think you agree that a specification forcing such a
>>> preprocessor directive would be at minimum brain-dead and useless.
>>>
>> Limiting #include "" in the same way the standard allows limiting <>
>> would not be very useful, although it would still be compliant.
>> However, I'm not talking about the #include "" directive here at all.
>>
>
>
>> I didn't even quote that section of the standard.
>>
>> What I was saying is that Xerces-C uses #include<> to indicate the
>> implementation-defined behavior of "don't search in the current
>> directory of the source file." But that behavior is not guaranteed by
>>
>
>
>> the standard.
>>
>> We could change every #include<> directive in the source code to
>> #include "", and it wouldn't change anything, except make the code
>> more portable. That's the point I was trying to make -- we are relying
>>
>
>
>> on implementation-defined behavior for no tangible benefit.
>>
>> Dave
>>
>>
>
>
>
RE: Including directive fails at compilation time
Posted by Jesse Pelton <js...@PKC.com>.
David may have a different answer, but as someone who spends a lot of
time wrestling with the issues on the Web caused by the sort of
reasoning you're using, I place a high value on code that conforms to
specifications. It may not be of much benefit today, but it can save
all kinds of trouble when you encounter some new processor of your code
(whether C++, HTML, or something else). If you write code in accordance
with the specification, you'll work with any new processor that
correctly implements the specification. If your code relies on existing
implementations as "de facto" standards, you're at the mercy of both
incorrect existing processors and correct future processors.
To paraphrase RFC 760: be liberal in what you accept, strict in what you
write.
-----Original Message-----
From: Alberto Massari [mailto:amassari@datadirect.com]
Sent: Thursday, November 29, 2007 10:39 AM
To: c-users@xerces.apache.org
Subject: Re: Including directive fails at compilation time
Hi David,
don't take it wrong, but my head is now spinning. My interpretation of
this thread is that you are worried by the fact that a (unnamed, maybe
not existent) compiler that interprets the C++ specs in a strict way
would not be able to compile Xerces because it uses <> in the headers.
Also, if Xerces used "", maybe this would not happen (I don't have the
specs, so I cannot check what that "very different" section says).
If this is true, who cares? Nobody ever complained about this compiler.
Xerces used to be compiled on AS/400, that should potentially be one of
these compilers, and it did have the <>-style includes...
Allow me to turn your "That's the point I was trying to make -- we are
relying on implementation-defined behavior for no tangible benefit"
question into:
Why should we rewrite our headers for no tangible benefit, if the
implementation-defined behavior for all the used compilers are fine with
it?
Alberto
David Bertoni wrote:
> Alberto Massari wrote:
>> Hi David,
>> I think you are interpreting the specs in a very strict way. As I
>> read it, "it searches a sequence of implementation-defined places for
>> a header" means that some compilers could look for an INCLUDE
>> environment variable, or process a list of command line options like
>> /I, or (like Borland) read the content of a bcc.cfg configuration
>> file; but, regardless of the method each compiler chooses, there is a
>> list of folders somewhere to search in.
>
> You are reading it too liberally. Notice that user of the term
> "header" rather than source file, and the fact that the standard uses
> both the term "header" and "source file," and that "source file" is
> never used in the section I quoted.
>
>> As for recognizing only a fixed set of header names, that would be
>> stupid; why have a set of folders where to search, if you only
>> recognize string.h?
>
> Why would it be stupid? Some platforms don't implement their system
> headers as files.
>
>> Anyhow, assuming there is a compiler that doesn't allow the
>> specification of the "sequence of implementation-defined places" and
>> so only allows for a predefined set of header names between the <>,
>> the user would be forced to write in his CPP file something like
>>
>> #include "/usr/include/xercesc/dom/DOM.hpp"
>>
>> or
>>
>> #include "../../../xercesc/dom/DOM.hpp"
>
> Not necessarily. You are conflating <> and "", but I was only talking
> about <>. The section in the standard for the #include "" directive
> is very different.
>
>>
>> and I think you agree that a specification forcing such a
>> preprocessor directive would be at minimum brain-dead and useless.
>
> Limiting #include "" in the same way the standard allows limiting <>
> would not be very useful, although it would still be compliant.
> However, I'm not talking about the #include "" directive here at all.
> I didn't even quote that section of the standard.
>
> What I was saying is that Xerces-C uses #include<> to indicate the
> implementation-defined behavior of "don't search in the current
> directory of the source file." But that behavior is not guaranteed by
> the standard.
>
> We could change every #include<> directive in the source code to
> #include "", and it wouldn't change anything, except make the code
> more portable. That's the point I was trying to make -- we are relying
> on implementation-defined behavior for no tangible benefit.
>
> Dave
>
Re: Including directive fails at compilation time
Posted by Alberto Massari <am...@datadirect.com>.
Hi David,
don't take it wrong, but my head is now spinning. My interpretation of
this thread is that you are worried by the fact that a (unnamed, maybe
not existent) compiler that interprets the C++ specs in a strict way
would not be able to compile Xerces because it uses <> in the headers.
Also, if Xerces used "", maybe this would not happen (I don't have the
specs, so I cannot check what that "very different" section says).
If this is true, who cares? Nobody ever complained about this compiler.
Xerces used to be compiled on AS/400, that should potentially be one of
these compilers, and it did have the <>-style includes...
Allow me to turn your "That's the point I was trying to make -- we are
relying on implementation-defined behavior for no tangible benefit"
question into:
Why should we rewrite our headers for no tangible benefit, if the
implementation-defined behavior for all the used compilers are fine with it?
Alberto
David Bertoni wrote:
> Alberto Massari wrote:
>> Hi David,
>> I think you are interpreting the specs in a very strict way. As I
>> read it, "it searches a sequence of implementation-defined places for
>> a header" means that some compilers could look for an INCLUDE
>> environment variable, or process a list of command line options like
>> /I, or (like Borland) read the content of a bcc.cfg configuration
>> file; but, regardless of the method each compiler chooses, there is a
>> list of folders somewhere to search in.
>
> You are reading it too liberally. Notice that user of the term
> "header" rather than source file, and the fact that the standard uses
> both the term "header" and "source file," and that "source file" is
> never used in the section I quoted.
>
>> As for recognizing only a fixed set of header names, that would be
>> stupid; why have a set of folders where to search, if you only
>> recognize string.h?
>
> Why would it be stupid? Some platforms don't implement their system
> headers as files.
>
>> Anyhow, assuming there is a compiler that doesn't allow the
>> specification of the "sequence of implementation-defined places" and
>> so only allows for a predefined set of header names between the <>,
>> the user would be forced to write in his CPP file something like
>>
>> #include "/usr/include/xercesc/dom/DOM.hpp"
>>
>> or
>>
>> #include "../../../xercesc/dom/DOM.hpp"
>
> Not necessarily. You are conflating <> and "", but I was only talking
> about <>. The section in the standard for the #include "" directive
> is very different.
>
>>
>> and I think you agree that a specification forcing such a
>> preprocessor directive would be at minimum brain-dead and useless.
>
> Limiting #include "" in the same way the standard allows limiting <>
> would not be very useful, although it would still be compliant.
> However, I'm not talking about the #include "" directive here at all.
> I didn't even quote that section of the standard.
>
> What I was saying is that Xerces-C uses #include<> to indicate the
> implementation-defined behavior of "don't search in the current
> directory of the source file." But that behavior is not guaranteed by
> the standard.
>
> We could change every #include<> directive in the source code to
> #include "", and it wouldn't change anything, except make the code
> more portable. That's the point I was trying to make -- we are relying
> on implementation-defined behavior for no tangible benefit.
>
> Dave
>
Re: Including directive fails at compilation time
Posted by David Bertoni <db...@apache.org>.
Alberto Massari wrote:
> Hi David,
> I think you are interpreting the specs in a very strict way. As I read
> it, "it searches a sequence of implementation-defined places for a
> header" means that some compilers could look for an INCLUDE environment
> variable, or process a list of command line options like /I, or (like
> Borland) read the content of a bcc.cfg configuration file; but,
> regardless of the method each compiler chooses, there is a list of
> folders somewhere to search in.
You are reading it too liberally. Notice that user of the term "header"
rather than source file, and the fact that the standard uses both the term
"header" and "source file," and that "source file" is never used in the
section I quoted.
> As for recognizing only a fixed set of header names, that would be
> stupid; why have a set of folders where to search, if you only recognize
> string.h?
Why would it be stupid? Some platforms don't implement their system
headers as files.
> Anyhow, assuming there is a compiler that doesn't allow the
> specification of the "sequence of implementation-defined places" and so
> only allows for a predefined set of header names between the <>, the
> user would be forced to write in his CPP file something like
>
> #include "/usr/include/xercesc/dom/DOM.hpp"
>
> or
>
> #include "../../../xercesc/dom/DOM.hpp"
Not necessarily. You are conflating <> and "", but I was only talking
about <>. The section in the standard for the #include "" directive is
very different.
>
> and I think you agree that a specification forcing such a preprocessor
> directive would be at minimum brain-dead and useless.
Limiting #include "" in the same way the standard allows limiting <> would
not be very useful, although it would still be compliant. However, I'm not
talking about the #include "" directive here at all. I didn't even quote
that section of the standard.
What I was saying is that Xerces-C uses #include<> to indicate the
implementation-defined behavior of "don't search in the current directory
of the source file." But that behavior is not guaranteed by the standard.
We could change every #include<> directive in the source code to #include
"", and it wouldn't change anything, except make the code more portable.
That's the point I was trying to make -- we are relying on
implementation-defined behavior for no tangible benefit.
Dave
Re: Including directive fails at compilation time
Posted by Alberto Massari <am...@datadirect.com>.
Hi David,
I think you are interpreting the specs in a very strict way. As I read
it, "it searches a sequence of implementation-defined places for a
header" means that some compilers could look for an INCLUDE environment
variable, or process a list of command line options like /I, or (like
Borland) read the content of a bcc.cfg configuration file; but,
regardless of the method each compiler chooses, there is a list of
folders somewhere to search in.
As for recognizing only a fixed set of header names, that would be
stupid; why have a set of folders where to search, if you only recognize
string.h?
Anyhow, assuming there is a compiler that doesn't allow the
specification of the "sequence of implementation-defined places" and so
only allows for a predefined set of header names between the <>, the
user would be forced to write in his CPP file something like
#include "/usr/include/xercesc/dom/DOM.hpp"
or
#include "../../../xercesc/dom/DOM.hpp"
and I think you agree that a specification forcing such a preprocessor
directive would be at minimum brain-dead and useless.
Alberto
David Bertoni wrote:
> Alberto Massari wrote:
>> Hi David,
>> as far as I know, using #include "..." means "include this file using
>> the given path relative to the folder where the cpp file is located",
>> while using #include <...> means "do like before, and if you don't
>> find it, repeat the process with each folder specified in the INCLUDE
>> list". It is not reserved for system headers, and Xerces-C doesn't
>> violate any rule.
>
> What I meant to say is that when you use <>, it is
> implementation-defined what happens. That is to say, it is possible
> for an implementation refuse to process non-implementation files
> included using <>. Here's the relevant section of the C99 standard:
>
> "6.10.2 Source file inclusion
>
> Constraints
>
> 1 A #include directive shall identify a header or source file that can
> be processed by the implementation.
>
> Semantics
>
> 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, and causes the replacement of that directive by the entire
> contents of the header. How the places are specified or the header
> identified is implementation-defined."
>
> So a conforming implementation could do the following:
>
> 1. Not have any files for implementation-defined headers.
> 2. Recognize only the names of implementation-defined headers.
> 3. Do textual substitution of implementation-defined headers from
> hard-coded values.
> 4. Refuse to find anything that's not a implementation-defined header.
>
> Note that how places to search are specified, and the algorithm you
> stated are all implementation-defined. The only requirement provided
> by the standard is that if finding a file included by "" fails, the
> implementation reprocesses the include directive as if it we're done
> using <>.
>
> Although most compilers implement the algorithm you've stated, it's
> not a requirement. Given that, I don't see any value with using <>
> for user-defined headers.
>
> Dave
>
Re: Including directive fails at compilation time
Posted by David Bertoni <db...@apache.org>.
Alberto Massari wrote:
> Hi David,
> as far as I know, using #include "..." means "include this file using
> the given path relative to the folder where the cpp file is located",
> while using #include <...> means "do like before, and if you don't find
> it, repeat the process with each folder specified in the INCLUDE list".
> It is not reserved for system headers, and Xerces-C doesn't violate any
> rule.
What I meant to say is that when you use <>, it is implementation-defined
what happens. That is to say, it is possible for an implementation refuse
to process non-implementation files included using <>. Here's the relevant
section of the C99 standard:
"6.10.2 Source file inclusion
Constraints
1 A #include directive shall identify a header or source file that can be
processed by the implementation.
Semantics
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, and causes the replacement of that directive by the entire
contents of the header. How the places are specified or the header
identified is implementation-defined."
So a conforming implementation could do the following:
1. Not have any files for implementation-defined headers.
2. Recognize only the names of implementation-defined headers.
3. Do textual substitution of implementation-defined headers from
hard-coded values.
4. Refuse to find anything that's not a implementation-defined header.
Note that how places to search are specified, and the algorithm you stated
are all implementation-defined. The only requirement provided by the
standard is that if finding a file included by "" fails, the implementation
reprocesses the include directive as if it we're done using <>.
Although most compilers implement the algorithm you've stated, it's not a
requirement. Given that, I don't see any value with using <> for
user-defined headers.
Dave
Re: Including directive fails at compilation time
Posted by Javier Gálvez Guerrero <du...@gmail.com>.
You're right, I added it to Executable files. Now it's added to Include
files. Thanks again.
Javi
2007/11/28, Alberto Massari <am...@datadirect.com>:
>
> Javier Gálvez Guerrero wrote:
> > Javier must add the proper directory to the project settings (Project |
> > Properties | C/C++ | General | Additional Include Directories) or
> > globally (Tools | Options | Projects and Solutions | VC++ Directories ->
> > Include Files and Library files)
> >
> > I had only included it the second way you explained here. Now I have
> checked
> > the second one and it works fine. Thank you all.
> >
> The global setting should have worked too; are you sure you selected
> "Include Files" from the combo box before adding the entry to the
> existing list (when you open the page, the Executable files is selected)?
>
> Alberto
> > Cheers,
> > Javi
> >
> > PS: Nice to see there is people that like expanding the community and
> > helping each other even with these newbie questions...=)
> >
> >
> > 2007/11/28, Vitaly Prapirny <ma...@mebius.net>:
> >
> >> Hi,
> >> Alberto Massari wrote:
> >>
> >>> Hi David,
> >>> as far as I know, using #include "..." means "include this file using
> >>> the given path relative to the folder where the cpp file is located",
> >>> while using #include <...> means "do like before, and if you don't
> find
> >>> it, repeat the process with each folder specified in the INCLUDE
> list".
> >>>
> >> Quite the opposite, "..." search fallback to <...> if the file has not
> >> been found (both search algorithms are implementation defined according
> >> to the standard). I.e. "..." uses current file folder first and INCLUDE
> >> list next but <...> uses the INCLUDE list only.
> >>
> >>> It is not reserved for system headers, and Xerces-C doesn't violate
> any
> >>> rule.
> >>>
> >> Agreed.
> >>
> >> Good luck!
> >> Vitaly
> >>
> >>
> >
> >
>
>
Re: Including directive fails at compilation time
Posted by Alberto Massari <am...@datadirect.com>.
Javier Gálvez Guerrero wrote:
> Javier must add the proper directory to the project settings (Project |
> Properties | C/C++ | General | Additional Include Directories) or
> globally (Tools | Options | Projects and Solutions | VC++ Directories ->
> Include Files and Library files)
>
> I had only included it the second way you explained here. Now I have checked
> the second one and it works fine. Thank you all.
>
The global setting should have worked too; are you sure you selected
"Include Files" from the combo box before adding the entry to the
existing list (when you open the page, the Executable files is selected)?
Alberto
> Cheers,
> Javi
>
> PS: Nice to see there is people that like expanding the community and
> helping each other even with these newbie questions...=)
>
>
> 2007/11/28, Vitaly Prapirny <ma...@mebius.net>:
>
>> Hi,
>> Alberto Massari wrote:
>>
>>> Hi David,
>>> as far as I know, using #include "..." means "include this file using
>>> the given path relative to the folder where the cpp file is located",
>>> while using #include <...> means "do like before, and if you don't find
>>> it, repeat the process with each folder specified in the INCLUDE list".
>>>
>> Quite the opposite, "..." search fallback to <...> if the file has not
>> been found (both search algorithms are implementation defined according
>> to the standard). I.e. "..." uses current file folder first and INCLUDE
>> list next but <...> uses the INCLUDE list only.
>>
>>> It is not reserved for system headers, and Xerces-C doesn't violate any
>>> rule.
>>>
>> Agreed.
>>
>> Good luck!
>> Vitaly
>>
>>
>
>
Re: Including directive fails at compilation time
Posted by Javier Gálvez Guerrero <du...@gmail.com>.
Javier must add the proper directory to the project settings (Project |
Properties | C/C++ | General | Additional Include Directories) or
globally (Tools | Options | Projects and Solutions | VC++ Directories ->
Include Files and Library files)
I had only included it the second way you explained here. Now I have checked
the second one and it works fine. Thank you all.
Cheers,
Javi
PS: Nice to see there is people that like expanding the community and
helping each other even with these newbie questions...=)
2007/11/28, Vitaly Prapirny <ma...@mebius.net>:
>
> Hi,
> Alberto Massari wrote:
> > Hi David,
> > as far as I know, using #include "..." means "include this file using
> > the given path relative to the folder where the cpp file is located",
> > while using #include <...> means "do like before, and if you don't find
> > it, repeat the process with each folder specified in the INCLUDE list".
> Quite the opposite, "..." search fallback to <...> if the file has not
> been found (both search algorithms are implementation defined according
> to the standard). I.e. "..." uses current file folder first and INCLUDE
> list next but <...> uses the INCLUDE list only.
> > It is not reserved for system headers, and Xerces-C doesn't violate any
> > rule.
> Agreed.
>
> Good luck!
> Vitaly
>
Re: Including directive fails at compilation time
Posted by Vitaly Prapirny <ma...@mebius.net>.
Hi,
Alberto Massari wrote:
> Hi David,
> as far as I know, using #include "..." means "include this file using
> the given path relative to the folder where the cpp file is located",
> while using #include <...> means "do like before, and if you don't find
> it, repeat the process with each folder specified in the INCLUDE list".
Quite the opposite, "..." search fallback to <...> if the file has not
been found (both search algorithms are implementation defined according
to the standard). I.e. "..." uses current file folder first and INCLUDE
list next but <...> uses the INCLUDE list only.
> It is not reserved for system headers, and Xerces-C doesn't violate any
> rule.
Agreed.
Good luck!
Vitaly
Re: Including directive fails at compilation time
Posted by Alberto Massari <am...@datadirect.com>.
Hi David,
as far as I know, using #include "..." means "include this file using
the given path relative to the folder where the cpp file is located",
while using #include <...> means "do like before, and if you don't find
it, repeat the process with each folder specified in the INCLUDE list".
It is not reserved for system headers, and Xerces-C doesn't violate any
rule.
Javier must add the proper directory to the project settings (Project |
Properties | C/C++ | General | Additional Include Directories) or
globally (Tools | Options | Projects and Solutions | VC++ Directories ->
Include Files and Library files)
Alberto
David Bertoni wrote:
> Javier Gálvez Guerrero wrote:
>> Hi everyone,
>>
>> When I try to compile a C++ class with its includes in the .h header
>> like
>> this:
>>
>> #include <xercesc/dom/DOM.hpp>
>> #include <xercesc/dom/DOMImplementation.hpp>
>> #include <xercesc/dom/DOMImplementationLS.hpp>
>> #include <xercesc/dom/DOMWriter.hpp>
>> #include <xercesc/util/PlatformUtils.hpp>
>>
>> The compiler fails saying there's no such file or directory. If I
>> change <>
>> for "" the compiling error dissapears for these included files, but
>> appear
>> for those included in them (for instance, DOMAttr.hpp). Actually, I
>> think
>> that something is going wrong because <> should not be changed, but I am
>> unable to guess what I am doing wrong. Obviously, the xerces folder
>> is where
>> it must be (so that the errors dissapear when <> are changed by "").
>>
>> Can anybody help me, please?
> Note that all files should be included using "" and not <>. Standard
> C++ reserves <> for system headers, and Xerces-C violates that.
>
> This is likely happening because you built the binaries but did not
> build an official distribution, or you have the include path messed
> up. Please supply more information about your compiler and
> development environment.
>
> Dave
>
Re: Including directive fails at compilation time
Posted by Alberto Massari <am...@datadirect.com>.
Javier,
if you had added the path to xerces_2_8/include there would be a /I
".../xerces_2_8/include" option in the first command line; double check
that you added it in the correct place
Alberto
Javier Gálvez Guerrero wrote:
> Sure, here it goes:
>
>
> Registro de la generación (generation register)
>
>
> Se inició Versión de compilación: proyecto: contents_manager,
> configuración: Debug|Win32
>
> Líneas de comandos (command line)
>
>
> Creando archivo temporal "d:\Ser teleco
> mola\IPTV\Aplicación\Desarrollo\dIPTV\contents_manager\Debug\RSP00000628204246032.rsp"
> con contenido
> [
> /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE"
> /FD /EHa /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /c /Wp64 /Zi /clr
> /TP ".\contents_manager.cpp"
> ]
> Creando línea de comandos "cl.exe @"d:\Ser teleco
> mola\IPTV\Aplicación\Desarrollo\dIPTV\contents_manager\Debug\RSP00000628204246032.rsp"
> /nologo /errorReport:prompt"
>
> Ventana Resultados (results window)
>
>
> Compilando...
> contents_manager.cpp
> d:\ser teleco mola\iptv\aplicación\desarrollo\diptv\contents_manager\contents_manager.h(3)
> : fatal error C1083: No se puede abrir el archivo incluir:
> 'xercesc/dom/DOM.hpp': No such file or directory
>
> Resultados (results)
>
>
> El registro de generación se guardó en el "file://d:\Ser teleco
> mola\IPTV\Aplicación\Desarrollo\dIPTV\contents_manager\Debug\BuildLog.htm"
> contents_manager - 1 errores, 0 advertencias
>
>
> Hope this helps,
> Javi
>
>
> 2007/11/28, Alberto Massari <am...@datadirect.com>:
>
>> Javier,
>> can you post the error log? Or, even better, the BuildLog.htm that the
>> IDE should have generated?
>>
>> Alberto
>>
>> Javier Gálvez Guerrero wrote:
>>
>>> Alberto,
>>> David probably could not help me because I did not say which compiler I
>>>
>> was
>>
>>> using.
>>> Anyway, I have changed the support for CLR and this worked perfectly,
>>>
>> but I
>>
>>> have the same problem although I have added the path as you said.
>>>
>>> The fact is that I have added the path to .../xercesc_2_8_0/include (the
>>> folder name xercesc_2_8_0 has been changed by myself). Then, these
>>>
>> includes
>>
>>> should work, shouldn't them?
>>>
>>> #include <xercesc/dom/DOM.hpp>
>>> #include <xercesc/dom/DOMImplementation.hpp>
>>> #include <xercesc/dom/DOMImplementationLS.hpp>
>>> #include <xercesc/dom/DOMWriter.hpp>
>>> #include <xercesc/util/PlatformUtils.hpp>
>>>
>>> However, the same error is still appearing (No such file or directory).
>>>
>> Am I
>>
>>> doing it properly?
>>>
>>> Thanks again for your help and sorry for my insistence and ignorance.
>>> Javi
>>>
>>> 2007/11/28, Alberto Massari <am...@datadirect.com>:
>>>
>>>
>>>> Javier,
>>>> the System namespace is part of the .NET framework, so you need to tell
>>>> the C++ compiler to generate managed code (Project | Properties |
>>>> General | Common Language Runtime support = /clr).
>>>>
>>>> Alberto
>>>>
>>>> Javier Gálvez Guerrero wrote:
>>>>
>>>>
>>>>> I am using the Microsoft Visual C++ 2005 Express IDE. Then, must I
>>>>>
>>>>>
>>>> change <>
>>>>
>>>>
>>>>> by "" in ALL Xerces files?
>>>>>
>>>>> Neither I can not understand why the compiler finds an error with the
>>>>>
>>>>>
>>>> using
>>>>
>>>>
>>>>> directive "using namespace System", because I need to use DateTime and
>>>>> TimeSpan and these are supposed to be included in System, but when I
>>>>>
>> try
>>
>>>> to
>>>>
>>>>
>>>>> compile it fails.I don't know if this has anything to do with the
>>>>>
>>>>>
>>>> previous
>>>>
>>>>
>>>>> problem.
>>>>>
>>>>> Thank you a lot for your answers,
>>>>> Javi
>>>>>
>>>>>
>>>>> 2007/11/27, David Bertoni <db...@apache.org>:
>>>>>
>>>>>
>>>>>
>>>>>> Javier Gálvez Guerrero wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> When I try to compile a C++ class with its includes in the .h header
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> like
>>>>>>
>>>>>>
>>>>>>
>>>>>>> this:
>>>>>>>
>>>>>>> #include <xercesc/dom/DOM.hpp>
>>>>>>> #include <xercesc/dom/DOMImplementation.hpp>
>>>>>>> #include <xercesc/dom/DOMImplementationLS.hpp>
>>>>>>> #include <xercesc/dom/DOMWriter.hpp>
>>>>>>> #include <xercesc/util/PlatformUtils.hpp>
>>>>>>>
>>>>>>> The compiler fails saying there's no such file or directory. If I
>>>>>>>
>>>>>>>
>>>> change
>>>>
>>>>
>>>>>> <>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> for "" the compiling error dissapears for these included files, but
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> appear
>>>>>>
>>>>>>
>>>>>>
>>>>>>> for those included in them (for instance, DOMAttr.hpp). Actually, I
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> think
>>>>>>
>>>>>>
>>>>>>
>>>>>>> that something is going wrong because <> should not be changed, but
>>>>>>>
>> I
>>
>>>> am
>>>>
>>>>
>>>>>>> unable to guess what I am doing wrong. Obviously, the xerces folder
>>>>>>>
>> is
>>
>>>>>>>
>>>>>> where
>>>>>>
>>>>>>
>>>>>>
>>>>>>> it must be (so that the errors dissapear when <> are changed by "").
>>>>>>>
>>>>>>> Can anybody help me, please?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Note that all files should be included using "" and not <>. Standard
>>>>>>
>>>>>>
>>>> C++
>>>>
>>>>
>>>>>> reserves <> for system headers, and Xerces-C violates that.
>>>>>>
>>>>>> This is likely happening because you built the binaries but did not
>>>>>>
>>>>>>
>>>> build
>>>>
>>>>
>>>>>> an official distribution, or you have the include path messed
>>>>>>
>>>>>>
>>>> up. Please
>>>>
>>>>
>>>>>> supply more information about your compiler and development
>>>>>>
>>>>>>
>>>> environment.
>>>>
>>>>
>>>>>> Dave
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>
>
>
Re: Including directive fails at compilation time
Posted by Javier Gálvez Guerrero <du...@gmail.com>.
Sure, here it goes:
Registro de la generación (generation register)
Se inició Versión de compilación: proyecto: contents_manager,
configuración: Debug|Win32
Líneas de comandos (command line)
Creando archivo temporal "d:\Ser teleco
mola\IPTV\Aplicación\Desarrollo\dIPTV\contents_manager\Debug\RSP00000628204246032.rsp"
con contenido
[
/Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE"
/FD /EHa /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /c /Wp64 /Zi /clr
/TP ".\contents_manager.cpp"
]
Creando línea de comandos "cl.exe @"d:\Ser teleco
mola\IPTV\Aplicación\Desarrollo\dIPTV\contents_manager\Debug\RSP00000628204246032.rsp"
/nologo /errorReport:prompt"
Ventana Resultados (results window)
Compilando...
contents_manager.cpp
d:\ser teleco mola\iptv\aplicación\desarrollo\diptv\contents_manager\contents_manager.h(3)
: fatal error C1083: No se puede abrir el archivo incluir:
'xercesc/dom/DOM.hpp': No such file or directory
Resultados (results)
El registro de generación se guardó en el "file://d:\Ser teleco
mola\IPTV\Aplicación\Desarrollo\dIPTV\contents_manager\Debug\BuildLog.htm"
contents_manager - 1 errores, 0 advertencias
Hope this helps,
Javi
2007/11/28, Alberto Massari <am...@datadirect.com>:
>
> Javier,
> can you post the error log? Or, even better, the BuildLog.htm that the
> IDE should have generated?
>
> Alberto
>
> Javier Gálvez Guerrero wrote:
> > Alberto,
> > David probably could not help me because I did not say which compiler I
> was
> > using.
> > Anyway, I have changed the support for CLR and this worked perfectly,
> but I
> > have the same problem although I have added the path as you said.
> >
> > The fact is that I have added the path to .../xercesc_2_8_0/include (the
> > folder name xercesc_2_8_0 has been changed by myself). Then, these
> includes
> > should work, shouldn't them?
> >
> > #include <xercesc/dom/DOM.hpp>
> > #include <xercesc/dom/DOMImplementation.hpp>
> > #include <xercesc/dom/DOMImplementationLS.hpp>
> > #include <xercesc/dom/DOMWriter.hpp>
> > #include <xercesc/util/PlatformUtils.hpp>
> >
> > However, the same error is still appearing (No such file or directory).
> Am I
> > doing it properly?
> >
> > Thanks again for your help and sorry for my insistence and ignorance.
> > Javi
> >
> > 2007/11/28, Alberto Massari <am...@datadirect.com>:
> >
> >> Javier,
> >> the System namespace is part of the .NET framework, so you need to tell
> >> the C++ compiler to generate managed code (Project | Properties |
> >> General | Common Language Runtime support = /clr).
> >>
> >> Alberto
> >>
> >> Javier Gálvez Guerrero wrote:
> >>
> >>> I am using the Microsoft Visual C++ 2005 Express IDE. Then, must I
> >>>
> >> change <>
> >>
> >>> by "" in ALL Xerces files?
> >>>
> >>> Neither I can not understand why the compiler finds an error with the
> >>>
> >> using
> >>
> >>> directive "using namespace System", because I need to use DateTime and
> >>> TimeSpan and these are supposed to be included in System, but when I
> try
> >>>
> >> to
> >>
> >>> compile it fails.I don't know if this has anything to do with the
> >>>
> >> previous
> >>
> >>> problem.
> >>>
> >>> Thank you a lot for your answers,
> >>> Javi
> >>>
> >>>
> >>> 2007/11/27, David Bertoni <db...@apache.org>:
> >>>
> >>>
> >>>> Javier Gálvez Guerrero wrote:
> >>>>
> >>>>
> >>>>> Hi everyone,
> >>>>>
> >>>>> When I try to compile a C++ class with its includes in the .h header
> >>>>>
> >>>>>
> >>>> like
> >>>>
> >>>>
> >>>>> this:
> >>>>>
> >>>>> #include <xercesc/dom/DOM.hpp>
> >>>>> #include <xercesc/dom/DOMImplementation.hpp>
> >>>>> #include <xercesc/dom/DOMImplementationLS.hpp>
> >>>>> #include <xercesc/dom/DOMWriter.hpp>
> >>>>> #include <xercesc/util/PlatformUtils.hpp>
> >>>>>
> >>>>> The compiler fails saying there's no such file or directory. If I
> >>>>>
> >> change
> >>
> >>>> <>
> >>>>
> >>>>
> >>>>> for "" the compiling error dissapears for these included files, but
> >>>>>
> >>>>>
> >>>> appear
> >>>>
> >>>>
> >>>>> for those included in them (for instance, DOMAttr.hpp). Actually, I
> >>>>>
> >>>>>
> >>>> think
> >>>>
> >>>>
> >>>>> that something is going wrong because <> should not be changed, but
> I
> >>>>>
> >> am
> >>
> >>>>> unable to guess what I am doing wrong. Obviously, the xerces folder
> is
> >>>>>
> >>>>>
> >>>> where
> >>>>
> >>>>
> >>>>> it must be (so that the errors dissapear when <> are changed by "").
> >>>>>
> >>>>> Can anybody help me, please?
> >>>>>
> >>>>>
> >>>> Note that all files should be included using "" and not <>. Standard
> >>>>
> >> C++
> >>
> >>>> reserves <> for system headers, and Xerces-C violates that.
> >>>>
> >>>> This is likely happening because you built the binaries but did not
> >>>>
> >> build
> >>
> >>>> an official distribution, or you have the include path messed
> >>>>
> >> up. Please
> >>
> >>>> supply more information about your compiler and development
> >>>>
> >> environment.
> >>
> >>>> Dave
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >
>
>
Re: Including directive fails at compilation time
Posted by Alberto Massari <am...@datadirect.com>.
Javier,
can you post the error log? Or, even better, the BuildLog.htm that the
IDE should have generated?
Alberto
Javier Gálvez Guerrero wrote:
> Alberto,
> David probably could not help me because I did not say which compiler I was
> using.
> Anyway, I have changed the support for CLR and this worked perfectly, but I
> have the same problem although I have added the path as you said.
>
> The fact is that I have added the path to .../xercesc_2_8_0/include (the
> folder name xercesc_2_8_0 has been changed by myself). Then, these includes
> should work, shouldn't them?
>
> #include <xercesc/dom/DOM.hpp>
> #include <xercesc/dom/DOMImplementation.hpp>
> #include <xercesc/dom/DOMImplementationLS.hpp>
> #include <xercesc/dom/DOMWriter.hpp>
> #include <xercesc/util/PlatformUtils.hpp>
>
> However, the same error is still appearing (No such file or directory). Am I
> doing it properly?
>
> Thanks again for your help and sorry for my insistence and ignorance.
> Javi
>
> 2007/11/28, Alberto Massari <am...@datadirect.com>:
>
>> Javier,
>> the System namespace is part of the .NET framework, so you need to tell
>> the C++ compiler to generate managed code (Project | Properties |
>> General | Common Language Runtime support = /clr).
>>
>> Alberto
>>
>> Javier Gálvez Guerrero wrote:
>>
>>> I am using the Microsoft Visual C++ 2005 Express IDE. Then, must I
>>>
>> change <>
>>
>>> by "" in ALL Xerces files?
>>>
>>> Neither I can not understand why the compiler finds an error with the
>>>
>> using
>>
>>> directive "using namespace System", because I need to use DateTime and
>>> TimeSpan and these are supposed to be included in System, but when I try
>>>
>> to
>>
>>> compile it fails.I don't know if this has anything to do with the
>>>
>> previous
>>
>>> problem.
>>>
>>> Thank you a lot for your answers,
>>> Javi
>>>
>>>
>>> 2007/11/27, David Bertoni <db...@apache.org>:
>>>
>>>
>>>> Javier Gálvez Guerrero wrote:
>>>>
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> When I try to compile a C++ class with its includes in the .h header
>>>>>
>>>>>
>>>> like
>>>>
>>>>
>>>>> this:
>>>>>
>>>>> #include <xercesc/dom/DOM.hpp>
>>>>> #include <xercesc/dom/DOMImplementation.hpp>
>>>>> #include <xercesc/dom/DOMImplementationLS.hpp>
>>>>> #include <xercesc/dom/DOMWriter.hpp>
>>>>> #include <xercesc/util/PlatformUtils.hpp>
>>>>>
>>>>> The compiler fails saying there's no such file or directory. If I
>>>>>
>> change
>>
>>>> <>
>>>>
>>>>
>>>>> for "" the compiling error dissapears for these included files, but
>>>>>
>>>>>
>>>> appear
>>>>
>>>>
>>>>> for those included in them (for instance, DOMAttr.hpp). Actually, I
>>>>>
>>>>>
>>>> think
>>>>
>>>>
>>>>> that something is going wrong because <> should not be changed, but I
>>>>>
>> am
>>
>>>>> unable to guess what I am doing wrong. Obviously, the xerces folder is
>>>>>
>>>>>
>>>> where
>>>>
>>>>
>>>>> it must be (so that the errors dissapear when <> are changed by "").
>>>>>
>>>>> Can anybody help me, please?
>>>>>
>>>>>
>>>> Note that all files should be included using "" and not <>. Standard
>>>>
>> C++
>>
>>>> reserves <> for system headers, and Xerces-C violates that.
>>>>
>>>> This is likely happening because you built the binaries but did not
>>>>
>> build
>>
>>>> an official distribution, or you have the include path messed
>>>>
>> up. Please
>>
>>>> supply more information about your compiler and development
>>>>
>> environment.
>>
>>>> Dave
>>>>
>>>>
>>>>
>>>
>>
>
>
Re: Including directive fails at compilation time
Posted by Javier Gálvez Guerrero <du...@gmail.com>.
Alberto,
David probably could not help me because I did not say which compiler I was
using.
Anyway, I have changed the support for CLR and this worked perfectly, but I
have the same problem although I have added the path as you said.
The fact is that I have added the path to .../xercesc_2_8_0/include (the
folder name xercesc_2_8_0 has been changed by myself). Then, these includes
should work, shouldn't them?
#include <xercesc/dom/DOM.hpp>
#include <xercesc/dom/DOMImplementation.hpp>
#include <xercesc/dom/DOMImplementationLS.hpp>
#include <xercesc/dom/DOMWriter.hpp>
#include <xercesc/util/PlatformUtils.hpp>
However, the same error is still appearing (No such file or directory). Am I
doing it properly?
Thanks again for your help and sorry for my insistence and ignorance.
Javi
2007/11/28, Alberto Massari <am...@datadirect.com>:
>
> Javier,
> the System namespace is part of the .NET framework, so you need to tell
> the C++ compiler to generate managed code (Project | Properties |
> General | Common Language Runtime support = /clr).
>
> Alberto
>
> Javier Gálvez Guerrero wrote:
> > I am using the Microsoft Visual C++ 2005 Express IDE. Then, must I
> change <>
> > by "" in ALL Xerces files?
> >
> > Neither I can not understand why the compiler finds an error with the
> using
> > directive "using namespace System", because I need to use DateTime and
> > TimeSpan and these are supposed to be included in System, but when I try
> to
> > compile it fails.I don't know if this has anything to do with the
> previous
> > problem.
> >
> > Thank you a lot for your answers,
> > Javi
> >
> >
> > 2007/11/27, David Bertoni <db...@apache.org>:
> >
> >> Javier Gálvez Guerrero wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> When I try to compile a C++ class with its includes in the .h header
> >>>
> >> like
> >>
> >>> this:
> >>>
> >>> #include <xercesc/dom/DOM.hpp>
> >>> #include <xercesc/dom/DOMImplementation.hpp>
> >>> #include <xercesc/dom/DOMImplementationLS.hpp>
> >>> #include <xercesc/dom/DOMWriter.hpp>
> >>> #include <xercesc/util/PlatformUtils.hpp>
> >>>
> >>> The compiler fails saying there's no such file or directory. If I
> change
> >>>
> >> <>
> >>
> >>> for "" the compiling error dissapears for these included files, but
> >>>
> >> appear
> >>
> >>> for those included in them (for instance, DOMAttr.hpp). Actually, I
> >>>
> >> think
> >>
> >>> that something is going wrong because <> should not be changed, but I
> am
> >>> unable to guess what I am doing wrong. Obviously, the xerces folder is
> >>>
> >> where
> >>
> >>> it must be (so that the errors dissapear when <> are changed by "").
> >>>
> >>> Can anybody help me, please?
> >>>
> >> Note that all files should be included using "" and not <>. Standard
> C++
> >> reserves <> for system headers, and Xerces-C violates that.
> >>
> >> This is likely happening because you built the binaries but did not
> build
> >> an official distribution, or you have the include path messed
> up. Please
> >> supply more information about your compiler and development
> environment.
> >>
> >> Dave
> >>
> >>
> >
> >
>
>
Re: Including directive fails at compilation time
Posted by Alberto Massari <am...@datadirect.com>.
Javier,
the System namespace is part of the .NET framework, so you need to tell
the C++ compiler to generate managed code (Project | Properties |
General | Common Language Runtime support = /clr).
Alberto
Javier Gálvez Guerrero wrote:
> I am using the Microsoft Visual C++ 2005 Express IDE. Then, must I change <>
> by "" in ALL Xerces files?
>
> Neither I can not understand why the compiler finds an error with the using
> directive "using namespace System", because I need to use DateTime and
> TimeSpan and these are supposed to be included in System, but when I try to
> compile it fails.I don't know if this has anything to do with the previous
> problem.
>
> Thank you a lot for your answers,
> Javi
>
>
> 2007/11/27, David Bertoni <db...@apache.org>:
>
>> Javier Gálvez Guerrero wrote:
>>
>>> Hi everyone,
>>>
>>> When I try to compile a C++ class with its includes in the .h header
>>>
>> like
>>
>>> this:
>>>
>>> #include <xercesc/dom/DOM.hpp>
>>> #include <xercesc/dom/DOMImplementation.hpp>
>>> #include <xercesc/dom/DOMImplementationLS.hpp>
>>> #include <xercesc/dom/DOMWriter.hpp>
>>> #include <xercesc/util/PlatformUtils.hpp>
>>>
>>> The compiler fails saying there's no such file or directory. If I change
>>>
>> <>
>>
>>> for "" the compiling error dissapears for these included files, but
>>>
>> appear
>>
>>> for those included in them (for instance, DOMAttr.hpp). Actually, I
>>>
>> think
>>
>>> that something is going wrong because <> should not be changed, but I am
>>> unable to guess what I am doing wrong. Obviously, the xerces folder is
>>>
>> where
>>
>>> it must be (so that the errors dissapear when <> are changed by "").
>>>
>>> Can anybody help me, please?
>>>
>> Note that all files should be included using "" and not <>. Standard C++
>> reserves <> for system headers, and Xerces-C violates that.
>>
>> This is likely happening because you built the binaries but did not build
>> an official distribution, or you have the include path messed up. Please
>> supply more information about your compiler and development environment.
>>
>> Dave
>>
>>
>
>
Re: Including directive fails at compilation time
Posted by Javier Gálvez Guerrero <du...@gmail.com>.
I am using the Microsoft Visual C++ 2005 Express IDE. Then, must I change <>
by "" in ALL Xerces files?
Neither I can not understand why the compiler finds an error with the using
directive "using namespace System", because I need to use DateTime and
TimeSpan and these are supposed to be included in System, but when I try to
compile it fails.I don't know if this has anything to do with the previous
problem.
Thank you a lot for your answers,
Javi
2007/11/27, David Bertoni <db...@apache.org>:
>
> Javier Gálvez Guerrero wrote:
> > Hi everyone,
> >
> > When I try to compile a C++ class with its includes in the .h header
> like
> > this:
> >
> > #include <xercesc/dom/DOM.hpp>
> > #include <xercesc/dom/DOMImplementation.hpp>
> > #include <xercesc/dom/DOMImplementationLS.hpp>
> > #include <xercesc/dom/DOMWriter.hpp>
> > #include <xercesc/util/PlatformUtils.hpp>
> >
> > The compiler fails saying there's no such file or directory. If I change
> <>
> > for "" the compiling error dissapears for these included files, but
> appear
> > for those included in them (for instance, DOMAttr.hpp). Actually, I
> think
> > that something is going wrong because <> should not be changed, but I am
> > unable to guess what I am doing wrong. Obviously, the xerces folder is
> where
> > it must be (so that the errors dissapear when <> are changed by "").
> >
> > Can anybody help me, please?
> Note that all files should be included using "" and not <>. Standard C++
> reserves <> for system headers, and Xerces-C violates that.
>
> This is likely happening because you built the binaries but did not build
> an official distribution, or you have the include path messed up. Please
> supply more information about your compiler and development environment.
>
> Dave
>
Re: Including directive fails at compilation time
Posted by David Bertoni <db...@apache.org>.
Javier Gálvez Guerrero wrote:
> Hi everyone,
>
> When I try to compile a C++ class with its includes in the .h header like
> this:
>
> #include <xercesc/dom/DOM.hpp>
> #include <xercesc/dom/DOMImplementation.hpp>
> #include <xercesc/dom/DOMImplementationLS.hpp>
> #include <xercesc/dom/DOMWriter.hpp>
> #include <xercesc/util/PlatformUtils.hpp>
>
> The compiler fails saying there's no such file or directory. If I change <>
> for "" the compiling error dissapears for these included files, but appear
> for those included in them (for instance, DOMAttr.hpp). Actually, I think
> that something is going wrong because <> should not be changed, but I am
> unable to guess what I am doing wrong. Obviously, the xerces folder is where
> it must be (so that the errors dissapear when <> are changed by "").
>
> Can anybody help me, please?
Note that all files should be included using "" and not <>. Standard C++
reserves <> for system headers, and Xerces-C violates that.
This is likely happening because you built the binaries but did not build
an official distribution, or you have the include path messed up. Please
supply more information about your compiler and development environment.
Dave