Some marcos like WIN32/_WIN32 and WIN64/_WIN64 are used by VC++. I am not sure what's the difference between WIN32/WIN64 and _WIN32/_WIN64.

Lakamraju Raghuram wrote:

I think you have't fully understood that article.
When you are copying win32 settings to x64, that article clearly mentioned to change win32 switch to win64 for /D switch

Refering to the artical, the WIN32 macro should be repalced by WIN64 with /D switch support. But after I did it under the steps, the WIN32 macro still there but not replaced by WIN64. You may try it from your side. So I am confused by the result.I wonder if it is a defect of vs2008 IDE. Some other articals mentioned that the WIN32 macro always should be set with /D switch and with WIN64 macro definied for x64 application perspectively.

Lakamraju Raghuram wrote:

Which source code? your code or in any of the standard headers?
If it is yours, then you should take care to propely to map these settings to win32 and win64 pre-processor definitions

I found the _WIN64 macro in MFC header file of basestd.h. Here a code snap:

#if defined(_WIN64)
typedef __int64 INT_PTR, *PINT_PTR;
typedef unsigned __int64 UINT_PTR, *PUINT_PTR;

typedef \_\_int64 LONG\_PTR, \*PLONG\_PTR;
typedef unsigned \_\_int64 ULONG\_PTR, \*PULONG\_PTR;

#define \_\_int3264   \_\_int64

#else
typedef _W64 int INT_PTR, *PINT_PTR;
typedef _W64 unsigned int UINT_PTR, *PUINT_PTR;

typedef \_W64 long LONG\_PTR, \*PLONG\_PTR;
typedef \_W64 unsigned long ULONG\_PTR, \*PULONG\_PTR;

#define \_\_int3264   \_\_int32

#endif

So I am not sure which macro I should set in the preprocessor definition setting. By default, VS2008 IDE set the WIN32 macro with /D switch. Also I found _WIN32 macro is used in the MFC header files and source files.

By the artical: http://msdn.microsoft.com/en-us/library/9yb4317s(v=vs.80).aspx[^] After create a new platform of x64, I can create a new solution configuration for Debug Win64 and copy settings from Debug Win32. But I wonder how to set the properties for the x64 solution. After I create new solution configuration and copy settting from Win32, I found the macro WIN32 is still there, but not replaced by WIN64. For win64 application, which macro(s) should I set in the /D setting? Should I keep the /DWIN32? Btw, I found the _WIN32,_WIN64 macro in MFC source code, but not WIN32,WIN64. Which one is required in the /D setting? Thanks for your inputs. /Sam

Hi Mark. Thanks. Appreciated for your share. It really helps me understand IOCP and other asnc IO operation.:thumbsup:

Hello Mark, Much appreciated for your input. I think it is very helpful to me.

Mark Salsbery wrote:

SAMZCN wrote:

Is it possbile to require more than one send request for each buffer?

Yes it's possible, so you need to check if the entire buffer of data was sent for each call, same as always with sockets.

Note: If you make multiple asynchronous WSASend calls using an I/O completion port then make sure all calls are made on the same thread.

For TCP/IP, I personally much prefer only one outstanding read and/or one outstanding write per socket given the above information :)

At this point, it is the biggest puzzling thing to me. I read many articles on this issue about IOCP. But don't find any conclusion to make me convienced. By your saying, it seems really I need to check the whether the entire buffer in one request was sent out completely. If not, I need to post another send request for the rest data. Yes. Really I want to make multiple asynchronous WSASend calls using an I/O completion port to get performance improvement. But I can't make sure the calls are received by same thread. It is my problem. I do many trials on this. It seems meaningless. I agree that one outstanding IO operation per socket in a given time is a good way to get stable running. Thanks.:thumbsup:

As I know IOCP which is called one powerful model to meet socket program in scalable case, from then on I have a question on IOCP.Today, still puzzle me. The question is What will happen if you post more than one WSASend() request in one client socket which has been associated with the existing completion port. The scenario is as follows: IO Request:

WSASend(...,wsaBuff1,1,...); // 1st send request for Buffer1 with 1MB data
WSASend(...,wsaBuff2,1,...); // 2nd send request for Buffer2 with 1MB data
WSASend(...,wsaBuff3,1,...); // 3rd send request for Buffer3 with 1MB data

