Hi. I tried today to use TinyXml inside a dll with Visual Studio 2005. I created a dll project, imported the 6 classes needed for TinyXml to work. I then added the #import "stdafx.h" on top of all 6 classes (otherwise I get an error message telling me to do so) but when I try to compile at this point, I get 8 errors saying that printf, sprintf, _snprintf_s, _snscanf_s, sscanf_s, _snprintf, _snscanf and sscanf are undefined identifiers in tinyxml.cpp
But they're defined in stdio.h
I don't know what the problem is. When I import the files in a regular console application, it works, but in a dll after adding #import "stdafx.h", i get those 8 errors.
Does anyone know the reason of the problem?
Has someone ever tried to use tinyxml inside a dll?
Thanks
Guillaume
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't tried specifically but if you add "#include <stdio.h>" in tinyxml.cpp what happens?
The other way, though admittedly its a little unusual in C++ code, is rather than adding the tinyxml.cpp files to your project, #include them.
For example, if you have a file my_dll_stuff.cpp you can add #include <tinyxml.cpp>" in that file. C/C++ will just merrily do it. I have done this rarely but on occasion it has been useful (particularly when I don't want to modify the other cpp file).
HTH
Ellers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Including stdio.h doesn't change anything.
If I don't add tinyxml.cpp to the project but just import it, will it still be inside the dll?
Unfortunately I cannot test de dll until Monday morning at work but it would be nice to come in with a solution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When you say "import" do you mean "#include"? The concepts are similar but not identical and software is driven by precision.
If you're compiling say my_dll_code.cpp and you #include tinyxml.cpp (or .h, or whatever) you are literally inserting that text into your file. It is as if you had that exact text right in your file.
In other words, yes, the code goes inside your DLL.
If you are getting errors like "symbol not found: sprintf" then #including <stdio.h> will solve it; if it doesn't seem to, I can only suggest that the #include line has been added at the wrong place.
HTH
Ellers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes I mean include when I say import.
Ok, I will try to just include it and not put it inside the project. But how will Visual Studio know where to find tinyxml.cpp if it's not in the project. Won't I get an error that says it's not able to find the file?
As strange as it may seen, adding #including <stdio.h> doesn't change anything. I feel like the error comes from a mix-up with the import of stdafx.h.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, we could go round like this for a while, but I'll try to summarise...
- Its important to use the right terms. You're #including, not "importing".
- If MSVC can #include "tinyxml.h" then it will succeed doing the same with tinyxml.cpp. If they're in separate directories, you'll need to add the cpp directory to the list of include paths, the same way you did for tinyxml.h. You shouldn't need to do this but you never know.
- The #include-the-cpp-file-directly trick is not a magic bullet for your particular situation - the proper solution is the use of #include <stdio.h>. Frankly, I think there has been a mistake in where you added "#include <stdio.h" or in how you set up the projects, thats all, nothing else. Having said that, it can be useful to #include the cpp file anyway - just don't think that it is normal or common practice, because it is not.
- It's not "strange" that including stdio.h doesn't work, its just plain wrong. The solution *is* stdio.h, period. However, the #include needs to put it in the right place.
The simplest solution would be to put #include <stdio.h> in the stdafx.h and you'd probably be done.
Ellers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I have tried to include stdio.h in stdafx.h but it didn't work. There is no place at all, whether in tinyxml.h, tinyxml.cpp or stdafx.h, where adding #include <stdio.h> changes anything. And I guess that's exactly my problem since stdio.h is already included in tinyxml.h anyway, which is itself included in tinyxml.cpp.
You say I should add the cpp directory to the list of include paths, the same way I did for tinyxml.h but I didn't. I just added all the sources of tinyxml directly to my dll project as if they were my own sources. So you're saying I shouldn't add any of the sources to the project but just include them in my own cpp files and provide Visual studio with the path where it can find tinyxml's sources?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Before using tinyxml in my dll project, i tried it in a console application and it worked perfectly well.
Then I copied/pasted my code to the dll project, added the sources of tinyxml just like I did in the console application, but this time, I had those 8 errors in tinyxml.cpp.
Unforntunately, I am not at work so I can't give o the exact errors I'm getting, but apart from the number of the error, it was something like this:
"The symbol printf is an undefined identifier". Same message for the other 7 methods I gave in my first post. I think the #include "stdafx.h" is screwing up the #include "tinyxml.h". I don't know what is included in stdafx.h but it might be the problem.
Something interesting is that when I include tinyxml.h before including stdafx.h (instead of the other way around), some of the errors disapear (not all of them. the error for printf stays for example) but I get other error like a namespace used in tinyxml.cpp that MSVS says doesn't exist, but is in fact defined in tinyxml.h
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I found the problem. We were far from it and I didn't imagine that could be the problem.
My dll project was for Windows CE, and the xxx_s functions are not compatible with windows CE. So what I did was change those functions into their older unsecured versions, that are supported by Win CE.
Thanks for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed.
I just thought it came from the fact that I was compiling a dll. It took me a while before I thought of checking the compatibility of those functions on MSDN.
Thanks again
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi. I tried today to use TinyXml inside a dll with Visual Studio 2005. I created a dll project, imported the 6 classes needed for TinyXml to work. I then added the #import "stdafx.h" on top of all 6 classes (otherwise I get an error message telling me to do so) but when I try to compile at this point, I get 8 errors saying that printf, sprintf, _snprintf_s, _snscanf_s, sscanf_s, _snprintf, _snscanf and sscanf are undefined identifiers in tinyxml.cpp
But they're defined in stdio.h
I don't know what the problem is. When I import the files in a regular console application, it works, but in a dll after adding #import "stdafx.h", i get those 8 errors.
Does anyone know the reason of the problem?
Has someone ever tried to use tinyxml inside a dll?
Thanks
Guillaume
I haven't tried specifically but if you add "#include <stdio.h>" in tinyxml.cpp what happens?
The other way, though admittedly its a little unusual in C++ code, is rather than adding the tinyxml.cpp files to your project, #include them.
For example, if you have a file my_dll_stuff.cpp you can add #include <tinyxml.cpp>" in that file. C/C++ will just merrily do it. I have done this rarely but on occasion it has been useful (particularly when I don't want to modify the other cpp file).
HTH
Ellers
Including stdio.h doesn't change anything.
If I don't add tinyxml.cpp to the project but just import it, will it still be inside the dll?
Unfortunately I cannot test de dll until Monday morning at work but it would be nice to come in with a solution.
When you say "import" do you mean "#include"? The concepts are similar but not identical and software is driven by precision.
If you're compiling say my_dll_code.cpp and you #include tinyxml.cpp (or .h, or whatever) you are literally inserting that text into your file. It is as if you had that exact text right in your file.
In other words, yes, the code goes inside your DLL.
If you are getting errors like "symbol not found: sprintf" then #including <stdio.h> will solve it; if it doesn't seem to, I can only suggest that the #include line has been added at the wrong place.
HTH
Ellers
Yes I mean include when I say import.
Ok, I will try to just include it and not put it inside the project. But how will Visual Studio know where to find tinyxml.cpp if it's not in the project. Won't I get an error that says it's not able to find the file?
As strange as it may seen, adding #including <stdio.h> doesn't change anything. I feel like the error comes from a mix-up with the import of stdafx.h.
Well, we could go round like this for a while, but I'll try to summarise...
- Its important to use the right terms. You're #including, not "importing".
- If MSVC can #include "tinyxml.h" then it will succeed doing the same with tinyxml.cpp. If they're in separate directories, you'll need to add the cpp directory to the list of include paths, the same way you did for tinyxml.h. You shouldn't need to do this but you never know.
- The #include-the-cpp-file-directly trick is not a magic bullet for your particular situation - the proper solution is the use of #include <stdio.h>. Frankly, I think there has been a mistake in where you added "#include <stdio.h" or in how you set up the projects, thats all, nothing else. Having said that, it can be useful to #include the cpp file anyway - just don't think that it is normal or common practice, because it is not.
- It's not "strange" that including stdio.h doesn't work, its just plain wrong. The solution *is* stdio.h, period. However, the #include needs to put it in the right place.
The simplest solution would be to put #include <stdio.h> in the stdafx.h and you'd probably be done.
Ellers
Well, I have tried to include stdio.h in stdafx.h but it didn't work. There is no place at all, whether in tinyxml.h, tinyxml.cpp or stdafx.h, where adding #include <stdio.h> changes anything. And I guess that's exactly my problem since stdio.h is already included in tinyxml.h anyway, which is itself included in tinyxml.cpp.
You say I should add the cpp directory to the list of include paths, the same way I did for tinyxml.h but I didn't. I just added all the sources of tinyxml directly to my dll project as if they were my own sources. So you're saying I shouldn't add any of the sources to the project but just include them in my own cpp files and provide Visual studio with the path where it can find tinyxml's sources?
The #include method is more of an optimisation approach. It *might* help you but I think you've got simpler problems to address.
How about this. The error you're getting is the key. If MSVC can't find the symbol then it isn't #including stdio.h in the right place, end of story.
So, rather than guessing at solutions, copy/paste the *exact* errors you're getting in here and we can help.
BTW, does the normal building of tinyxml work as expected?
Ellers
Before using tinyxml in my dll project, i tried it in a console application and it worked perfectly well.
Then I copied/pasted my code to the dll project, added the sources of tinyxml just like I did in the console application, but this time, I had those 8 errors in tinyxml.cpp.
Unforntunately, I am not at work so I can't give o the exact errors I'm getting, but apart from the number of the error, it was something like this:
"The symbol printf is an undefined identifier". Same message for the other 7 methods I gave in my first post. I think the #include "stdafx.h" is screwing up the #include "tinyxml.h". I don't know what is included in stdafx.h but it might be the problem.
Something interesting is that when I include tinyxml.h before including stdafx.h (instead of the other way around), some of the errors disapear (not all of them. the error for printf stays for example) but I get other error like a namespace used in tinyxml.cpp that MSVS says doesn't exist, but is in fact defined in tinyxml.h
OK, I found the problem. We were far from it and I didn't imagine that could be the problem.
My dll project was for Windows CE, and the xxx_s functions are not compatible with windows CE. So what I did was change those functions into their older unsecured versions, that are supported by Win CE.
Thanks for your help.
Ah, yes, well that "little" detail would have been helpful!
Indeed.
I just thought it came from the fact that I was compiling a dll. It took me a while before I thought of checking the compatibility of those functions on MSDN.
Thanks again