C / C++ / MFC

Once Again Assert in Release and I am lost

7-Sep-17 6:57

You generally do put the initD3D in the WM_CREATE and the cleanD3D in the WM_DESTROY.
The problem is you can't really put the render in the WM_PAINT you need to pump the render over and over.
So they have done a horrible hack to use the message loop to pump the render.

The problem with their hack is they can only have one render window and the render speed is controlled by the message loop.
Do you see the sneaky render_frame(); call in the message loop which is the render pump.

The correct way to do it is create a thread in WM_CREATE to pump the render call .. good old CreateThread()
You can link up WM_WINDOWPOSCHANGED (window size change) and WM_PAINT to the render thread if you want to do things from them to the renderer.

So they are basically trying to dodge having to deal with the complexity of having a render thread because it is targetted at beginners.
It is horrible as the render complexity and time goes up the message response time goes out the window.

MS has a proper threaded samples and there are probably others around
Windows Direct3D Multithreaded Rendering Win32 Sample in C++ for Visual Studio 2012[^]
NVidia also has do's and dont's ... see under do's ... Master Render Thread
DX12 Do's And Don'ts | NVIDIA Developer[^]

In vino veritas

modified 7-Sep-17 13:13pm.

ForNow4-Sep-17 13:39

4-Sep-17 13:39

Hi
I got a debug assertion in Release the VC c run time Message Box is nice enough to give
me the source and line number wincore.cpp line 656

its in CreateHook asserting m_hWnd == NULL

well this is in a process of Creating a modeless dialog box with 5 controls all CStatic

I check the m_hWnd of each of the 5 right after the call to base fundtion

CDialog::OinitDialog which calls DataExchange routine to create the m_hWnd's

and issue a AfxMessagebox in case any of the handles are NULL

I also check it right before I do a return in my overridable OninitDailog in case I somehow

overlaid the handle

I also check the Return code from CDialog::Create

Any advice would be appreciated

David Crow4-Sep-17 15:45

David Crow

4-Sep-17 15:45

ForNow wrote:

I got a debug assertion in Release...

I'm not sure how since the ASSERT() macro resolves to a no-op in release mode. Does the same assertion fire in debug mode?

modified 5-Sep-17 12:42pm.

ForNow4-Sep-17 16:01

4-Sep-17 16:01

No my code works fine under the Visual Studio debugger

Other funny thing after selecting re-try and attaching the VS debugger the call stack points to the debugging version of MFC140 - MFC140D.DLL

the only thing I included in my libs per Microsoft doc were the UCRT .libs from the windows 10 sdk

I have preprocessor NDEBUG flag just wondering if that might cause this

leon de boer6-Sep-17 19:09

6-Sep-17 19:09

NDEBUG it is defined by C/C++ standards to control what assert does.
assert - cppreference.com[^]
Visual Studio will redirect it in release build to try and do something useful but probably wrong and you are welcome to override it.

Visual Studio itself uses it's own two macros to control build/release modes
Predefined Macros[^]
_DEBUG Defined as 1 when the /LDd, /MDd, or /MTd compiler option is set. Otherwise, undefined.

_DLL Defined as 1 when the /MD or /MDd (Multithreaded DLL) compiler option is set. Otherwise, undefined.

You seem to be getting confused between what is demanded by C/C++ standards and what VS does itself.
Assert functionality lies outside VS control as demanded by the C/C++ standard.

Now at a guess what you have a wrong DLL dependency like the console using msvcrd.lib rather than msvcr.lib. If you are dragging in other libraries you need to make sure those other libraries are also compiled in release mode. So what other libraries are you linking with and are they added in your project source list. AKA do you see them compile when you do a full build or are you just dragging in pre-compiled units.

There are a number of dependency walkers out there you can run on your exe to see what DLL's it calls hit your favourite search engine. You shouldn't need them and I don't use them (so can't recommend one) but they are out there.

In vino veritas

modified 7-Sep-17 1:46am.

Jochen Arndt4-Sep-17 21:13

Jochen Arndt

4-Sep-17 21:13

You should find out first why your release build is linked with the debug version of the MFC.

Is this still the same project where you already recognised this?

If yes, I guess that there is something wrong with your release project settings.

You might use the Dependency Walker (depends.exe) Home Page[^] to check which DLL's are required by your application.

Note also that there are two definitions which are set accordingly when selecting the project build option: NDEBUG and _DEBUG. You should not change these. If you need to do so, create a special build instead of modifying the standard release or debug settings.

ForNow5-Sep-17 1:22

5-Sep-17 1:22

I have an idea The .lib I pointing to ucrt has both debug and release libs
Libcrt and libcrtd

If I just point it to the one with libcrt
Then those functions which require the debug build (erroneously ) should be unresolved

Jochen Arndt5-Sep-17 1:39

Jochen Arndt

5-Sep-17 1:39

Why have you specified the CRT library in the project settings?
It is automatically selected according to the /M build option (static/dynamic, release/debug).

You should still use the Dependency Walker to check if there are more debug DLLs referenced.

ForNow5-Sep-17 1:43

5-Sep-17 1:43

I have MFC as a static build
I have used dependency walker against a DLL to see what functions they expose
I guess it works also against a .exe to see what methods are called

Thanks

ForNow7-Sep-17 6:00

7-Sep-17 6:00

Okay I finally ran dependency walker was absolutely no help all it told me that my module was dependent on MFC140D.DLL but which api Pulled this in ?

Next I turned to DUMPBIN a little more usefull but not by much so I used the /IMPORT option to see what calls my .exe is referencing from the Microsoft DLL's

By the way as a side not I ensure that both my native CRT call and MFC were dynamic wanted to be consistent

well for the regular windows .DLL as USER and GDI it (DUMPBIN) told me the API my program was referencing

Getting to MFC or MFC140D.DLL is became more secretive just showing the ordinal
number

leon de boer7-Sep-17 6:39

7-Sep-17 6:39

You missed a library somehow. Hmmm what I might try is temporarily rename MFC140D.DLL and try a rebuild and hopefully you get a linker error.

In vino veritas

ForNow8-Sep-17 10:09

8-Sep-17 10:09

I did that and I got a whole slew of errors all related to the MFC wrappers my question would be then is there any difference between MFC140D and MFC140

I mean just the api's it exposes I am getting a whole slew of errors asserts and I am trying to track down the problem by removing piece by piece of my code related to the CDilaog which seems to be the problem I don't think its the fact that I am running with MFC140D as opposed to MFC140

Thanks

Rick York8-Sep-17 12:54

Rick York

8-Sep-17 12:54

MFC140D is the debug build and MFC140 is the release build - I think.

leon de boer8-Sep-17 18:07

8-Sep-17 18:07

You obviously have a real mess with the solution files. I think at this point I would either copy the directory and delete all the solution files or simply make a new directory and just copy the source files into it. Then set the solution up from new with the new directory with no existing solution files. I think that has to be the fastest way to solve it because it really shouldn't be this hard, its a lot less effort than what you are going thru.

In vino veritas

ForNow9-Sep-17 15:03

Re: Once Again Assert in Release and I am lost I finally figured out the bug .. My reflections

9-Sep-17 15:03

Leon my thinking exactly

I'll start from scratch (except for the source code)

when I first created the solution project I knew very little about the components I do now have a better idea

there are basically 3 components

1) C run time library such as sprintf
2) Windows native code user32 gdi etc..
3) the mfc wrappers

I am basically going to shared or dynamic linking for all three as opposed to static

Thanks

ForNow10-Sep-17 12:50

10-Sep-17 12:50

Well

At Leon's suggestion I started from scratch with a solution copying my code in

Guess what I noticed I had SetThreadName still my code. Obviously with no debugger this would cause problems

I am not by trade a Windows programmer but I will say this there seems to be somewhat of a window for (errors going from debug to release)

as having MFC140D.DLL in my module list I put MFC140.LIB as input to my linker to get rid of that problems

