C / C++ / MFC

I was making the wrong function call. v_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small"); should have been execute_assert(s = MAX_ACL_DEPTH, "MAX_ACL_DEPTH too small"); Problem fixed. Thanks all.

Found out the way to do that without actually removing Hex. Used <

As I understand it, the FD_WRITE message means you have a connection and room in the output buffer to accept data. After you get FD_WRITE, use send() to send data when you have it.

Well, Nearly per Definition you can Not use a C Compiler to compile CPP! You do not understand where it all came from, but I'll ex[plain. 'C' was created by Brian Kernigan and Dennis Ritchie as a High Level Language, with the flexibility of Assembler. It has a straight forward flat language structure, needing a very simple symbol table. (The Symbol Table is a database used by the Compiler, to keep track of what symbolic value is stored where) This database would not allow for items like 'MyStruct.MyMember'.Instead, it kept a separate Database of Structure Names. When Brian Stroustrep started CPP, it was initially a 'PreCompiler' which would write a 'C' acceptable set of variable names. For Intance: void MyStruct::MyFunct(int,char,int) would be translated into something like 'FnMyStruct_MyFunct_int_char_int__void' and then let the 'C' Compiler do it's Job. That worked of a kind, but, what if one also were to write a 'C' function: 'FnMyStruct_MyFunct_int_char_int__void(int Param)' Unlikely, but, a potential problem. Brian Stroustrep had to use symbols and characters acceptable to the 'C' language. When proper CPP Compilers appeared at the scene, the decoration became more flexible. For Instance: 'FnMyStruct?MyFunct??int_char_int???void' Such a name cannot be passed as a 'C' Name. (Note: I do not state that the scheme here is actually used, it is just an illustration to explain the point of how a CPP Compiler generates different code compared to a 'C' compiler) A CPP compiler can compile 'C' Code. The otherway around, a 'C' Compiler accepting CPP Code is never going to happen, for the reasons stated above. Now, As others have Asked: what is your problem! Perhaps you want to Include a 'C' Module in your 'CPP Project' :) Bram van Kampen

Thanks for your reply! I don't know, to be honest. The problem was occurring when I AltF4ed or clicked on Close Window but not when I clicked on my 'Exit' button. However, it looks like it was a corrupt memory problem I had with a member variable I'd assigned to the heap and was using to pass data between threads. I've changed the communication to the following: In the sending thread: ControlDlg \* pParent = (ControlDlg \*) this->GetParent(); ColourAlphaEnvelope \* s = new ColourAlphaEnvelope; \*s = m\_ColourEnvelope; pParent->PostMessage(CM\_COLOURBOUNDS, reinterpret\_cast<WPARAM>(s)); and in the recieving dialog I used afx_msg LRESULT CRectArtDlg::OnCmColourbounds(WPARAM wParam, LPARAM lParam) { std::auto_ptr<ColourAlphaEnvelope> s(reinterpret_cast<ColourAlphaEnvelope*>(wParam)); m_colourEnvelope = *s; return 0; } I bet there are dozens of better ways of doing this (not least since a quick Google reveals that auto_ptr is depracated) but I haven't had a crash and the compiler isn't telling me there is a memory leak.

The information is not stored in a DLL. It is stored in a database file (the WMI Repository) in the directory %windir%System32\Wbem\Repository\. See also WMI Overview[^] and Windows Management Instrumentation - Wikipedia, the free encyclopedia[^].

Of course.

Richard was spot on ADO and ADOX both use the no_namespace option you need to rename the functions of one into a renamed namespace #import "..\..\..\dll\msadox.dll" // Importing Adox unchanged in this example #import "..\..\..\dll\msado15.dll" no_namespace rename("EOF", "EOFADO")rename("DataTypeEnum", "DataTypeEnumADO") rename("EditModeEnum", "EditModeEnumADO") \ rename("FieldAttributeEnum", "FieldAttributeEnumADO") rename("LockTypeEnum", "LockTypeEnumADO") // Rename each function you want to use into current namespace with ADO at end // The ADO at the end just makes remembering the name easy You could choose to import the ADO and rename the ADOX functions, rename the one you use least. In vino veritas

