|
Only the distributor of the library will need to compile the derived class, not the person using the API!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I meant his code, not the library. If the class definition is in a header and is being used, then all its base classes will also have to be declared.
|
|
|
|
|
Erudite_Eric wrote: If the class definition is in a header and is being used, then all its base classes will also have to be declared.
In the example and per the answer given it is child classes, not base classes, that are being hidden.
|
|
|
|
|
The OP didnt mention base or derived classes.
|
|
|
|
|
Erudite_Eric wrote:
The OP didnt mention base or derived
classes.
You didn't respond to the OP. You responded to the second posters example and a comment that poster made about the that example.
|
|
|
|
|
Please reread my example: the CLog definition and declaration only goes into the library code! Only the ILog definition goes into the public API: since that one is a base class it is self-sufficient: there is no other definition or header file required!
On a sidenote, we've been using that very technique for years: the APIs don't have any data members, and in many cases we don't have the slightest idea how the actual implementatuion looks like.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I didnt say you werent using your tecnique but the OP asked about the class definition in the header. If it isnt defined it wont compile. Period.
modified 29-Nov-13 8:06am.
|
|
|
|
|
That is not the point at all. The OP wondered about class definitions that don't contain data members. I explained how an API can work without data members by just defining interface classes without data. The API only provides the interface headers. The ILog definition and any call to it will compile just fine without ever seeing the CLog implementation. That's what we did, and apparently that's what the library mentioned in the OP does, too.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: That is not the point at all.
Just noting that I agree with you that the other response was off base.
|
|
|
|
|
hi all,
how to know the process(self and others) is run as admin privileges or not,
I read the process information using PROCESSENTRY32 ,here no option to get information about the process running state.
thanks.
|
|
|
|
|
|
it just get the process by its name not the information about process running state (its run from admin or not)
|
|
|
|
|
You have to open the process token, then check to see which group the user is a member of.
I don't recall the functions involved, but if you google, you'll find it.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Run this piece of code -
HANDLE hProcess = ::GetCurrentProcess();
HANDLE hToken;
::OpenProcessToken(hProcess, TOKEN_QUERY, &hToken);
PTOKEN_ELEVATION_TYPE ele = 0;
DWORD dwLen;
::GetTokenInformation(hToken, TokenElevationType, (LPVOID)ele, 0, &dwLen);
ele = (PTOKEN_ELEVATION_TYPE)::HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, dwLen);
::GetTokenInformation(hToken, TokenElevationType, (LPVOID)ele, dwLen, &dwLen);
ele will be TokenElevationTypeFull if run with admin privileges and TokenElevationTypeLimited if not.
The above code will check the current process.
To check for other processes, as others have said, you need to open the process to get its handle.
«_Superman_»
I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) (October 2009 - September 2013) Polymorphism in C
|
|
|
|
|
thanks to all of you for valuable suggestion and help.
thanks alot.
but i have one another problem this works on vista and 7 but on XP, GetTokenInformation fail with invalid parameter.
please help me for this.
thanks.
modified 27-Nov-13 8:03am.
|
|
|
|
|
I am trying to get users name using traversing c:\users but I am getting 3 user name extra which does not in that folder i.e. All Users, Default User, Public.
How can I get exact users name?
|
|
|
|
|
john5632 wrote: How can I get exact users name?
Which one? The one logged in to the PC? The one running your program? Be specific. Have you looked into GetUserName()?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
|
I have a regular DLL that uses MFC statically linked.
When I try to export a function with a c-style unmangled name, the DLL ends up being built with a mangled name for the function.
The function I'm exporting is defined as follows:
extern "C"
{
_declspec(dllexport) _LaunchProcess __stdcall Start(LPCLIENT32STARTUPCONTEXT StartupContext)
{
theApp.Start(StartupContext);
return &LaunchProcess;
}
}
When I build the DLL, the function ends up named "_Start@4" instead of just "Start". Does anyone know how I can force it to export the function as "Start"?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
I'll try it, thanks. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
It worked, thank you.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
The MSDN documentation describes this - dllexport, dllimport[^]
Here is the excerpt from the documentation -
dllexport of a function exposes the function with its decorated name. For C++ functions, this includes name mangling. For C functions or functions that are declared as extern "C", this includes platform-specific decoration that's based on the calling convention. If you don't want name decoration, use a .def file (EXPORTS keyword).
Here is the result of what I tried with dllexport -
extern "C" __declspec(dllexport) void __cdecl One() {}
extern "C" __declspec(dllexport) void __stdcall Two() {}
extern "C" __declspec(dllexport) void __fastcall Three() {}
«_Superman_»
I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) (October 2009 - September 2013) Polymorphism in C
|
|
|
|
|
Oh! So it's the "__stdcall" that was causing the name mangling!
Thanks Uberman!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Yes, but it is Microsoft specific.
If you'll always use dllimport when invoking functions in the DLL, any calling convention will work as long as it is correctly specified while importing.
«_Superman_»
I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) (October 2009 - September 2013) Polymorphism in C
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
