Printable View
Hi Experts,
Just a quick one, can anyone recommend any decent books / sites that can teach you C++ from someone who has a fairly good knowledge of C and the WinAPI.
Main things i am interested in mastering are the object oriented features and concepts.
Thanks in advance.
Accelerated C++ by Koenig & Moo. That book is geared to programmers who know another language that want to learn C++.Quote:
Originally Posted by RipRage
Also, realize that C++ is a different language than C, and you may/will need to unlearn a lot of things you did in 'C'. This means that a lot of things you did when programming in 'C' are not necessary, and in some cases, invalid in a C++ program.
Regards,
Paul McKenzie
I just want to add my $0.02. I learned C++ and then got an internship at a company that uses both C and C++. Yes, they are similar in some aspects, but they really are two different languages. So, I would keep that in mind when learning C++.
As someone who learned C long before C++, I can atest that C++ is a superset of C. They are not different languages.
That said, C follows a Procedural approach to programming, whereas C++ was designed around Object Oriented Programming. That is the real difference and the reason so many people believe they are different languages.
I have converted hundreds of thousands of lines of C code to C++. I can tell you that while there are a few things in the C99 Standard that are incompatible with the C++ Standards, there isn't anything in C that is invalid in C++.
That is absurd. Unless C++ is C, which is obviously not the case, they are different languages. I suggest reading Stroustrup's answer to the FAQ: Is C a subset of C++? for a more sensible way of expressing the relationship between C and C++.Quote:
Originally Posted by mlgoff
When paradigms and idioms appropriate to C and C++ differ (and this is more than just a matter of procedural versus OOP), it is indeed the case that they are different languages. Pretending that modern C++ is just an extension to C is a poor way of approaching C++.Quote:
Originally Posted by mlgoff
Indeed, as far as I know, C++98 attempts to be compatible with C89, and C++11 attempts to be compatible with C99, though with some differences. Nonetheless, a valid C program is not necessarily a valid C++ program.Quote:
Originally Posted by mlgoff
You might want to re-read that one yourself. Effectively (rather than mathematiucally) C is a subset of C++.
"Thus, C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985. "
More precisely, C is effectively a proper subset of C++, and the differences imply different paradigms and idioms that are appropriate to each. Therefore, C++ is a different programming language from C.Quote:
Originally Posted by mlgoff
Stated that way, I agree.
So in other words the effort that gave you all the experience was just to compile the code as C++ instead of C? ;)Quote:
Originally Posted by mlgoff
When I state "invalid", I'm meaning using 'C' constructs within a C++ program without any regard for those big differences in the two languages.Quote:
Originally Posted by mlgoff
How many times has stuff like what you see below been posted here? Too many times.
Then the 'C' programmer scratches their head in amazement that the program crashes or works sometimes and not other times.Code:#include <stdlib.h>
#include <string>
struct S
{
std::string s;
};
int main()
{
S* pS =(S*)malloc( sizeof(S) );
pS->s = "abc123";
free (pS);
}
How about examples that look like this, which again, seems to be posted on a bi-weekly basis here:
The above is what a C programmer habitually does when writing to a file in binary mode -- OK for 'C', not so much for C++. This won't crash, but the file will more than likely contain junk, not the string they expected to have.Code:#include <string>
#include <stdio.h>
struct S
{
std::string s;
};
int main()
{
S pS;
pS.s = "abc123abc123abc123";
FILE *f = fopen("whatever.bin", "wb");
if ( f )
{
fwrite( &pS, 1, sizeof(S), f );
fclose ( f );
}
}
Regards,
Paul McKenzie
There are a few things. Assuming an implicit return type of int isn't valid in C++ and neither is assigning a (void*) return from malloc to another pointer type without a cast.Quote:
Originally Posted by mlgoff
No. A lot of debugging was involved. But it was more due to non-standard compilers/language implementations than to differences between C and C++.Quote:
So in other words the effort that gave you all the experience was just to compile the code as C++ instead of C?
Granted.Quote:
When I state "invalid", I'm meaning using 'C' constructs within a C++ program without any regard for those big differences in the two languages.
I wasn't thinking about those things. I was thinking about the C Standard Library and general syntax.Quote:
There are a few things. Assuming an implicit return type of int isn't valid in C++ and neither is assigning a (void*) return from malloc to another pointer type without a cast.
Obviously there are differences. But from the stand-point of learning C++, the biggest obstical is not syntax, it is the difference between Procedural and OOP paradygms. RipRage's knowledge of C should serve him well.
BTW- I didn't know Stroustrup had a FAQ. I've really been enjoying it. I also understand Paul's initial assertion that they are separate languages. Thank you.
Thank you for your replies experts.
Thank you for this Paul, i have jumped straight into this.Quote:
Originally Posted by Paul McKenzie
Yes, this will be the hardest part for me.Quote:
Originally Posted by mlgoff
Thanks again all.
OOP is only one way that C++ can be used. I actually think that generic programming using templates is a bigger difference in some ways.Quote:
Originally Posted by mlgoff
Also critical, though related, is learning to use RAII techniques, especially the STL. You can write OOP code in C++, but if it uses C style memory management internally, you are wasting your valuable time.
Hi Experts;
I also forgot to mention, what is the best way to use the C++ STL with the windows API. Since the API is built using C, i would like to know if it possible to pass std::wstring and std::vectors etc to parameters that take for example PTSTR, LPWTSR etc for some of the common functions contained within the API,
Or since this is C++, shall i stop using the API and start learning MFC ?
Thanks in advance?
MFC won't completely shield you from the API, but it does make writing Windows programs much, much easier.Quote:
Originally Posted by RipRage
I don't know your motivation for learning C++, but if I were starting out now and wanting to write Windows apps, I'd be learning C# and .Net rather than C++ and MFC.
The STL is not compatible with the Win API. At least not the way you are indicating that you want to use it.Quote:
I also forgot to mention, what is the best way to use the C++ STL with the windows API. Since the API is built using C, i would like to know if it possible to pass std::wstring and std::vectors etc to parameters that take for example PTSTR, LPWTSR etc for some of the common functions contained within the API,
If your primary motivation is to write Windows apps, I agree with GCDE, concentrating on C# would be the preferred route.
If you are concentrating on Systems or embedded development, I'd stick with C++.
I wouldn't go quite that far. Certainly some care is needed, but the two can be used together.Quote:
Originally Posted by mlgoff
Let's say a WinAPI function has a LPCWSTR parameter. This is Microsoft-ese for "Long pointer to const wide character string," AKA const wchar_t*.
The std::wstring class has a c_str() method which returns exactly this type. So, no problem there.
If it were a LPWSTR instead, (wchar_t*, no const) then the c_str() method would not be appropriate. However, there are still two appropriate options.
For any vector<T> v which is non-empty, &v[0] is a T* which represents the vector as an array. (Trying to access v[0] can cause a crash if v is empty.) Therefore, we can simply copy the std::wstring into a std::vector<wchar_t> and then pass it to the WinAPI function as such.
In C++11, the string class is guaranteed to be contiguous, so one could do the same thing with the wstring s directly (pass &s[0]) without bothering with the vector.
Hi Lindley
Thank you! this was the answer i was hoping for.Quote:
Originally Posted by Lindley
One last thing, the methods you mention above work for input parameters to a function, but what can you use for output ? i.e a function argument of pStringBuf [out] StringBufSize [in]
My knowledge of C would make me do something like this:
Would i continue like this and then assign std::wstring to the buffer, or is it possible to use std::vector as an output buffer to a function like above ?Code:WCHAR IpStr[INET6_ADDRSTRLEN];
if (!::InetNtopW(AF_INET6, SockAddr, IpStr, INET6_ADDRSTRLEN))
return NULL;
Thanks in advance :-)
So long as you use the resize() method (not reserve) to allocate the desired amount of space beforehand, you can certainly use a vector as an output buffer in this way. The only time you cannot is if the buffer is returned to you as a pointer rather than passed in as a parameter.
In general, however, if you need a buffer of a size known at compile time, then a standard array is a more efficient choice than a vector. (Under C++11, you can use a std::array<T> if you prefer.)
When you are working in C++ rather than C, there is a notion of an "output iterator" which is an even more flexible way of doing things.
Thank you for your helpful comments Lindley, very much appreciated!
I will certainly have a play with this, it may seem silly to use C++ with the Windows API, but because i know the API quite well from programming in C, i thought i would use it in trying to gather a better understanding of C++. Now i just need to drop my C habits ;-)
Thanks again!
Hi Lindley,
Would it be possible for you to please confirm / correct me on this small code snippet below? I just want to be reassured i have taken in what you have stated in the comments above and have it right ;-)
This seems to work correctly:
Looking forward to your reply.Code:int wmain ()
{
/* Store IP address as an std::array<T> */
std::array<wchar_t, INET_ADDRSTRLEN> IpBuf;
/* IP string to convert to binary form */
std::wstring IpStr = L"192.168.2.1";
SOCKADDR SockAddr;
/* Convert to binary form */
if (!::InetPton(AF_INET, &IpStr[0], &SockAddr))
return NULL;
/* Convert to readable string form */
if (!::InetNtopW(AF_INET, &SockAddr, &IpBuf[0], INET_ADDRSTRLEN))
return NULL;
std::wcout << IpBuf.data() << std::endl;
return 0;
}
Regards
Dan.
I think that should be okay, with the caveat that in this day and age, you should strongly consider coding for IPv6 rather than IPv4.
In my opinion, the biggest advantage of C++ over C is the simplification of memory management. Use of C-style APIs vs C++ APIs is a marginal difference by comparison, so I have no issue with you using C++ containers with WinAPI if that's what you like.Quote:
I will certainly have a play with this, it may seem silly to use C++ with the Windows API, but because i know the API quite well from programming in C, i thought i would use it in trying to gather a better understanding of C++. Now i just need to drop my C habits ;-)
You should be calling WSAGetLastError() if there is an error in those socket functions.Quote:
Originally Posted by RipRage
Regards,
Paul McKenzie
That is good! at least i can start to apply C++ to the things i already know. i have been making wrappers for some of the Windows API functions and using them in classes to try and get the hang of the whole OOP approach and seem to being going OK.Quote:
Originally Posted by Lindley
Yes i agree, that was just some untested code i typed in to the forum.Quote:
Originally Posted by Lindley
Thanks Paul, again just some basic code to test out the std::array and std::wstringQuote:
Originally Posted by Paul McKenzie
One suggestion. When calling InetPton, the second parameter is const, so I would suggest passing IpStr.c_str() instead of &IpStr[0]. There are two reasons for this.
First, as I mentioned before, while the &v[0] trick will work fine with non-empty vectors, its applicability to strings is theoretically limited to C++11 which not all compilers in wide use support. In practice, I don't think there are many std::string implementations out there which don't store the string contiguously, but prior to C++11 this was a possibility, so it's best not to rely on it if you want to be compatible with C++03.
Second, the function is probably expecting a NULL-terminated string, and there is no guarantee that std::string will use null-termination internally unless you explicitly request the C-style presentation of it with c_str().
Ok, Thanks Lindley, you have taught me a lot!
One last question in regards to constructors and destructors, its it good practice to include initialization functions such as WSAStartup() or under COM CoInitializeEx() in the constructor ?
My main concern is that there may be a possibility either one of those functions could possible fail. Calling there associate cleanup functions WSACleanup() or COM's CoUninitialize() in the destructor seems OK, although again, they could possible fail.
Regards,
Is it ever appropriate to call WSAStartup() more than once? If not, you would need to control the creation of the type which calls it on construction, perhaps using the singleton or factory pattern.Quote:
Originally Posted by RipRage
If you ever have a case where construction of an object can fail, there are two primary ways to handle it. The first is to set a field in the object to indicate it is invalid. Make this query-able and check it in every method so that you can fail gracefully or print an error message if someone attempts to use an invalid object. For instance, std::ifstream does this if you attempt to construct it with an invalid filename.
The second is in some ways simpler: throw an exception. That way, no invalid object can be created in the first place. This will close your program unless you handle it, of course.
Don't ever throw an exception in a destructor, however.
No, it is not OK to call these in the destructor, unless your destructor catches the exceptions these functions may throw.Quote:
Originally Posted by RipRage
As Lindley pointed out, you never let an exception thrown in a destructor exit the destructor. You have to catch any and all of these exceptions within the destructor. This includes your code, or any other function and/or library function that may throw an exception.
So basically, you want to strive to make sure that your destructor is a "nothrow" function. If you had to call one of these throwable functions in the destructor, the one proper to code the destructor would be this:
Regards,Code:~SomeClass::SomeClass()
{
try
{
// any function that can throw goes here
}
catch( some exception )
{
// non-throwing calls must go here
}
catch (some other exception)
{
// non-throwing calls must go here
}
//...etc... additional catch() blocks for all other exceptions you know about
}
Paul McKenzie
Hi Paul,
Thank you for your post. If its not to much trouble could you show me a working example ? the reason why i ask is because i am making a function fail deliberately like WSACleanup() in the destructor but i am unable to catch the exception...
Regards,
What type of exception is it? Is it a bona-fide C++ exception, where a C++ module actually throws an exception, or is it a Windows SE exception (Access violation, or some OS exception)?Quote:
Originally Posted by RipRage
If it's the latter, then you could try the catch-all:
But you should really fix the problem with your app if it's an OS exception.Code:try
{
}
catch(...)
{
}
I know that no socket functions throws exceptions explicitly, since they are all 'C' functions. The only exceptions possible are the ones generated by the OS (called Structured Exceptions). There is no guarantee, unless you set the proper compile switches, that these are caught (don't remember what these settings are). But at some point, you have to address these exceptions, and they are an indication that your program is faulty.
Regards,
Paul McKenzie
Hi Paul,
Not to worry, i am getting my bearings with MFC now and just trying to experiment with its classes via command shell instead of GUI.
I have ran into a problem and cannot seem to initialize MFC.
but i am getting this exception before main is called and dont i know whyCode:#include <afxwin.h>
int main(void)
{
if(AfxWinInit(GetModuleHandle(NULL),NULL,GetCommandLine(),0)==FALSE)
{ cout<<"Unable to initialize MFC"<<endl; return 1; }
/*
Use MFC Classes Here !!!
*/
return 0;
}
Can anyone help with this ?Code:if (FLS_SETVALUE(__flsindex, (LPVOID)ptd) ) {
/*
* Initialize of per-thread data
*/
_initptd(ptd,NULL);
ptd->_tid = GetCurrentThreadId();
ptd->_thandle = (uintptr_t)(-1);
}
else {
/*
* Return NULL to indicate failure
*/
_free_crt(ptd);
ptd = NULL;
}
}
}
SetLastError(TL_LastError);
return(ptd);
}
EDIT: Debug window displays this: Warning: m_pMainWnd is NULL in CWinApp::Run - quitting application.
Ah my fault!, forgot to add "Use MFC in a shared DLL" in the project settings. All fixed now!