|
I ran into something I don't understand. The following line is producing another unresolved link error. 'buf' is a std::string.
std::getline(stream, buf,'\n');
We have the same line of code in other projects that compile just fine. Below is the link error. To resolve the problem, I changed buf to a char[1024] and am calling stream.getline(buf, sizeof(buf), '\n'). But why am I getting this link error in the first place? The projects which compile fine are REQUIRED projects for the project giving me this problem. I don't know if the chain of links has something to do with this, but I thought I'd at least mention it.
18>SimpleMCSFile.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > & __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::operator+=(char)" (__imp_??Y?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV01@D@Z) referenced in function "class std::basic_istream<char,struct std::char_traits<char> > & __cdecl std::getline<char,struct std::char_traits<char>,class std::allocator<char> >(class std::basic_istream<char,struct std::char_traits<char> > &&,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &,char)" (??$getline@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@YAAAV?$basic_istream@DU?$char_traits@D@std@@@0@$$QAV10@AAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@0@D@Z)
|
|
|
|
|
Looks like you're not linking to the library that contains the definition. First thing I'd do is create a new console project and see if it works there. Something like this should do:
#include "stdafx.h"
#include <tchar.h>
#include <string>
#include <sstream>
#include <iostream>
int _tmain(int argc, _TCHAR* argv[])
{
using namespace std;
string source = "First line\nSecond line\n";
istringstream iss(source);
string line;
while (getline(iss, line))
{
cout << line << endl;
}
cout << endl;
return 0;
}
Steve
|
|
|
|
|
I just compiled this with my copy of VS2010 and it compiles and links fine. There must be something else in your configuration that is causing the problem.
It's time for a new signature.
|
|
|
|
|
Thanks everyone for the helpful input. It does seem like something strange with the project. I wrote a test console application and got no linker errors. And the same calls link in other projects within the Solution just fine. I compared projects and am unable to find a difference between a project that works and a project that does not work.
I am now trying to clean up code. The pre-compiled headers have includes for a ton of STL includes. I removed the one for string and am converting the headers and CPP files appropriately to see what happens.
Anyway, it does seem to be something odd with this project. Everything worked fine in VS 2005. We never upgraded to 2008 and now I'm converting to 2010.
EDIT: As a result of this exercise, I did run across several headers which were also including string, so I was able to clean those up.
modified on Monday, June 7, 2010 4:42 PM
|
|
|
|
|
Compare the project files using a diff tool.
Steve
|
|
|
|
|
Thanks again for the input.
Took me nearly two weeks, but I finally figured out the problem. It turns out we had two classes derived from std::string. I did not realize we had classes derived from std::string.
I had noticed in a smaller test case, adding a certain #include would show the problem. Removing the #include and things would compile/link just fine. Unfortunately, there is a HUGE trail of #include's in that one header. This led me to slowly move #include's out of headers into CPP files allowing me to narrow down which headers were causing a problem. Eventually I got things down to where I noticed one of the std::string-derived classes and I went, "Aha!". Changed it to a 'has a' and the problem went away.
|
|
|
|
|
Difference between Interface and dispInterface?
|
|
|
|
|
Beg, borrow or steal a copy of "Essential COM" by Don Box. It'll describe what COM interfaces are and how to use them. It'll also tell you all about dispatch interfaces, how they're just a particular type of COM interface and how to implement both types, as well as an "interesting" hybrid called a dual interface.
Cheers,
Ash
|
|
|
|
|
It is a good book on COM.
Steve
|
|
|
|
|
Interface is a general term. A dispinterface (Dispatch Interface) is an interface that meets special requirements, specifically dynamic invocation by scripting environments (see the IDispatch[^] interface).
Steve
|
|
|
|
|
Hello,
I was trying to compile and execute an example given into a tutorial. everything went right but when i tried to execute the Client program i had a failure message for QueryInterface of a COM supplied by a server COM.
Here is a link to the code [^]
"The Ultimate Limit Is Only Your Imagination."
|
|
|
|
|
it seems an error due to the DllRegister Servir (code 0x8007007e)
"The Ultimate Limit Is Only Your Imagination."
|
|
|
|
|
Hi,
This error means that you are missing one of the dependencies.
Best Wishes,
-David Delaune
|
|
|
|
|
Not sure who gave me a 1 vote... but HRESULT 0x8007007e means "The specified module could not be found". if this is occuring during DLL registration then it is a missing dependency.
Best Wishes,
-David Delaune
|
|
|
|
|
Hello Everybody,
I'm currently studying the ATL/COM paradigm and i'm was asking a question.
What's the currently use of the ATL/COM components ? I know that it's used to bring or raise functions from one application to others using interfaces and Dll; but after reading some tutorials i was wondering why have i to do such manipulations and code implementations when we may do such operations unsing just DLLs.
I'm new on this paradigm and i hope to have a good answer to that question.
Thank you.
"The Ultimate Limit Is Only Your Imagination."
|
|
|
|
|
Well COM was originally intended to be a solution for DLL Hell[^]. In the old days... when CompanyX updated a Microsoft distributable DLL... it would often break the application written by CompanyY. "The procedure entry point.. blah blah could not be located..."
So naturally the user would phone CompanyY and complain about the crash. At this point CompanyY would send the user the original DLL to fix the issue. One problem... now the application written by CompanyX no longer works. COM was suppose to fix the problem by allowing multiple versions of the same component to be installed on the system and be located using a GUID in the registry.
Fast forward to the modern era... we still have the DLL Hell problem... and the new solution is called WinSxS[^].
History lesson over, lets have this conversation again in 10 years and see whats changed.
Best Wishes,
-David Delaune
|
|
|
|
|
Well it seems that the COM is like a patch of ActiveX and may be is more significant when we talk about Avtivex with Internet and browsers than Applications. Anyway Thanks for your reply even if the idea about COMs and The Hell of Dlls still fuzzy
Thank You
"The Ultimate Limit Is Only Your Imagination."
|
|
|
|
|
COM is the foundation ActiveX is build upon. DLL hell was just one of the problems COM was designed to solve, and it's not the major one. Essentially COM is a technology designed to provide language independent binary components.
Steve
|
|
|
|
|
I cam back just to say that your link for the WinSxS was very interesting and i knew many things that i ignored before. With the Dll Hell link i noticed that the interfaces are used to fix the uncompatibility of differents versions of Dlls and so when it says interaces that means the use of ATL / COM. That's the only fact that i had by reading that. SO am I right ??
"The Ultimate Limit Is Only Your Imagination."
|
|
|
|
|
Blood_HaZaRd wrote: so when it says interaces that means the use of ATL / COM. That's the only fact that i had by reading that. SO am I right ??
Not exactly. Win32, managed or COM components can be stored in an assembly (and much more). Side-by-side (SxS) simply keeps track of dependencies that your application needs. The contents of this collection is determined by your application manifest. For example... one of the most commonly used shared assemblies is Comctl32.DLL. You can tell the SxS manager which version of this DLL you require by adding a manifest file to your application.
Some additional documentation for you:
The End of DLL Hell[^] (Look at the date!)
Authoring DLLs for Side-by-side Assemblies[^]
Using Isolated Applications and Side-by-side Assemblies[^]
If you are wondering what the future holds for SxS then you should keep track of the recent Activation Contexts[^]. I was forced to learn everything I could about SxS Activation Contexts late last year when I began experiencing a strange bug in one of the products I maintain. You can read about it here:
http://www.codeproject.com/Messages/3282355/Re-0xC015000F-The-activation-context-being-deactiv.aspx[^]
Best Wishes,
-David Delaune
|
|
|
|
|
|
COM's got some advantages compared to calling functions in DLLs or rolling your own interprocess communication:
- Does all the marshalling for you
- Your components can be used relatively easily and transparently from non-C or C++ languages
- Location transparent (ish), your components can be in the same process, a different process or at the end of some convoluted communications network
Against that it's a bitch to use properly especially in languages that don't support it directly (e.g. C and C++). To be honest if you're writing code that doesn't need any of the things I've mentioned above stick to straight DLLs written in the same language as you main application.
Cheers,
Ash
|
|
|
|
|
Yeah Yeah, Indeed. Thank you
"The Ultimate Limit Is Only Your Imagination."
|
|
|
|
|
Hi ,
I have created one ATL COM add ons for IE which write file on C:\users\sample.txt path.
When i run application on my machine(Vista) then it writes files as correctly, but when I run application of another vista machine ,file is not written. Is there any setting in Vista which allow to write file on C:\users folders.
Thanks
ABM
|
|
|
|
|
It sounds to me as if the second machine has Internet Explorer running in protected mode. If this is the case then you will need to instead write your files into the FOLDERID_LocalAppDataLow special folder.
PWSTR pszPath[1];
HRESULT hr = SHGetKnownFolderPath(FOLDERID_LocalAppDataLow,KF_FLAG_NO_ALIAS | KF_FLAG_DONT_VERIFY,NULL,pszPath);
CoTaskMemFree(*pszPath);
Understanding and Working in Protected Mode Internet Explorer[^]
Best Wishes,
-David Delaune
|
|
|
|