|
Thanks Steve!
Actually I even wanted to know that if I implement WMP to read from an IStream, is it important to have the knowledge of COM?
Regards,
Harshita
|
|
|
|
|
IStream is a COM interface, so if you implement it yourself, yes. In my opinion knowledge of COM is essential knowledge for Windows developers. Especially if you write unmanaged code. In this instance you may be able to get away with using the CreateStreamOnHGlobal API and use a system supplied implementation however.
Steve
|
|
|
|
|
Thanks again for your kind suggestion!
Can you suggest me some good URL for learning COM?
Regards,
Harshita
|
|
|
|
|
Hello,
Visual Studio 2005
From the help on: Compiler Warning (level 2) C4356
If I modify that example like:
#include <iostream>
template <class T>
class C {
static int n;
};
class D : C<int> {};
int C<int>::n = 0;
if I take this code and put it in a DLL
like this:
# if defined(MYLIB_EXPORTS)
# define MYLIB_API __declspec(dllexport)
# else
# define MYLIB_API __declspec(dllimport)
# endif
template <class T>
class C {
static int n;
static void show() {
std::cout << "C:show()" << std::endl;
std::cout << n << std::endl;
}
};
class MYLIB_API D : C<int> {};
int C<int>::n = 3;
#include "mydll.h"
int main() {
int k1 = D::n;
int k2 = C<int>::n;
D::show();
}
The error I get, if I uncomment (a) or (b), is always:
1>myapp.obj : error LNK2001: unresolved external symbol "public: static int C<int>::n" (?n@?$C@H@@2HA)
This makes sense because I am not exporting C.
So the question is:
1.1) Why then method show() gets exported ?
1.2) In other words: Why the method gets exported and the data member not ?
2) Is there any way to export directly the data ?
( of course I could workaround the problem and access the static data member through a static method )
3) A last question, a little different, but maybe related:
If I try to export some data from a DLL, like:
// file mydll.h :
static MYLIB_API int mydata; // error C2201: 'mydata' : must have external linkage in order to be exported/imported
MYLIB_API static int mydata2; // error C2201: 'mydata' : must have external linkage in order to be exported/imported
I think that with vc70, if I remember well, I was not gettting any error message while compiling the DLL, but the LNK2001 error when linking the application.
In other words I am always forced to export data as static data member of a class, ( which is in some cases very unconvenient), like:
class MYLIB_API MyDataClass {
static int data;
};
int MyDataClass::data = 5;
Is there a way to do it without using a class ?
Thank you very much for any answer.
Marcello
|
|
|
|
|
static tokens are only seen in the scope of that specific compilation unit.
Maxwell Chen
|
|
|
|
|
This is not the case when the static keyword is used on a class member: in this case it means that the member is shared across all instances of the class and can be accessed without a this pointer.
Just for interests sake, the use of static to make a global variable or function private to a compilation unit is deprecated in C++. The recommended way to achieve this effect is to use an anonymous namespace. i.e.
namespace
{
int g_Var;
}
Steve
|
|
|
|
|
I was talking about this line.
static MYLIB_API int mydata; // error C2201: 'mydata' : must have external linkage in order to be exported/imported
Maxwell Chen
|
|
|
|
|
A data member of a class can be declared static; be it in the public or private part of the class definition. Such a data member is created and initialized only once, in contrast to non-static data members, which are created again and again, for each separate object of the class. A static data member is created once: when the program starts executing. Nonetheless, it is still part of the class.
Static data members which are declared public are like `normal' global variables: they can be reached by all code of the program using their name, together with their class name and the scope resolution operator. This is illustrated in the following code fragment:
#include <iostream>
template <class t="">
class C {
public:
static int n;
};
The data member n is a private static variable. During the execution of the program, only one C::n exists, even though more than one object of the class C may exist. This data member could be inspected or altered by the constructor, destructor or by any other member function of the class C.
|
|
|
|
|
Thank you for the all answers.
But the question I made is not a beginner's question.
It is about exporting a static variable and if there is any reason why it is made so difficult to export it.
We know that it is possible to export a static member from a template class specialization,
We know that it is not possible to use the __declspec(dllexport) keyword with a template.
But in the example I gave I was able to get a static methods of a template exported even if the __declspec(dllexport) was not used. But this is not happening with a static data member.
The reason I am trying to do this is that I need to export and use a class created by using the Curiously Recurring Template Pattern (CRTP). In my case the template base class needs to have a static member.
About the third question, I am pretty sure that it is possible by using an export file (.def) and using a special keyword in it [ unfortunately I don't remember exactly how  ].
Cheers,
Marcello
|
|
|
|
|
"Windows requires all public symbols to be explicitly exported from a DLL via the __declspec(dllexport) syntax (and correspondingly dllimported when referenced in some other DLL).
I guess it works pretty well on C libraries. But it doesn't work so well on C++ libraries, particularly with template classes--the template itself, of course, doesn't have a link-time presence, so it doesn't make sense to dllexport a template. What you really mean to export is the template instantatiation. But template instantiations are implicit, according to the language, so where do you put the dllexport syntax?
Microsoft came up with a place to put the dllexport syntax, which is to explicitly put a line like this in the DLL that exports a particular template instance:
Code:
template class __declspec(dllexport) my_template_class<my_instance>;
And also put a line like this in a DLL that imports that template instance:
Code:
extern template class __declspec(dllimport) my_template_class<my_instance>;
These lines must be the first instantiation of the template instance, which means they must be seen by the compiler before any other reference to my_template_class<my_instance>.
Of course, this is a Microsoft extension to C++ syntax; the language itself does not require this sort of declaration (and non-Microsoft compilers won't understand it).
The problem with this declaration is that it explicitly expands and exports all methods and components of the template class, whether they are actually used or not; and it requires that nested template classes be explicitly exported before their containing classes are exported.
That's not too bad, but it turns out that the standard STL implementation of list, map, set, multiset, multimap--basically everything other than vector--use nested template classes that are mutually recursive. That is, the nested class includes references to the containing class, and vice-versa. This makes it impossible to export the nested classes first, since expanding them requires expanding the containing class--which has not been exported yet, violating the rule that the export syntax must appear before the first instance is encountered. Similarly, you can't export the containing class first, which would expand the nested class before its export syntax. This means that none of the STL classes except for vector can be exported from a DLL.
But do you really need to export a template instance from a DLL? Isn't each instance of a template technically a completely new copy of the class? If you don't even try to export the class, you should end up with a new copy of the template code in each DLL, but since all of the copies are essentially the same, they should be compatible with each other. So what happens if you don't try to export the class?
It turns out this works, mostly, but the standard implementation of STL relies on some static members of the template class, which the language specifies that the linker should resolve to the same pointer value by runtime. The Microsoft DLL linker doesn't do this (because, without having explicitly exported the template classes, the linker sees them as unrelated classes). The net result is that any class that tries to expose iterators to its internal STL object, even via an inline method, will crash if those iterators are accessed by code in another DLL.
We spent a long time trying to figure out why our code, which worked fine on Unix, was crashing when we ported it to Windows. We finally tracked it down to this, and the only solution we could find--short of making everything non-inline and paying the corresponding run-time performance penalty--was to compile everything into one big DLL. Now, within the one DLL, all the iterators are valid and can be accessed by code in different modules.
This was back on VC6. Beginning with VC7.0, Microsoft started shipping with a third-party reimplementation of STL, that supposedly works around the DLL linker issue by not requiring static members to be unified. So presumably the issue is now a moot point on VC7.0 and above--you should be able to use STL iterators across DLL's now, although you still pay the cost of code bloat--although we haven't tested this."
/////////////////////////////////////////////////////////////////
// header file DLL
#ifdef MYDLL_EXPORTS<br />
#define MYDLL_API __declspec(dllexport)<br />
#else<br />
#define MYDLL_API __declspec(dllimport)<br />
#endif<br />
<br />
class MYDLL_API CMyDLL {<br />
public:<br />
CMyDLL(void);<br />
static void SetN(int x);<br />
static int GetN();<br />
static void show();<br />
static int n;<br />
};<br />
MYDLL_API int CMyDLL::n;
// CPP file DLL
CMyDLL::CMyDLL() { return; }<br />
<br />
void CMyDLL::show() {<br />
std::cout << "CMyDLL:show()" << std::endl;<br />
std::cout << n << std::endl;<br />
}<br />
<br />
void CMyDLL::SetN(int x) { n = x; }<br />
<br />
int CMyDLL::GetN() { return n; }
// main file
#include "stdafx.h"<br />
#include <iostream><br />
#include "myDLL.h"<br />
<br />
int main(int argc, char* argv[])<br />
{<br />
CMyDLL::n = 2;<br />
CMyDLL::SetN(9);<br />
int k1 = CMyDLL::n;<br />
std::cout << k1 << std::endl;<br />
CMyDLL::show();
return 0;<br />
}<br />
Result: // ???
2 // direct call n
CMyDLL:show()
9 // calling via function
|
|
|
|
|
Thank you so much for your answer, and for saving me a lot of time and trouble.
You really went to the core of problem I am having.
Unfortunately I worked for months to recode my program in separate DLL's in order to keep things separated.
I personally think that DLL are also a mean to keep things separated, so to unify all of them in a unique DLL is something I will do only if I have no other choice.
In my case I think I would rather find a way to eliminate the static member, even if it is really not a good solution because of the way my class is supposed to be used.
Only a question. Why in Unix you didn't meet this problem ? ( I know a bit about Linux, but not very much. )
Best Regards,
Marcello
|
|
|
|
|
I wanna know ways to make low-level operations to devices (mainly the hard disk) in .Net Framework by using C++ dll's or something ?????
By ways I mean maybe a class or a Windows standard API library (doesnt matter if its not managed code)
Specific things I want to know are (mostly consultations) :
- the beginning/ending number of cluster and track of files,
- the beginning/ending number of cluster and track of folders
- the size in clusters of files
- the volume serial number
- the size in clusters and tracks of a hard disk, etc
- can I do "interrupts" ???
Let me know the class or the Api library and the documentation, if there is it.
thanks in advance, fvalerin
|
|
|
|
|
It sounds like a device driver is in your future.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Well, no, I dont want to complicate my existence. I just want to read those kind of values
thanks, fvalerin
|
|
|
|
|
I know of no way to circumvent the HAL in order to get access to such low-level information.
For the fourth bullet, use GetVolumeInformation().
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
I just saw this article:
Hooking the kernel directly
http://www.codeproject.com/useritems/soviet_direct_hooking.asp
maybe he can help you !
Marcello
|
|
|
|
|
Marcello wrote: maybe he can help you !
I'm not the one needing help, fvalerin was.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Yes, I meant fvalerin
|
|
|
|
|
is there any way to change the default color(blue) of title bar, and the color of text in a dialog application.
Thanks
|
|
|
|
|
i think only way is to draw them yourself on WM_NCPAINT message.
A special image tool for C++ programmers, don't miss it!
The world unique Software Label Maker is here for you and me ...
A nice hyper tool for optimizing your MS html-help contents.
|
|
|
|
|
|
Hello,
I have a weird error that I hope someone can help me with:
I have a program (SDI), whose view is derived from CPropertyView, a property sheet view by Leo Moll. When I run the application in debug mode, I have no problems whatsoever. However, if I change to release mode, I get the following:
depView.obj : error LNK2001: unresolved external symbol "protected: int __thiscall CDepView::OnCreate(struct tagCREATESTRUCTA *)" (?OnCreate@CDepView@@IAEHPAUtagCREATESTRUCTA@@@Z)
Release/dep.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
dep.exe - 2 error(s), 0 warning(s)
In DepView.h, I have:
afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);
In DepView.cpp, I have
BEGIN_MESSAGE_MAP(CDepView, CPropertyView)
ON_WM_CREATE()
...
END_MESSAGE_MAP()
and
int CDepView::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
...
return 0;
}
If I remove either the declaration in the header file, or the implementation (and message map) in the source file, it compiles fine, but crashes when I close it (and of course doesnt initialize anything).
Does this sound familiar to anyone?
I have only seen this error when I forget to include the source file in the project, but I have checked that. What boggles my mind is that it works perfectly in debug mode.
Any help/comments would be greatly appreciated,
Thanks in advanced,
-----------------
Genaro
|
|
|
|
|
Just a guess: I'd check the preprocessor definitions for the release build and compare it to that of the debug build. In particular I'd pay attention to the UNICODE, _UNICODE and _MBCS defines.
Steve
|
|
|
|
|
Hi Stephen,
thanks for the reply. I checked the preprocessor settings, and as far as definitions are concerned, no difference, except for _debug vs. ndebug.
For project options,
Debug is:
/nologo /MDd /W3 /Gm /GX /ZI /Od /I
"C:\mysql++-1.7.1-win32-vc++\include"
/I
"C:\mysql++-1.7.1-win32-vc++\mysql\include"
/D "WIN32"
/D "_DEBUG"
/D "_WINDOWS"
/D "_AFXDLL"
/D "_MBCS"
/Fp"Debug/dep tool.pch"
/Yu"stdafx.h"
/Fo"Debug/"
/Fd"Debug/"
/FD /GZ /c
Release is:
/nologo /MD /W3 /GX /O2 /I
"C:\mysql++-1.7.1-win32-vc++\include"
/I
"C:\mysql++-1.7.1-win32-vc++\mysql\include"
/D "WIN32"
/D "NDEBUG"
/D "_WINDOWS"
/D "_AFXDLL"
/D "_MBCS"
/FR"Release/"
/Fp"Release/dep tool.pch"
/Yu"stdafx.h"
/Fo"Release/"
/Fd"Release/"
/FD /c
I can't find anything that would cause the error there... any clues?
-----------------
Genaro
|
|
|
|
|
Looks fine. I can't think of anymore suggestions. Good luck
Steve
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
