C / C++ / MFC

Re: managing objects derived from the same base class using a container

10-Aug-22 11:14

pointers from a library, that`s a topic that`s a bit too advanced or complicated for my present day understanding.

k505410-Aug-22 13:01

k5054

10-Aug-22 13:01

If you can handle raw pointers, then C++ smart pointers should be easy to understand. Google for C++ unique_pointer tutorial and read through a few of the returned hits. It's fairly straight forward, and in general new C++ development should use the smart pointers instead of using raw (e.g. new/delete).

Keep Calm and Carry On

Re: managing objects derived from the same base class using a container

Calin Negru10-Aug-22 21:25

Re: managing objects derived from the same base class using a container

10-Aug-22 21:25

The problem is I hate complicated syntax. Containers are already complicated syntax for me, combine that with another object (pointer) from a library and it becomes unintelligible mess. I will use a complicated feature when I really need to use it and there is no other way around it. Usually I need to use a feature a couple months before I can move on to something more complicated.

Richard MacCutchan10-Aug-22 21:10

Re: managing objects derived from the same base class using a container

10-Aug-22 21:10

It's a lot simpler than classes and inheritance. Laugh | :laugh:

Calin Negru11-Aug-22 0:38

Re: managing objects derived from the same base class using a container

11-Aug-22 0:38

Richard you really think so?

Richard MacCutchan11-Aug-22 0:39

Re: managing objects derived from the same base class using a container

11-Aug-22 0:39

Did you notice the Laugh | :laugh:

icon?

Calin Negru11-Aug-22 0:57

Re: managing objects derived from the same base class using a container

11-Aug-22 0:57

ok, it was a joke

Calin Negru12-Aug-22 18:58

Re: managing objects derived from the same base class using a container

12-Aug-22 18:58

I guess converting the object(pointer) back to it`s original form when time comes to use it somewhere works the same

C++

derivedclass * DerClpointer1 = (derivedclass *)AllObjects->at(0);

Is there a way to check is the conversion is valid? like if an object is of a certain type. For instance how do I convert all objects to their derived state type in a for loop?

C++

for(int i =0; i< AllObjects->size();i++ )
{
 // if AllObjects->at(i) is of type derivedclass covert to derivedclass
}

modified 13-Aug-22 9:27am.

Richard MacCutchan12-Aug-22 21:55

moving graphics in a win32 c++ window

12-Aug-22 21:55

Calin Cali wrote:
guess converting the object(pointer) back to it`s original form when time comes to use it somewhere works the same

Yes it should do, but you need to run some tests to make sure.

Calin Negru9-Aug-22 8:25

9-Aug-22 8:25

I`m trying to animate things in a basic window. The code I have should get a rectangle (rc) move to the right however that does not happen, it`s all static.

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
	static RECT rcBmp;
	static HDC hdcCompat;
	static HBITMAP hbmp;
	static RECT rc;
	static RECT rc2;
	static RECT rc3;
	static RECT rc4;
	HBRUSH hbrWhite, hbrGray; 
	const COLORREF SomeColor = RGB(255,255,255);
	const COLORREF SomeColor2 = RGB(0,0,1);
	hbrWhite = CreateSolidBrush(SomeColor); 
	hbrGray  = CreateSolidBrush(SomeColor2); 
	
	int y = 0;
	HDC hdc = (HDC) wParam; 
	

    switch (uMsg)
    {
		case WM_CREATE: 
		
		return 0L; 
 
case WM_ERASEBKGND: 
    
    GetClientRect(hwnd, &rc); 
    SetMapMode(hdc, MM_ANISOTROPIC); 
    SetWindowExtEx(hdc, 100, 100, NULL); 
    SetViewportExtEx(hdc, rc.right, rc.bottom, NULL); 
    FillRect(hdc, &rc, hbrWhite); 
	
    
       
       
    return 0;
  
    case WM_DESTROY:
        PostQuitMessage(0);
        return 0;
	
		
           
    case WM_PAINT:
        {
            PAINTSTRUCT ps;
			
            HDC hdc = BeginPaint(hwnd, &ps);

            

           
			 SetRect(&rc,x, 20, 40, 40); 
			FillRect(hdc, &rc, hbrGray); 
			SetRect(&rc2,60, 60, 80, 80); 
			FillRect(hdc, &rc2, hbrGray); 

            EndPaint(hwnd, &ps);
        }
        return 0;

    }
    return DefWindowProc(hwnd, uMsg, wParam, lParam);
}
void GameUpdate()
{
	 
	x = x +1;

}

