C / C++ / MFC Discussion Boards

Eddy Vluggen30-Jun-16 2:54

30-Jun-16 2:54

Not before you can confirm that it is broken; are the files that lack an hour created during the same period, or is it distributed randomly?

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

Re: CFileStatus m_mtime problems

Member 1253112930-Jun-16 3:14

Member 12531129

30-Jun-16 3:14

I have a little bit check files. Files that where modified round in period betwen November and April have time one hour later.

Re: CFileStatus m_mtime problems

Richard MacCutchan30-Jun-16 2:54

Richard MacCutchan

30-Jun-16 2:54

The m_mtime.Format method returns a time formatted according to the local timezone, so it may well be one hour out. You should use one of the alternative methods (see CTime Class[^]) to get the absolute time.

Re: CFileStatus m_mtime problems

Jochen Arndt30-Jun-16 3:06

Jochen Arndt

30-Jun-16 3:06

This can occur when files are stored on FAT file systems. NTFS stores all dates in UTC while FAT uses local times. The local time from FAT file systems is converted when getting the time. But this will return wrong values when the time stamp has been written by a system that uses a different time zone than the one used to read the time stamp.

See also File Times (Windows)[^].

Re: CFileStatus m_mtime problems

Member 1253112930-Jun-16 21:51

Member 12531129

30-Jun-16 21:51

I have solved the Problem with this:

Retrieving the Last-Write Time (Windows)[^]

Compile dll in Ubuntu to include in Windows 7 (32 bit) program

Member 1224497229-Jun-16 6:41

Member 12244972

29-Jun-16 6:41

Hi, I just need instructions to build my working source code in C++ into a dll that is compatible with Windows 7.
Thanks.

Re: Compile dll in Ubuntu to include in Windows 7 (32 bit) program

Jochen Arndt29-Jun-16 7:08

Jochen Arndt

29-Jun-16 7:08

You want to build a Windows DLL on a system running Ubuntu?

Such tasks are called cross-compilation and require installation of additional components. See Compile for Windows on Linux | BlogCompiler[^] for setting up such a cross compilation environment using MinGW.

The creation of DLLs is described at cross compilation - Compiling a DLL project written in c++ - Ask Ubuntu[^].

Re: Compile dll in Ubuntu to include in Windows 7 (32 bit) program

leon de boer29-Jun-16 7:22

leon de boer

29-Jun-16 7:22

Assuming that your code has no linux OS calls in it and is just generic stuff you just define an interface for it and compile it like Jochen's answer.

If you have linux OS calls you will need to build windows replacements or use a framework.

In vino veritas

modified 29-Jun-16 13:29pm.

std::string declaration in header file error

Member 1224497229-Jun-16 3:26

Member 12244972

29-Jun-16 3:26

Hi, I need your help a bit in C++.

I am coding a dll but my source code has 2 errors.

Both issues stem from the same declaration in my header file.

void execute_assert(bool expr, std::string str);

When I do the function calls...

v_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");

and

v_assert(s < 1, "Illegal acl size (" + deb + ")");

I get the error message...

Error: too many arguments to function ‘void execute_assert(bool, std::string)’

On both counts, the parameter count is ok, so what's the problem?

Please help.

Re: std::string declaration in header file error

David Crow29-Jun-16 3:33

David Crow

29-Jun-16 3:33

Does v_assert() call execute_assert() or vice-versa?

Member 12244972 wrote:

v_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");

Shouldn't this be:

v_assert(s == MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");

or maybe

v_assert((s == MAX_ACL_DEPTH), "MAX_ACL_DEPTH too small");

"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

Re: std::string declaration in header file error

Member 1224497229-Jun-16 3:41

Member 12244972

29-Jun-16 3:41

I was making the wrong function call.

v_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");

should have been

execute_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");

Problem fixed.

Thanks all.

Re: std::string declaration in header file error

Richard MacCutchan29-Jun-16 3:43

Richard MacCutchan

29-Jun-16 3:43

Where is the definition of v_assert, is is a macro?

Re: std::string declaration in header file error

Member 1224497229-Jun-16 3:54

Member 12244972

29-Jun-16 3:54

I was making the wrong function call.

C++

v_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");

should have been

C++

<pre>execute_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small");

Problem fixed.

Thanks all.

Type Conversion happens while writing to Logfile in VC++

aruzhere28-Jun-16 21:36

aruzhere

28-Jun-16 21:36

I am trying to output certain int variables to my logfile. But upon viewing the logfile these varuiables are shown in hex. any idea why this happens?

ofstream logfile;
GetLocalTime(&st);
sprintf(logfilename,"Myfilename_%d%02d%02d.log",st.wYear,st.wMonth,st.wDay);

logfile.open(logfilename, ios::app);

logfile <<"# Time is :: "<

Re: Type Conversion happens while writing to Logfile in VC++

Jochen Arndt28-Jun-16 22:29

Jochen Arndt

28-Jun-16 22:29

I don't know why your stream uses hex format here. But you can set the format: ios_base::fmtflags - C++ Reference[^].

Because you are still using the C library function sprintf for the file name you might use it also for formatting the output. I still prefer this because it is often simpler (e.g. for date and times with leading zeroes).

Re: Type Conversion happens while writing to Logfile in VC++

Richard MacCutchan28-Jun-16 22:53

Richard MacCutchan

28-Jun-16 22:53

I just ran the above code and the values are all in decimal. There must be something else in your code that is causing the issue.

Re: Type Conversion happens while writing to Logfile in VC++

aruzhere28-Jun-16 23:04

aruzhere

28-Jun-16 23:04

Actually this is only a part of the code. I have int variables declared and those are also displayed in hex in the logfile.
will it have something to do with the settings while I build the same in Visual C++?

Re: Type Conversion happens while writing to Logfile in VC++

Richard MacCutchan28-Jun-16 23:43

Richard MacCutchan

28-Jun-16 23:43

No, but somewhere you are setting the stream attributes to display all integers in HEX rather than DEC format.

Re: Type Conversion happens while writing to Logfile in VC++

aruzhere29-Jun-16 2:24

aruzhere

29-Jun-16 2:24

Thanks a lot.. There are instances in the code where the stream is set to hex. Upon removal the same works fine.

But is there a way without removing hex and set the stream back to display DEC ?

Re: Type Conversion happens while writing to Logfile in VC++

aruzhere29-Jun-16 2:42

aruzhere

29-Jun-16 2:42

Found out the way to do that without actually removing Hex. Used <

openMP loop and exception

Joerg Michels27-Jun-16 23:38

Joerg Michels

27-Jun-16 23:38

Hi all,

I have a for loop parallelized with openMP. Inside I want to catch possible exceptions. My idea is that the caught exception should be a private variable, as it is possible that several exception occur parallel. But I cannot express this.

example:

#pragma omp parallel for default(none)
for ( int i = 0; i < 10; ++ i )
{
	try
	{
		// do something ...
	}
	catch ( const std::exception&	e )
	{
		e;
		// handle exception ...
	}
}

This yields to compiler error:

error C3052: 'e' : variable doesn't appear in a data-sharing clause under a default(none) clause

But I cannot mark the exception variable as private, as I is not known at that scope.

I can bypass the compiler error by changing the default sharing behaviour to shared, but I think this could lead to a runtime error, if two exceptions occur at the same time.

What is the correct way to deal with this?

Thanks in advance,
Joerg

Heap Corruption issue

Ben Aldhouse21-Jun-16 10:27

Ben Aldhouse

21-Jun-16 10:27

I've got an application which has two dialogs, I use a deque and Direct2D in one dialog within a thread. Now, if I close the application via handling WM_CLOSE I have no problem but when I try and close it by clicking on 'Close Window' in the task bar or using Alt F4 I get a breakpoint triggered on

C++

if (!HeapFree(select_heap(block), 0, block))

I know it's a long shot since I have given so little detail - but seeing as the difference seems to be in the way I close the app down I was hoping there might be a quick and easy fix for this.

Yours hopefully,

Ben

*Update since I posted in this it the next door forum, this morning, by mistake: I still get the same error if the thread (and hence the direct2d drawing) isn't running. Perhaps it is something to do with the way I set up the dialogs.

Re: Heap Corruption issue

David Crow21-Jun-16 10:47

David Crow

21-Jun-16 10:47

Isn't the WM_CLOSE message being sent whether you terminate the app via Task Manager or by using Alt+F4?

Re: Heap Corruption issue

Ben Aldhouse21-Jun-16 12:45

Ben Aldhouse

21-Jun-16 12:45

Thanks for your reply!

I don't know, to be honest. The problem was occurring when I AltF4ed or clicked on Close Window but not when I clicked on my 'Exit' button. However, it looks like it was a corrupt memory problem I had with a member variable I'd assigned to the heap and was using to pass data between threads.

I've changed the communication to the following:

In the sending thread:

ControlDlg * pParent = (ControlDlg *) this->GetParent();
ColourAlphaEnvelope * s = new ColourAlphaEnvelope;
*s = m_ColourEnvelope;
pParent->PostMessage(CM_COLOURBOUNDS, reinterpret_cast<WPARAM>(s));

and in the recieving dialog I used

afx_msg LRESULT CRectArtDlg::OnCmColourbounds(WPARAM wParam, LPARAM lParam)
{
	std::auto_ptr<ColourAlphaEnvelope> s(reinterpret_cast<ColourAlphaEnvelope*>(wParam));
	m_colourEnvelope = *s;
	return 0;
}

I bet there are dozens of better ways of doing this (not least since a quick Google reveals that auto_ptr is depracated) but I haven't had a crash and the compiler isn't telling me there is a memory leak.

Winsock - FD_WRITE

Vijjuuu.21-Jun-16 4:54

Vijjuuu.

21-Jun-16 4:54

Hi all,

i am developing client program using WSAAsyncselect() in Winsock2.
i have few queries regarding FD_WRITE.
i understood that when client is connected to server. There will be FD_WRITE event posted stating that we can send the data to server. However, i want to send data to server based on some other events that the application is interested in. i am not quite sure how the FD_WRITE event will be fired when i want send data to server.

here is the pseudo.

C++

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
	switch (message)
	{
	case WM_SOMEOTHEREVENT:
		// collect the data. we need to send collected data to sever (right now data is stored in a list).  
		break;
	case WM_SOCKET:
		switch (WSAGETSELECTEVENT(lParam))
		{
             // how to fire this event when application wants to send data ?
		     case FD_WRITE:

		     break;
		}
		break;
	}
	return 0;
}

Thanks in advance.

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.