wouldn't the following be better ? class CPoteauBeton : public CObject {}; class CVerifiPoteau : public CPoteauBeton {}; Serge

just insert this one as the very first line of your code: #include "stdafx.h"

>> If there isn't one why do I keep hearing people saying to move away from MFC and learn .Net. One of the reason to move away from MFC is that it is not backward compatible between versions. For example, there are lots of changes (documented and non-documented) between MFC 6 (Visual Studio 98) and MFC 7.0 and MFC 7.1 (.NET 2003). So, if you have a large-scaled project, heavily based on MFC 6 and you are planning for migration to .NET 2003 with MFC 7, be prepare for lots of compile-time and run-time surprises. Serge

>> The compiler seems to add some _extra_ info before the actual array data it adds the size of the array so that the 'operator delete[]()' *knows* how many objects it must delete. Looks like you need to overload the 'operator delete[]()' so you can implement your own memory management system; and do not fogort to implement the corresponding 'operator delete()' and 'operator delete[]()' Serge

#ifdef _DEBUG #define TEST test #else //#define TEST #define TEST 0 #endif void test(int, ...) { std::cout << "Hello, World from test() \n"; } int _tmain(int argc, _TCHAR* argv[]) { TEST(5, std::cout << "Hellow, World from _tmain! \n"); return 0; } Note that if #define TEST in Release mode, the test() function will never get called, but its parameters are get evaluated; so if you do not want this side effect, use: #define TEST 0 Regards, Serge

http://www.codeproject.com/cpp/cppforumfaq.asp#win_sendmail[^]

do you mean the thread gets blocked on the recv() function if no data ? if yes, that's the expected behaviour: If no incoming data is available at the socket, the recv call blocks and waits for data to arrive according to the blocking rules defined for WSARecv with the MSG_PARTIAL flag not set unless the socket is nonblocking. In this case, a value of SOCKET_ERROR is returned with the error code set to WSAEWOULDBLOCK. The select, WSAAsyncSelect, or WSAEventSelect functions can be used to determine when more data arrives. Serge

1. Yes it is possible to use cout inside the for loop. 2. The fragments are not the same: the first one prints 1 through 11 with a new line at the end; the second prints 0 through 10. 3. The pseudo code for the ‘for’ loop: for (expression1; expression2; expression3) { Body; } is somewhat like this: EXECUTE expression1; LABEL1: IF expression2 is FALSE GOTO LABEL2 EXECUTE Body; EXECUTE Eexpression3 GOTO LABEL1 LABEL2: This pseudo code should answer why the fragments do not provide the same results. Note that the 1st fragment has an empty body. 4. From CPU usage point of view, the 1st one executes 11 'cout << i' operations and 12 times flushes the buffer (‘cout << endl’), whereas the 2nd one - 11 and 11 respectively, so the second one is faster. 5. From the code size point of view, the 2nd one is smaller as it contains 2 cout calls, whereas the 1st one – 3. 6. It is hard to say about advantages as the two are not equivalent from the point of view of producing the result. Serge

also, keep in mind that Microsof didn't include dlls to run release versions of C++ .NET applications on Server 2003. (you can run release versions of VC6 apps, but not VC7 apps) Serge

Yes, they are defined in LIMITS.H Serge

1. See: http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.7[^] 2) See http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.8[^] Serge

Here’s the easiest way to set the default console foreground and background colors from a .NET console application: Serge #include "stdafx.h" int _tmain(int argc, _TCHAR* argv[]) { // paint in red on black: ::system("COLOR 04"); std::cout << "Hello, World!" << std::endl; return 0; } /* C:>color /? Sets the default console foreground and background colors. COLOR [attr] attr Specifies color attribute of console output Color attributes are specified by TWO hex digits -- the first corresponds to the background; the second the foreground. Each digit can be any of the following values: 0 = Black 8 = Gray 1 = Blue 9 = Light Blue 2 = Green A = Light Green 3 = Aqua B = Light Aqua 4 = Red C = Light Red 5 = Purple D = Light Purple 6 = Yellow E = Light Yellow 7 = White F = Bright White If no argument is given, this command restores the color to what it was when CMD.EXE started. This value either comes from the current console window, the /T command line switch or from the DefaultColor registry value. The COLOR command sets ERRORLEVEL to 1 if an attempt is made to execute the COLOR command with a foreground and background color that are the same. Example: "COLOR fc" produces light red on bright white */