[Edit] it looks like WM_PAINT isn`t triggered every frame, only if I minimize and then maximize the window a change takes place

modified 9-Aug-22 14:35pm.

Gerry Schmitz9-Aug-22 9:15

Gerry Schmitz

9-Aug-22 9:15

I think you need an "event"; like a timer tick; in order to create a "frame loop" (update and paint).

"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I

Graham Breach9-Aug-22 20:54

Graham Breach

9-Aug-22 20:54

Windows is event-driven, it doesn't have regular animation frame updates.

You can use SetTimer() to get WM_TIMER messages as often as you want, then invalidate your window to get the WM_PAINT message and repaint.

GDI performance is not very good though, so to reduce flicker you'll probably want to draw to an offscreen compatible device context and then BitBlt() that to the screen. Or use Direct2D - but then you'll have a new problem to think about.

Richard MacCutchan9-Aug-22 20:57

9-Aug-22 20:57

You need to call InvalidateRect function (winuser.h) - Win32 apps | Microsoft Docs[^] each time the object's position changes. The WM_PAINT message is only sent when Windows decides that the view needs repainting. Calling InvalidateRect tells it to do this.

Calin Negru10-Aug-22 1:58

10-Aug-22 1:58

I had in mind switching my videogame from DirectX to GDI. After some attempts at getting a win app working the way I need it and failing I will probably give up on the idea. I should probably keep using DirectX. Thanks for your help Richard and everyone else. Sorry for taking your time, this GDI idea is just a dead end.

modified 10-Aug-22 9:06am.

Richard MacCutchan10-Aug-22 2:01

FileMapping book exmple goes in loop

10-Aug-22 2:01

I would suggest you remove that link from your message (and future ones), as the system assumes it is spam. And some people here will just flag the message which means it will not get published.

coco2438-Aug-22 8:48

Re: FileMapping book exmple goes in loop

8-Aug-22 8:48

Hi,

I am following an example from a book and it doesn't work fine.

In a win32 c++ project I am trying to make the following codes to work:

At the window creation the mapped file is created

C++

case WM_CREATE:
		{
			// Create a file mapped object.
			//.............................
			hMapFile = CreateFileMapping( (HANDLE)0xFFFFFFFF, NULL,
				                          PAGE_READWRITE, 
										  0,
										  1024,
										  "MyFileMappingObject" );

			// Return if the mapping failed.
			//..............................
			if ( !hMapFile )
				return(-1);
		}
		break;

There are made modification in mapped file in the following thread function:

C++

DWORD AnotherProcess( LPDWORD lpdwParam )
{
	HANDLE hFileMap;
	LPTSTR lpMapAddress;

	// Open the file mapping.
	//.......................
	hFileMap = OpenFileMapping( FILE_MAP_ALL_ACCESS, FALSE,
		                        "MyFileMappingObject" );

	// Map a view to the mapping object.
	//..................................
	lpMapAddress =(LPTSTR)MapViewOfFileEx( hFileMap, FILE_MAP_ALL_ACCESS,
		                            0, 0, 0, lpdwParam );

	// Display the contents of the memory.
	//....................................
	MessageBox( NULL, lpMapAddress, "Mapped Memmory",
		        MB_OK | MB_ICONINFORMATION );

	// Set "Received" into the memory.
	//................................
	strcpy( lpMapAddress, "Received" );

	UnmapViewOfFile( lpMapAddress );

	return( 0 );
}

There are made modification on mapped file and the thread function is called on the following code:

C++

case IDM_TEST:
			{   
				DWORD dwID;
				// Map a view of the file mapped object.
				//......................................
				lpMapAddress = (LPTSTR)MapViewOfFile( hMapFile, 
					                          FILE_MAP_ALL_ACCESS,
											  0, 0, 0 );

				// Place data int the view.
				//.........................
				strcpy(lpMapAddress, "Data passed from main process.");

				// Make sure the data is flushed to the file.
				//...........................................
				FlushViewOfFile( lpMapAddress, 
					             lstrlen( lpMapAddress ) );

				// Create a thread to receive the data.
				//.....................................
				hThread = CreateThread( NULL, 0, 
					      (LPTHREAD_START_ROUTINE)AnotherProcess, 
						  lpMapAddress, 0, &dwID);

				// Set a timer to wait for the data to be processed.
				//..................................................
				SetTimer( hWnd, 1,	1000, NULL );
			}
			break;

If everything is ok all cycle is ended with the timer:

C++

case WM_TIMER:
		{
			// Check to see if the thread has processed the memory.
			//.....................................................
			if ( strcmp( lpMapAddress, "Received" ) == 0 )
			{
				// Kill the timer and thread.
				//...........................
				KillTimer( hWnd, 1 );
				TerminateThread( hThread, 0 );

				MessageBox( hWnd, lpMapAddress, "Done", MB_OK );

				UnmapViewOfFile( lpMapAddress );

			}

When I put breakpoint in the "AnotherProcess" thread function, after the message box, in the message box no message
is displayed, like lpMapAddress would be empty.
It could be from OpenFileMapping or MapViewOfFileEx to not doing their job? Because in watch table lpMapAddress
has value 0.

After that point, the compiler enters in a kind of assambler code in a inifinite main loop. Maybe here WM_TIMER goes crazy.

Can you help me to figure out what should be done? Where are the things that are nok?

Thank you very much.

Mircea Neacsu8-Aug-22 10:35

Mircea Neacsu

8-Aug-22 10:35

Took me some time to spot the problem (I think):

C++

lpMapAddress =(LPTSTR)MapViewOfFileEx( hFileMap, FILE_MAP_ALL_ACCESS,
		                            0, 0, 0, lpdwParam );

This doesn't make much sense: the last argument of the function is the address where you want it mapped. So you are kind of mapping the memory where it was already mapped. I's suggest to change it to:

C++

lpMapAddress =(LPTSTR)MapViewOfFile( hFileMap, FILE_MAP_ALL_ACCESS,
		                            0, 0, 0);

If you want a shared memory implementation that has been tested, you can find one here. The source file is mlib/src/shmem.cpp

Mircea

Re: FileMapping book exmple goes in loop

coco2438-Aug-22 11:45

Re: FileMapping book exmple goes in loop

8-Aug-22 11:45

Thank you for the rapid response.

Indeed, now, the code works as I think it should.

I supposed that this was the central idea, to modify the mapped file from two different places, but appears
that something went wrong. I supposed that the LPWORD type of lpdwParam was the problem but I haven't seen a solution.
It appears that it does't like the start address but the all file to be mapped.

Anyway it seems that it's working, and now I can move on in the learning process beacause I want to get the ideea not to
stay to long on each topic.

Thank you very much Mircea for your response and for the links.

Thank you.

Mircea Neacsu8-Aug-22 11:47

Mircea Neacsu

8-Aug-22 11:47

You are very welcome!

Mircea

defining a function with #define

coco24330-Jul-22 9:03

30-Jul-22 9:03

Hi,

Please help me understanding the following declaration:

C++

#define EVENBYTE( i )  ((i+7)/8*8)

It represents the definition of function?

If for example I call EVENBYTE( 1 ), the result will be ((1+7)/8*8)?

From where I have extracted de code, the EVENBYTE was called in that way:

C++

int    nIconBytes = (EVENBYTE(nWidth)/8)*nHeight;

I don't understand what this kind of declaring is and why to do it in that mode?

Thank you in advance.

Mircea Neacsu30-Jul-22 9:54

Mircea Neacsu

30-Jul-22 9:54

No, it is not a function, it is a macro definition. While, in your case a function defined as:

C++

int evenbyte (int i) {return (i+7)/8*8;}

would do the same thing, there is an important difference: a macro definition is expanded at compile time while a function is compiled and later on called at runtime.

When to use one over the other is a question of optimization speed vs memory: a macro definition like your would not incur the overhead of a call but might produce larger code. Meanwhile a function definition would produce smaller code but might take longer to execute.

To solve these type of issues, C++ has introduced inline functions, so in C++ you can write

C++

inline int evenbyte (int i) {return (i+7)/8*8;}

and you leave the compiler the choice of expanding it inline (like a macro definition) or make it a function and call it.

One more thing: the macro definition is insensitive to the type of argument. That is both a good thing and a bad thing like in the examples below:

C++

int i1 = 3;
int e1 = EVENBYTE (i1); //calling macro with an int argument yields an int result
long i2 = 129;
long e2 = EVENBYTE (e2); //calling macro with a long argument yields a long result

int e3 = EVENBYTE ("abc"); //generates some obscure error message

To accomplish the same thing in C++ you would have to use a function template:

C++

template <typename T>
T evenbyte (T i) { return (i+7)/8*8;}

Mircea

trønderen30-Jul-22 12:46

trønderen

30-Jul-22 12:46

Also worth noting: A macro does not define its own scope, the way a function does. It could refer to other symbols, say,

C++

#define PLUSX(i) (i + x)

Which x is added? That depends on where PLUSX is used. In one place it could be a different x than in another place. In a third place, there may be no x defined at all, and you get a compilation error, even if the two first uses of PLUSX went without any error.

A define is a pure textual replacement. If you in your code editor replace 'PLUSX(i)' with '(i + x)' (and change the 'i' in the replacement text to whatever was the name of your actual argument), you are doing by hand the work of the C preprocessor. Or in your case, if in your editor you replace

C++

int  nIconBytes = (EVENBYTE(nWidth)/8)*nHeight;

with

C++

int  nIconBytes = (((nWidth+7)/8*8)/8)*nHeight;

then you get the exact same result as with the #define.

Note: I am certainly not suggesting that referring to non-argument variables from macros is a good idea (usually is is not), but understanding how macros differ from functions includes understanding how such references would work.

Personal opinion: #define is among the most mis-used features of the C language. Except for giving symbolic names to simple constants, you should try to avoid it as far as possible.

Greg Utas30-Jul-22 13:58

Greg Utas

30-Jul-22 13:58

In C, #define is sometimes used to do the same thing as templates in C++, which I can understand.

In C++, #define shouldn't be used that way, but C hackers use their preprocessor crapola in C++. It shouldn't even be used to define constants, especially after constexpr showed up.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

Randor 30-Jul-22 9:55

Randor

30-Jul-22 9:55

coco243 wrote:
Please help me understanding the following declaration

Kinda looks like something used for calculating Image stride[^].

coco2433-Aug-22 9:01