What will happen in the completion port? 1/ How many completion packet will be received? 2/ What is the order of the completion packet? 3/ Is it possbile to require more than one send request for each buffer? It means one time send request can't finish the data transmission. The user need to post another or more WSASend request for the rest data.

Question 1: I create one CDockablePane wnd and dock it in the bottom of the parent wnd. The default CDockablePane height is too short and I want to resize the height of the CDP. How to do that? Btw, if the CDP is docked in the left/right side of the parent wnd, it works well after setting new width. Question 2: How to make the CDP floating when initialized. The CDP is initially docked in one side when created? I want to make it floating after it is created in the specified position with an initial size. I feel very hard to control the CDP programmatically, like floating, resizing and moving with MFC. I found one artical from MS website about docking window management programmatically. But it is for C# Winform, not for MFC. Still two days no replys come in. Seems not to poplular on CDockablePane class. :(( Can anyone give help? NOTE: Ohh....:confused: nobody is interested in CDP usage....Why? Not a good object, is it?

modified on Friday, June 3, 2011 5:49 AM

Question 1: I create one CDockablePane wnd and dock it in the bottom of the parent wnd. But the default CDockablePane height is too short and I want to resize the height of the CDP. But don't find any workable method to do. Btw, if the CDP is docked in the left/right side of the parent wnd, it works well when setting new width. Question 2: Another question is how to make the CDP floating when initialized. The CDP is initially docked in one side when created. But I want to make it floating after it is created in the target position and with a initial size. How to do it ? I feel very hard to control the CDP programmatically, like floating, resizing and moving with MFC. I found one artical from MS website about docking window management programmatically. But it is for C# Winform, not for MFC. Can anyone give help?

modified on Wednesday, June 1, 2011 5:25 AM

Include all the STL head files which are shared by the DLL and the client proj. And all the data structure of the DLL proj and all the data struct will be used by the cilent proj too. I'm trying ...

Thanks. Yes. In the client project linking to the DLL, the client project include the DLL interface head file like this.

#include "MyExprotDllHead.h"

Now the issue is still pending. And so many new failure report and reported in STL allocation procedure. I'm trying my best to find out the root cause. :(

Richard MacCutchan wrote:

This is fine but have you include all the correct headers (and reference to std namespace) in the class that is linking to the DLL, i.e the code that will be using the DLL. Remember that classes and methods exported from a DLL are visible to the linker not the compiler.