This looks more like resource exhaustion rather memory exhaustion; I’ve seen similar behaviour when applications create too many socket connections with dedicated threads serving such socket connections.

Thanks!

Hi Christian, Considering changes to the compiler, I completely agree with your comment; but there’s more than just a compiler: changes in MFC between version 6 and version 7. Just a couple of them to give you an idea on the amount of work when migrating large MFC based projects from VC6 to VC7. 1. Changes in CFile class interface: virtual DWORD CFile::GetLength( ) const; // MFC6 (Visual C++ 6.0) virtual ULONGLONG CFile::GetLength( ) const; // MFC7 (.NET 2003) so that compiling code like this: CFile f; DWORD dwLength = f.GetLength(); will now produce compiler warnings on loosing data; and certainly, this kind of warnings can’t be ignored. Add millions user-defined specialisations of the CFile class in a large MFC based project to complete the picture (actually, it is a good example of when inheritance bites and aggregations should be used instead); 2. Changes in CTime class: in the interface (similar to the 1.) and in size: size of objects of the CTime class is now 8 bytes, instead of 4 bytes; our software serialises objects of the CTime class through sockets; therefore the backward compatibility issue. The change in the CTime class breaks backward compatibility with the legacy systems that can’t be upgraded to run applications built under VC7 with MFC 7; even our non-legacy systems can’t be upgraded in one go, so this backward compatibility issue will exist for a transition period of time. Also consider the backward compatibility requirement (support for both VC6 and VC7 for a transition period of time) so source code now looks like this: CFile f; #if _MFC_VER >= 0x0700 // represents MFC version 7 and later ULONGLONG llLength = f.GetLength(); #else DWORD dwLength = f.GetLength(); #endif and requirements for unit, build, factory etc. testing for two versions - so you’ve got the picture… Serge

Good people, If anybody seen any links on other good people’s experience on migrating large VC++ 6.0 projects to .NET, could you please send the links to me. Thanks, Serge

PJ, thanks, it works, but it does not make any sense… 1) check out what MSDN says on this: A DAO recordset in a non-UNICODE build expects strings to be ANSI. Thus, for DAO functions that use COleVariant objects, if you are not creating a UNICODE recordset, you must use the COleVariant::COleVariant( lpszSrc, vtSrc ) form of constructor with vtSrc set to VT_BSTRT (ANSI) or use SetString with vtSrc set to VT_BSTRT to make ANSI strings. For example, the CDaoRecordset functions CDaoRecordset::Seek and CDaoRecordset::SetFieldValue use COleVariant objects as parameters. These objects must be ANSI if the DAO recordset is not UNICODE. 2) It breaks backward compatibility with MFC6, namely this one will print just one letter “H”: #include "stdafx.h" int main() { COleVariant v; v.SetString("Hello, World!", VT_BSTR); CString s; // why 's = v.pcVal' works, but 's = v' does not? s = v.pcVal; std::cout << (LPCSTR)s << std::endl; return 0; } so the backward compatible version of a non-Unicode build should be like this: #include "stdafx.h" int main() { COleVariant v; v.SetString("Hello, World!", #if _MFC_VER >= 0x0700 // represents MFC version 7 and later VT_BSTR); #else VT_BSTRT); #endif CString s; // why 's = v.pcVal' works, but 's = v' does not? #if _MFC_VER >= 0x0700 // represents MFC version 7 and later s = v; #else s = v.pcVal; #endif std::cout << (LPCSTR)s << std::endl; return 0; } but does it make any sense? Thanks, Serge

Michael, MSDN states that “Visual C++ provides limited support for XML documentation comments”. I do not know what they mean by that (what is supported and what is not), but as per the .NET 2003, even if I want to attach a simple summary to a class, like this: /// /// This is my Visual C++ class /// class MyClass { }; Visual C++ would generate an empty Comment Web Page (via the “Tools | Build Comment Web Pages…” option). And the Visual C++ compiler does not support the /doc compiler option as the C# compiler does. May be other people have something to say on this? Serge

Good people, Does anybody know why the following code, compiled under .NET 2003, prints junk instead of the expected “Hello, World!”?. Thanks, Serge #include "stdafx.h" int main() { COleVariant v; v.SetString("Hello, World!", VT_BSTRT); CString s; // why 's = v.pcVal' works, but 's = v' does not? s = v; std::cout << s << std::endl; return 0; }

Can you try this: #import rename_namespace("ADO") rename("EOF","ADOEOF")