Again thanks to all who have been helping me

Declaration Confuse

Mr. Anup Roy31-Aug-17 6:38

31-Aug-17 6:38

Finally, I solved my previous problem Re: Sum Multiple Value At a Time - C / C++ / MFC Discussion Boards[^]
I have a question in declaration why we declare sum = 0; if we declare only sum; what happen, what is the meaning of 0 and please clarify the function sum = sum+workhours; I have to understand whole thing.

#include<iostream>
using namespace std;
int main ()
{

    int sum = 0;
    int workhours;
    int numemployee;
    int employeewage;
    int wage = 0;


    cout << "Enter Number of Employee:";
    cin >> numemployee;

    for(int i=0;i<numemployee;i++)
    {
        cout << "Enter Employee Works Hours " << (i+1) <<":";
        cin >> workhours;
        sum=sum+workhours;
        cout << "Enter Work/hrs Wage " << (i+1) <<":";
        cin >> employeewage;
        wage=wage+employeewage;

    }
    cout << "Total Work Hours: " << sum <<endl;
    cout << "Total Wage:" << wage <<endl;
    return 0;
}

modified 12-Sep-17 8:50am.

Re: Declaration Confuse

leon de boer31-Aug-17 8:37

Sum Multiple Value At a Time

31-Aug-17 8:37

Well two problems if we imagine it uninitialized that is it will have some random value. The start value could be any integer value.

1.) Your sum starts at some random value then you do this line
sum=sum+workhours;

So your answer is some random value + the work hours.
Why bother calculating anything the total is just some random number.

2.) You print the answer even if you had zero employees you would print some random value.
The compiler will actually throw a warning about this line using uninitialized value due to that

The take home message here is variables don't magically start at zero if you want them to start as zero you need to set it to zero.

There is one subtlety here that when you are in debug mode it will initialize all variables to zero. That doesn't happen in release mode.
So new users when debugging often get caught out because when they look in debug mode sum will start as zero.

So the key here is don't set it to zero, compile in release mode ignoring the warning and run your code and watch some random number display. You will have your answer.

In vino veritas

modified 31-Aug-17 14:46pm.

Mr. Anup Roy30-Aug-17 6:18

30-Aug-17 6:18

Hi,
I am a beginner in C++. Today my first program is summed two value.
Question: Write a program that inputs the number of hours that an employee works and the employee wage. Then display the employee gross pay(Be sure promote to input).
I have a question here I input two value and calculate their result and display, but I want to input more than two value. How to input more than two value and calculate them?

#include<iostream>
using namespace std;
int main()
{
    int i, m, j, n, k, l;
    cout <<"Enter Your Work Hour:.\n";
    cin >>i >>m;
    cout << "Enter Your Salary:.\n";
    cin >> k >> n;
    j = i+m;
    l = k+n;
    cout << "Your Total Work Hour is:" << j <<endl;
    cout << "Your Total Salary is:" << l <<endl;
    return 0;
}

C++

jeron130-Aug-17 8:10

jeron1

30-Aug-17 8:10

By 'more than two' do you mean a variable number of inputs, or a fixed number?

"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle

Mr. Anup Roy31-Aug-17 4:25

31-Aug-17 4:25

Variable number of input..

jeron131-Aug-17 5:38

jeron1

31-Aug-17 5:38

In keeping with Davids theme, you could specify an array that's larger than you would ever need, and have the user enter the number of entries first, then setup an input loop based on that. Or setup a loop that runs the same number of times as your array size and have the user enter a value (like -1) that denotes the end of the data at which point you would exit the loop, then process the the data entered prior to the -1 entry.

David Crow30-Aug-17 10:31

David Crow

30-Aug-17 10:31

You'd need to use an array and a loop. Something like:

int hours[5] = {0};
for (int x = 0; x < 5; x++)
{
    cout << "Enter hours worked for day " << (x + 1) << ": ";
    cin >> hours[x];
}

Mr. Anup Roy31-Aug-17 4:27