Oh... I am trying to catch the error. But I found it is uncertain and not repeatable.. :( Try to find more and report later ...

Hi, Cpallini I am trying to find out some clue here... I am confused now... What's wrong with my code or proj? And the STL support headers are all included and employeed its namespace too.

CPallini wrote:

It looks like you have problems with the STL library, not DLL issues. You should post the errors and (as Richard pointed out) the relevant code for getting better help

Hello Richard, Thanks for your input. I've include the headers in the DLL project

#include #include #include #include using namespace std;

Is ther any error on my implementation on the DLL exporting? Is it a right way to make DLL proj to export derived class like what I do ? It is the first time that I do it like this.

Richard MacCutchan wrote:

Well we will have to guess what they are. It may be that you are not adding a using statement in your client project before the inclusion of the class containing the STL members. Alternatively you could add the full definitions in your headers like this: CMyDLLClass1 : public CInterfaceClass { public: CMyDLLClass1 (){}; virtual ~ CMyDLLClass1 (){}; virtual int Func1(); virtual int Func2(); virtual int Func3(); private: std::vector<...> .... std::map<...> .... } Did you notice how I also used

tags to make the code snippet more readable?

Really? I've make the interface class as one interface class with all functions of pure virtual property. It says it is an abstract class only. It seems not required to export it with the DLL's derived class. Right?

Nisamudheen wrote:

In order to use the CInterfaceClass in another DLL, as a base class, you need to export this class first.

In my case, I want to create one interface class and use it to employee the drived class implementation. The sample codes are as follows.

CInterfaceClass
{
public:
CInterfaceClass(){};
virtual ~CInterfaceClass(){};
virtual int Func1() = 0;
virtual int Func2() = 0;
virtual int Func3() = 0;
}

And the interface class will be used the DLL project and the client project. Here the drived class in the DLL project and it will be exported and be used by the client project:

CMyDLLClass1 : public CInterfaceClass
{
public:
CMyDLLClass1 (){};
virtual ~ CMyDLLClass1 (){};
virtual int Func1();
virtual int Func2();
virtual int Func3();
private:
vector<...> ....
map<...> ....
}

And another DLL project may like this...

CMyDLLClass2 : public CInterfaceClass
{
public:
CMyDLLClass2 (){};
virtual ~ CMyDLLClass2 (){};
virtual int Func1();
virtual int Func2();
virtual int Func3();
private:
vector<...> ....
map<...> ....
}

In the client project, I want to use the exported class like this.

CInterfaceClass* pMyDllClass1 = new CMyDLLClass1();
pMyDllClass1->Func1();
pMyDllClass1->Func2();
pMyDllClass1->Func3();
CInterfaceClass* pMyDllClass2 = new CMyDLLClass2();
pMyDllClass2->Func1();
pMyDllClass2->Func2();
pMyDllClass2->Func3();

It seems that I can enter the functions. But many errors come out with STL members. I am confused on this usage of DLL. Could you pls give your help on this ?

modified on Monday, November 22, 2010 7:57 PM

Hello Federico, Thanks for your great help. It makes me clear on the problems I met recently. Many many thanks for your kind help. :-D Sam/Br.

federico.strati wrote:

Note: 1. it is necessary to declare the variables volatile on some systems to prevent using cached values, you'll be fine by declaring all the integer indexes unRead/unWrite etc... as volatile 2. the classes are thread safe for the single situation where you have a single producer (writer) and a single consumer (reader) in different threads. It is NOT safe for multiple consumers / multiple producers. 3. The modifs you've done are good even if don't understand why you changed the way you increment the pointers it is not important to increment pointers in an atomic manner as there will be only two threads: one writer and one reader. If you want atomicity then you shall use InterlockedIncrement / Decrement functions. But it is a wasted effort here. Hope that helps Cheers Federico

I read the CDoubleBuffer class you write. It's a very good implementation on the double buffer usage. Here I have some questions on the buffer class. Would you please give some comments?Thanks in advance. 1. Is it thread-safe of CDoubleBuffer? In Read/Write function, each of them will access the target buffer.If in multi-thread case, the reader thread will use Read() and the writer thread will use Write() simutaneously. Both of the function will access unRead/unWrite variables. Is it necessary to declare the variable with key word of volatile? 2. About the CCircBuffer, I have the same question of CDoubleBuffer. Besides, what's the purpose of the following two functions?

// Increment the read pointer
UINT32 IncTheReadPtr(void);
// Increment the write pointer
UINT32 IncTheWritePtr(void);

From the implemention of the two funcitons, I see it does nothing except only increasing the pointer. And the pointer increasement has been done in GetTheData()/SetTheData() functions. Appreciated for your share. It's very usefull for me to understand the problem of my case furthermore. And I get big confidence to start my job on this case.

federico.strati wrote:

#ifndef DOUBLE_BUFFER_H #define DOUBLE_BUFFER_H #include #include class CDoubleBuffer { public: CDoubleBuffer( unsigned int unAlloc = 0x000FFFFF ); ~CDoubleBuffer(void); void Write(void* pBuf, unsigned int unBytesTo); void Read (void* pBuf, unsigned int unBytesFrom); private: void** pAlloc; unsigned int unRead; unsigned int unWrite; unsigned int unSize; }; #endif // ! defined (DOUBLE_BUFFER_H)

ooh...okey. Now it seems a problem for me. :( Originally, I think the view instance is not the same one in spite of same type of view. So the CMFCToolBarComboBoxButton control object is also created onece for each view. Only the ID is the same. The click/change message for the control may be routed to different target view. I think only the control box which is clicked actually should changed. Whatever, any way to make it happen? I really donot want to use CComboBox control to implement. it is not a easy way to do. In that case, you need to control the the box by yourself completely, including its possition and behave.

Thanks for your reply. Yes. It is same views of same document. In the program, I really need multiple views of same type in one document. Simply, the program is a Single Docment Multiple Views one. More than one view of same type are displayed to view different data from data controller with SQL query support. But I find if I use normal CCombox control other than CMFCToolBarComboBoxButton, it works well. I guess it may be a question with CMFCToolBarComboBoxButton. Any more inputs?

Working on an MDI program. There is a toolbar ,in which there is an CMFCToolBarComboBoxButton item, in one of the views. User need to open multiple views of the same type. The question is the combox item will change together when user changed it in one view, even through the combox is in different views. What's wrong? Is it designed by Microsoft? :doh: :confused: