int to CString

[ADSOFT]

Aha. Here is one solution:

int MessageBoxV(LPCTSTR pszFormat,...)
{
   CString strMsg;

   va_list args;
   va_start(args, pszFormat);
   strMsg.FormatV(pszFormat, args);

   return AfxMessageBox(strMsg);
}

   // somewhere in space, just one line:
   MessageBoxV(_T("X is: %d\nY is: %d\nZ is: %d"), x, y, z);

I like this one, thanks

[ovidiucucu]

Yes I have learned C++, but somewhere I briefly heard that :: calls the old version of the function in the MFC world.

Nope. It just tell compiler to use global identifier rather than the local one.
As long as AfxMessageBox is a global function, prefixing it or not with :: has the same effect.

[ovidiucucu]

I like this one, thanks

You are wellcome! Any time.

[ADSOFT]

Nope. It just tell compiler to use global identifier rather than the local one.
As long as AfxMessageBox is a global function, prefixing it or not with :: has the same effect.

Thanks for clearing that up. ...I'm a big fan of using the ::, global scope operator.

[ADSOFT]

You are wellcome! Any time.

What about the In Line Assembly?


Does MFC support assembly language like "C" ?

[Ajay Vijay]

MFC is not a language. It is build on top of C++ language and it follows C++ language rules. While coding in MFC application you can also use other library like OpenGL or networking libraries. The question you aksed is non-sense.

[ADSOFT]

MFC is not a language. It is build on top of C++ language and it follows C++ language rules. While coding in MFC application you can also use other library like OpenGL or networking libraries. The question you aksed is non-sense.

Well there is no need to get offensive. Just asking a question. If I knew I wouldn't be asking. .... I have other things to do.


I'm aware that MFC is just a Class Library developed by Microsoft to develope Windows applications.

[ovidiucucu]

What about the In Line Assembly?


Does MFC support assembly language like "C" ?

As Ajay Vijay already said, MFC is not a language but a library. It's not an offense to point this.
Well, to clarify:
MS Visual C++ compiler supports inline assembly instructions/blocks of instructions by using __asm keyword.
You can find more in Assembly forum and in An Introduction to Assembly Language article.

[gstercken]

Does MFC support assembly language like "C" ?

As others said, MFC is a class library written in C++. And since Visual C++ supports inline assembly calls, you can of course mix that with MFC calls - although I hardly see any reason for doing that.
As long as you still have problems getting C++ code correct, and without knowing how exactly a C++ construct will be translated to machine code, I can hardly think of any scenario where adding inline assembly would do any good...
Besides that, a typical error made by beginners is to think far too early about optimization. You might spend much time and effort in optimizing something like a simple int-to-string conversion, and when you profile your code, you'll probably find out that it makes up for only 0.0001% of your total CPU time, while other parts of your code which you never took into consideration for optimization use up more than 90%. So as a general rule, write your code so that it is clear, readable, maintainable and working. When you test your app and experience any performance problems (in a release build, of course), instrument your code and start profiling to see where and how your code spends CPU time. And if profiling reveals that there are clear speed bottlenecks (like a significant percentage of the time being spent in something like int-to-string formatting), then you should start thinking about optimizing those parts - but not earlier.

[ADSOFT]

As others said, MFC is a class library written in C++. And since Visual C++ supports inline assembly calls, you can of course mix that with MFC calls - although I hardly see any reason for doing that.
As long as you still have problems getting C++ code correct, and without knowing how exactly a C++ construct will be translated to machine code, I can hardly think of any scenario where adding inline assembly would do any good...
Besides that, a typical error made by beginners is to think far too early about optimization. You might spend much time and effort in optimizing something like a simple int-to-string conversion, and when you profile your code, you'll probably find out that it makes up for only 0.0001% of your total CPU time, while other parts of your code which you never took into consideration for optimization use up more than 90%. So as a general rule, write your code so that it is clear, readable, maintainable and working. When you test your app and experience any performance problems (in a release build, of course), instrument your code and start profiling to see where and how your code spends CPU time. And if profiling reveals that there are clear speed bottlenecks (like a significant percentage of the time being spent in something like int-to-string formatting), then you should start thinking about optimizing those parts - but not earlier.

