Am I ready for C++ and MFC ?

[Dawoodoz]

I'm finding it particularly strange that you seem to be advocating to use Assembler, and then go on that you write

I never said that people should use assembler. It is better to learn OOP on a virtual machine that allow mistakes before going for performance in C++.

[GCDEF]

If you don't know how assembler level works when using unmanaged C++, you might use a temporary pointer on the stack as a value, get odd race conditions and loose more performance than you gained from using C++ by preventing the compiler from optimizing. I haven't heard of any C++ programmer that never write bugs and when they do, the bugs causes other applications to crash.

But you don't need to know assembly language to understand or debug those problems. I have to go with the poppycock crowd on this one.

[Paul McKenzie]

If you don't know how assembler level works when using unmanaged C++, you might use a temporary pointer on the stack as a value,

But you don't need assembly to know that -- you need knowledge of what C++ considers "undefined behaviour". Either you know your C++ or you don't.

I would even say that using assembly language to figure out what is legal or illegal in C++ is not recommended. What if your program works, even though you are using a pointer to a local variable? How would you know that it is illegal C++ if the assembly code shows that it works?

If anyone came to me and said "it's legal to do this in C++ because the assembly code shows this...", I don't listen any further.

Regards,

Paul McKenzie

[Dawoodoz]

Valid C++ works well in theory but when you do something wrong, that theory means nothing.

[laserlight]

Valid C++ works well in theory but when you do something wrong, that theory means nothing.

And your point is...?

[GCDEF]

Valid C++ works well in theory but when you do something wrong, that theory means nothing.

I don't get it either.

[DanLeon]

Thank you all for your replies ;-)

"Accelerated C++" by Koenig & Moo.

Thank you for this, I will look into it.

I just wanted to ask, is it a bad thing to mix C with C++ ?

The reason why I have asked this is because I have read some source code found on the net which uses printf()'s NOT the (std:rintf() <cstdio>) as suppose to cout. I know this may just come down to personal preference when it comes to I/O but I was more surprised to see standard C string functions like strlen() and strcpy() instead of string::length, and string::copy in classes.

Many Thanks!

-Dan

[somedaysomewhere]

I don't know much about C/C++ my background is C# (started to learn since last summer)
Bad or good is opinions and jobs of the language Standards members and language developers
Being just a normal software developer really doesnt relate much to it because developers must answer "will my joint to make this product benefits better my income ? Can I do it ? Will the final product have no bugs ?"
The last question will be left for QC testing group, rarely do I find bugged products returned if their coders have some actual coding experience, they tend to test while coding (at the same time).

[GCDEF]

I don't know much about C/C++ my background is C# (started to learn since last summer)
Bad or good is opinions and jobs of the language Standards members and language developers
Being just a normal software developer really doesnt relate much to it because developers must answer "will my joint to make this product benefits better my income ? Can I do it ? Will the final product have no bugs ?"
The last question will be left for QC testing group, rarely do I find bugged products returned if their coders have some actual coding experience, they tend to test while coding (at the same time).

The only point I can understand is your last one, and I don't agree with it. The only programs that won't have bugs in them are very small ones. When you get into large, complex systems, there are going to be side effects that programmers can't foresee, and full regression testing is the only way to find them.

[Paul McKenzie]

I was more surprised to see standard C string functions like strlen() and strcpy() instead of string::length, and string::copy in classes.

There are some possible reasons:

1) The author of the code didn't know C++ well enough at the time he/she wrote the code, so they fell back to what was comfortable to them -- using 'C' functions.

2) The code was written a long time ago (before 1998 when C++ became standardized), therefore usage of 'C' functions instead of a non-standard string class.

3) The code was written by a programming student, where the teacher has given them the (IMO) ridiculous constraint that they cannot use std::string. That occurs often here.

4) You are looking at the internals of a string or string-like class, so usage of the 'C' library may show up to do the low-level copying.

5) The author is given a char buffer from potentially another language passed as a parameter, and their function has to fill this buffer with the string data on return. Exported functions from DLL's that fill in a buffer with info usually fall into this category.

6) The author is paranoid or misinformed/illinformed and believes that 'C' functions are safer and faster than C++ classes. Usually the coder is a veteran 'C' programmer who doesn't "trust" C++.

Take your pick. There are probably other reasons, but these are the reasons I've encountered (whether on the job, on programming forums, etc.).

BTW, "Accelerated C++" makes no mention of strcpy(), strcat() or any of those 'C' string functions -- you go straight to the std::string functions for string manipulation. The reason is that these C functions inherently put holes in the security of your program by opening up for buffer overruns.

Unless the coder has written wrappers around these functions to ensure that copying beyond the bounds of the destination buffer cannot occur, the program is a security risk in the worst case scenario, or will run but can potentially cause a memory overwrite in the best case.

As far as mixing C++ with C, the issue is that you should strive to not mix 'C' style programming with C++. The reason is that using 'C' style inherently makes you use 'C' constructs on things that are not 'C' compatible. For example, using memset(), memcpy(), or other 'C' functions on non-POD types is one such error.

If you are to use C style programming in C++, you better know exactly what you're doing and why you're doing it. This means you need to have a solid grounding in C++, know the difference between POD and non-POD types, know that using 'C' doesn't necessarily mean faster code, etc.

In my experience, most of the time I've seen 'C' style used in C++ programs for the simple reason that the coder just didn't know any better, and just fell back to what they knew or what they were comfortable with (which is why I put that first on the list).

Regards,

Paul McKenzie

[Alex F]

It is absolutely OK to use CRT functions like printf or strlen in C++.

[ovidiucucu]

It is absolutely OK to use CRT functions like printf or strlen in C++.

Right.
Even C++ standard has a list of headers for using Standard C Library: <cstdio>, <cstdlib>, <cstring>, and so on.

[vcdebugger]

Hi Paul,
what you mean by POD and non-POD types ?

[Paul McKenzie]

Hi Paul,
what you mean by POD and non-POD types ?

POD stands for Plain Old Data. These types are compatible with 'C' types.

Non-POD types are types that are C++ only. These types include structs/classes that have virtual functions, user-defined constructors and destructors, types derived from other classes/structs, etc. Doing 'C' things on these types usually results in undefined behaviour.

Regards,

Paul McKenzie

[vcdebugger]

thanks Paul for the info.