|
Member 13655542 wrote:
kindly help this project
Help or Do? If the former, what have you done (for us to help you with)?
"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
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
So, I finally decided to dive into C++ world, trying to adapt some C# code I've been working on lately.
So here's what I have.
bin.h file:
#pragma once
namespace Maths {
class Bin
{
public:
template <class T> static const T GetMask(int);
};
}
bin.cpp file:
#include "bin.h"
namespace Maths {
template <class T> const T Bin::GetMask(int count) {
return (T)0; }
}
This compiles just fine. However, in the same console project, when I write:
#include "bin.h"
using namespace Maths;
int main() {
unsigned char value = Bin::GetMask<unsigned char>(0);
}
I get a nasty LNK2019 linkage error on compilation:
Error LNK2019 unresolved external symbol "public: static unsigned char const __cdecl Maths::Bin::GetMask<unsigned char>(int)" (??$GetMask@E@Bin@Maths@@SA?BEH@Z) referenced in function "int __cdecl main(void)" (?main@@YAXXZ)
In the Bin class, I have a couple of other (non-generic) methods, which I can use just fine. I suspect a problem with static templated methods specifically, but I can't understand the core problem. Maybe I just try to do something which is not possible (using a static generic method), but I cannot figure out why it would not be possible.
Anyone could give me a hint on this?
"I'm neither for nor against, on the contrary." John Middle
|
|
|
|
|
The Maths namespace does not contain a definition/declaration of Bin::GetMask<T>(int); only one of Bin::GetMask(int);. Just remove the <unsigned char> piece and it should be fine.
|
|
|
|
|
Thank you Richard for answering.
However, if I try to remove the <unsigned char> piece (namely: unsigned char value = Bin::GetMask(0);), the editor itself complains about the fact that no instance of function template "Maths::Bin::GetMask" matches the argument list.
Moreover, the Bin::GetMask<T>(int) is actually declared in Maths namespace. Problem seems to be with the .cpp part: the editor/IDE can see the definition of the generic method (since the editor does not complain when I try to use it, and the object explorer clearly displays the method with correct signature), but, on compilation, the linker cannot make a link to the actual implementation.
How can I correctly declare a static, generic method inside a non-generic class, then?
Thanks for your time 
"I'm neither for nor against, on the contrary." John Middle
|
|
|
|
|
phil.o wrote: the Bin::GetMask<T>(int) is actually declared in Maths namespace.
I don't see it anywhere, unless that is somehow implied by template <class T> static const T GetMask(int);.
Hmm, I though I understood templates.
|
|
|
|
|
Anyway, I found the issue. I cannot implement a template method in the .cpp file, like I did with other non generic methods. I moved the implementation of the generic method in the .h header file, and now everything is ok.
I guess I have to dig deeper in the translation unit concept
"I'm neither for nor against, on the contrary." John Middle
|
|
|
|
|
Yes, that's it. Template method definitions should be in header files.
|
|
|
|
|
phil.o wrote: the translation unit concept
The only reason for creating header files is when you have a set of common definitions that need to be shared by multiple translation units. If you only have a single .cpp file then all the definitions can safely be put in there. The #include statement is recognised by the preprocessor which reads all the include files and creates a new text file containing all the included code followed by the user written C/C++ code, and passes that new composite to the actual compiler.
|
|
|
|
|
I have learnt it the hard way This explains why everything was fine as far as the editor/IDE were concerned, and why the issue only occurred on the linking phase. That's quite confusing for a beginner.
"I'm neither for nor against, on the contrary." John Middle
|
|
|
|
|
phil.o wrote: quite confusing for a beginner.
and sometimes for the rest of us.
|
|
|
|
|
Hello,
I want to create application like windows explorer. I think I can use builtin tree and builtin list view.
I think there are some interface IShellFolderTree or IShellFolderList. Can you please guide me with any example/article?
|
|
|
|
|
|
The IShellFolder interface is mainly used to manage folders and provide data for clipboard and drag & drop. I suggest to start without using that and implement the tree and list views using standard API functions like FindFirstFileEx and FindNextFile which provide basic information like size, time stamps and attributes.
For additional info like icons and file types use SHGetFileInfo.
To get the owner name for a file or directory use GetNamedSecurityInfo and LookupAccountSid.
Solutions to resolve reparse points (links and mounts) can be found in the web (open with CreateFile with flags FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT and call DeviceIoControl with FSCTL_GET_REPARSE_POINT).
To use the IShellFolder interface you have to get the DesktopFolder and use that to bind to other folders:
LPSHELLFOLDER pDesktopFolder;
::SHGetDesktopFolder(&pDesktopFolder);
LPSHELLFOLDER psfFolder = NULL;
LPITEMIDLIST pFolderPIDL = ::ILCreateFromPath(lpszPath);
HRESULT hRes = pDesktopFolder->BindToObject(
pFolderPIDL,
NULL,
IID_IShellFolder,
IID_PPV_ARGS(&psfFolder)
);
LPITEMIDLIST pPIDL;
CString strName; hRes = psfFolder->ParseDisplayName(
NULL, NULL, strName.GetBuffer(), NULL, &pPIDL, NULL );
strName.ReleaseBuffer();
::CoTaskMemFree(pPIDL);
psfFolder->Release();
::ILFree(pFolderPIDL);
pDesktopFolder->Release();
As you can see there are lot of tasks where some are quite complex.
|
|
|
|
|
|
HWND hWnd;
After that declaration, please, how can I find the total outside size of the current window including the window's frames and menu and any scroll bars etc, not only the window's available area for writing text and images in?
|
|
|
|
|
Once you have the window handle, you just call GetWindowRect[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
Thanks.
SetWindowPos() sets up a window, and needs the desired total window size including borders and scroll bars etc.
Can I find easily the values of the needed total window size (say xj and yj) needed to set up a window whose image-and-text area (= client area) is xi * yi)?
|
|
|
|
|
Use GetWindowRect and GetClientRect to find those two values. The difference is the size of the frame portion. You can then calculate your required client size, add that to the frame sizes to get your new window size.
|
|
|
|
|
Just read an article on using classes as a DLLs following the class a __declspec(dllimport/dllexport) is needed. I was just wondering how MFC does it. On my system the MFC code is located in MFC140.DLL now when I inherit a let’s say CDialog class I don’t specify __declspec(dllimport)
Thanks
|
|
|
|
|
ForNow wrote: I don’t specify __declspec(dllimport)
No because that declaration will be in the header file. You should take a look at Creating and Using a Dynamic Link Library (C++)[^] for more information. Basically the project that creates the dll needs __declspec(dllexport) and every application the wants to use it needs __declspec(dllimport). This is usually controlled by a #define in the header that goes with the dll. If you create a DLL project in Visual Studio and select the "Export Symbols" checkbox, you get the following in the header:
#ifdef WIN32PROJECT2_EXPORTS
#define WIN32PROJECT2_API __declspec(dllexport)
#else
#define WIN32PROJECT2_API __declspec(dllimport)
#endif
class WIN32PROJECT2_API CWin32Project2 {
public:
CWin32Project2(void);
};
extern WIN32PROJECT2_API int nWin32Project2;
WIN32PROJECT2_API int fnWin32Project2(void);
|
|
|
|
|
Thanks I was just curious how MFC does it the code is in MFC140.DLL
and I don’t see any __declspec(import)
When I want to use CDialog
Also I assume when I follow theses steps in my .dll I’ll create a .lib
Thanks
|
|
|
|
|
The exported labels are not in the dll, as that means nothing to the compiler. They are in one of the header files somewhere in the MFC include folders. So if you find the definition of CDialog it will somehow be defined there.
|
|
|
|
|
FYI I did a dependency walker against MFC140.DLL and I got all the entry points N/A meaning without function names
|
|
|
|
|
Well they will be in there somewhere, but MFC/C++ names get mangled up and are not always easy to recognise. Be that as it may, if the entry points didn't exist then the dll would not be usable. I have not used MFC for many years so cannot actually check any of this. The key point is to ignore the dll and inspect the header files.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