correct on all counts, you have correctly identified that the standard makes the code much more easily readable and helps you identify errors. I enforce the standards at our company and I therefore never write without using that standard. The standard we use is essentially an extension of C99 or sometimes called ANSI-C standard and is used heavily in the sector I work, which is embedded programming. Companies in the game market you are looking at tend to use C++ (UNREAL GAME ENGINE etc) or C# (UNITY GAME ENGINE) and there standard may differ slightly as the majority of the code won't be C compliant, and they have other pressures for readability. So generally in large companies you will be expected to write to a standard and there will usually be a process to check code into the active repository. So while learning coding try and have your own standard but just remember you may have to adapt when you are employed. The company is not going to rewrite an entire repository to your standard even if you could argue it was better. So my standard is not the "absolute best" it's just a standard I would generally have to write to at work. In vino veritas

I have doubts this will work the 8.1 kit code is expecting v120XP platform toolset and linking. It will be really interesting to see if it does work. Is there a reason you can't just download and install VS2015, something funky with the code? In vino veritas

It does offer boundary condition, just use modern C++ constructs (vector, array, string...) instead of their unsafe C equivalent (pointers, char*...) If you are using a modern version of Visual Studio, there are additional checks made by the compiler and runtime to check boundary conditions (Security Features in the CRT[^]) and also they offer a set of safer runtime API (all the _s functions like strcpy_s instead of strcpy) Remember that if the language let you shoot yourself in the foot, there is no excuse try not to by following best practice when coding. I'd rather be phishing!

Since your existing libraries can be linked, you need not convert them all at once. However, if you really do intend to abandon the Fortran compiler, then convert them you must, eventually. However, C++ and Fortran are enough alike that the conversion may be simpler than you think. For instance, the control structures should be fairly straightforward. While you may have to visit each one briefly, I suspect that a lot of the conversion can be handled by editor macros or Perl scripts written around regular expressions. If the libraries use PRINT and FORMAT statements, all of which will need to be completely rewritten to use something like sprintf(), you may not be able to do quite as much with automation, though I would explore it. It's been too long, and I've forgotten most of what I once knew about FORMAT statements, but it's quite possible that you can accomplish much of that conversion with regular expressions, too. Along that line, since they are essentially literal constants, consider replacing the FORMAT statements with #define macros or string resources, so that they incur little or no runtime overhead. There is a trade-off between #define macros and string resources. A #define resolves to a constant that is baked into the code, and costs basically nothing to use. A string resource requires a Windows API call (LoadString) every time you need a new pointer to the string. If you set your character set to Unicode and null terminate your string resources, LoadString can return a pointer to the string, right where it sits. There is a resource compiler option, settable in the project configuration, to null terminate your resource strings. Otherwise, you need a buffer of up to 4097 TCHARs to hold each string. Better yet, let MFC look after all of that by using its CString class, which even sports a LoadString method that looks after the memory for you. Another potentially thorny issue is COMMON blocks, either blank or labeled. Blank common is essentially process global storage that must be externally linked, and is usually easiest to define as part of the source file in which main() is defined. If there are also labeled COMMON blocks, consider putting each into a static class. Regardless, the actual common block definitions should go into header files. If you surround them with preprocessor guard cod

yea.. same is the case with codeblocks and bloodshed dev-cpp

leon de boer wrote: Sometimes I just shake my head at answers offered I get much the same feeling with more and more of the questions posted here.

I am not convinced there is a leak ... Please explain this statement After running the code , it's about 85M memory cannot be release on my computer How exactly do you know it isn't released? For example looking at the memory use in Task manager means nothing if that is all you are using. So has this statement got some actual tool basis? If all you are doing is running task manager run the Test for me twice please one after another. void CTestMemDlg::OnOK() { Test(); test(); // RUN test a second time .. if you are bleeding memory use will double CString strInfo; strInfo.Format("Object construction: %d destruction: %d \r\n",g_cCount,g_dCount); AfxMessageBox("finish\r\n"+strInfo); } If the memory use doesn't double to 170M you aren't leaking memory at all you just misunderstand what windows task manager is reporting. In vino veritas

You can either 1.) Scan each character of the entry before doing anything with it, this is the generic form of a parser. 2.) Try converting it and if you get an error prompt, reloop and ask for entry again. 3.) Look for an error and if found exit program with error notification. Which depends on what the source of the number is and what your goals with your program are. For example if the source of the number is a file not much use prompting and asking for re-entry ... files can't do anything about it :-) So the question comes down as, in the program you are writing what do you think it should do? What is the most elegant and most useful? In vino veritas