Well I appreciate your input.

I maybe somewhat of a beginner to MFC(or at least being productive with it), but I'm not a beginner to C/C++ or Assembly language programing.

As far as you comment regarding assembly language not being usefull, I strongly disagree and I'm surprised that you would say that: I guess you haven't done much embedded development.


There are some instances where if you are talking to hardware you have to make sure that things happen in real-time. Having a GUI is great and handy, but the whole beauty of programing in C/C++/Assembly is to be able to get down to the machine and hardware level and write code that executes in instruction cycles:..... which is why I have taken the time to learn MFC: After having progrmmed in C/C++ and Assembly language for a while.


... so I might not be an Expert in MFC(i.e it's Class Library and Macros, etc) but I've been doing C/C++ and Assembly for a while, and like I said before, my only motive to learning MFC is the be able to access the hardware directly and speed.


I respect your knowledge of MFC, but to say that Assembly language is not important to MFC is a little .

Anyhow, I have my coding style and have worked with outher C/C++/Assembly Libraries and I just wanted to tailor some functions to libraries that I'm familiar with.

As a matter of fact there are many functions that I have created which emulate libraries that I have already worked with.

[ovidiucucu]

Well, everyone may be able to write assembly code much more worse than any compiler, but as long as the OP asks for it there is nothing wrong to point it in the desired direction. Although I didn't see any cool optimization for displaying a humble modal message box.

[ADSOFT]

Well, everyone may be able to write assembly code much more worse than any compiler, but as long as the OP asks for it there is nothing wrong to point it in the desired direction. Although I didn't see any cool optimization for displaying a humble modal message box.

Well I was trying to optimize typing: ..... and it works for me. I guess we are all intitled to our opinion. ... I wasn't trying to optimize code or processing speed. When you get a diagnostic message on the board, all execution stops anyways.


... that's the beauty of C/C++/Assembly you can tailor it to how you think or are most familar with.

I do a lot of stuff with MessageBoxes, but I like format a whole box in one line of typing. .... which was my goal.

I'm still sorta getting familiar with MFC CLASS LIBRARY and it's macros, ide, etc., and I can understand that Microsoft had to do some creative things to handle all the messages that windows has to manage , but like I said before, I have worked other C/C++/Assembly Language libraries and I wanted to tailor it to the functions and styles of those libraries.

[cilu]

ADSOFT, I just want to say that #defining a function or a piece of code for reducing the code size is a bad idea.

#define amsg AfxMessageBox

If I was seeing this

amsg("gigel");

somewhere how could I knew what amsg is? That only reduces readability, which is very important, especially when your code needs to be maintain, and that is done by someone else that you.

Moreover, remember that you cannot debug macros.

I strongly advise against this kind of coding.

[ADSOFT]

ADSOFT, I just want to say that #defining a function or a piece of code for reducing the code size is a bad idea.

#define amsg AfxMessageBox

If I was seeing this

amsg("gigel");

somewhere how could I knew what amsg is? That only reduces readability, which is very important, especially when your code needs to be maintain, and that is done by someone else that you.

Moreover, remember that you cannot debug macros.

I strongly advise against this kind of coding.

Good question!!!

If I had a previously worked with a C/C++/Assembley language library that had a function called 'amsg' which displayed out the screen , then my first function would be:

void MyFirstFunction(void){
  
    amsg("Awesome, I'm hitting the road Running. This MFC stuff is fits like a glove, lol!!!!. \n Just like the Library I have been working on!!! \nWhat Else does MFC have that I'm used too!! " + (CS)"\nI'm going to give this library a :" + itoS(10) +(CS) "!!!!!");

}

See how I did that all on one line!!!

[cilu]

See how I did that all on one line!!!

Except that I would have inlined that MyFirstFunction().