|
Here is how I usually check for memory leaks in my code. The concept is just a hacked method from a Chris Losinger's article[^].
I use Boost Test Library[^] as my unit-test framework, and at the beginning of init_unit_test_suite function I place the following code:
_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG );
_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDERR );
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG );
_CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDERR );
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG );
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
_CrtSetReportXXX functions cause memory leak reports to be dumped out to the stderr (in practice, the console window) as well as to the output window within VS IDE. CrtSetDbgFlag is there to make the report be displayed regardless of the place where the program terminates. Otherwise, I would need to manually call _CrtDumpMemoryLeaks(); at my program's exit points.
Also, at the beginning of the unit-test cpp file, after other #includes, I put this:
#include <crtdbg.h>
#ifdef _DEBUG
void* operator new(size_t nSize, const char * lpszFileName, int nLine)
{
return ::operator new(nSize, 1, lpszFileName, nLine);
}
#define DEBUG_NEW new(THIS_FILE, __LINE__)
#define MALLOC_DBG(x) _malloc_dbg(x, 1, THIS_FILE, __LINE__);
#define malloc(x) MALLOC_DBG(x)
#endif // _DEBUG
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
In the best-case scenario, there is no output at all  However, if I have a memory leak in, say, mymodule.cpp the output would look like:
Running 2 test cases...
*** No errors detected
Detected memory leaks!
Dumping objects ->
{2455} normal block at 0x00A793E0, 512 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
Press any key to continue
This is helpful in a sense that it tells me I have a memory leak, but it does not tell me where the leak actually happens. To find this out, I add the same code (the bunch that goes at the beginning of the cpp file, not the _CrtXXX calls) at the beginning of the suspicious cpp file(s) (in the worst case scenario, to all my cpp files), and than run unit-tests again. The result:
Running 2 test cases...
*** No errors detected
Detected memory leaks!
Dumping objects ->
c:\myprojects\leakssample\mymodule.cpp(1303)
: {2455} normal block at 0x00A774B8, 512 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
Press any key to continue
Aha! What is at the line 1303 of mymodule.cpp?
char* leak = new char[512];
Bingo!
After I fix a memory leak, I just undo the changes from my source control system to keep the production code cleaner.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Here is a link to the "official wishlist"[^] for changes in the next version of the C++ Standard Library.
Items I really like:
- A threads library
- A socket library
- Explicit support for Unicode
- A way of manipulating files that a part of a directory structure
Items I don't like:
- some form of simple graphic/GUI library (possibly a simple interface to the simpler parts of larger libraries)
- Versions of the standard containers with virtual destructors
For others, I have mixed feelings. Generally they sound good, but maybe we should keep them out of the Standard library.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I found out that a small group of smart people (including Boehm and Alexandrescu) is lobbying for including threading support into the next C++ standard.[^].
This is interesting. So far, we have used threads either from C libraries (Win32 threads, pthreads) or from some C++ libraries built on top of the C ones (Boost Threads, ACE). Now, the proposal is not only to add a threads library to the Standard, but also to make C++ compilers thread-aware.
But what happens on systems where threads simply don't exist? 
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Simple, you have to target the hardware and select threading or non-threading libs.
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
What I mean is: now it is possible to make fully Standard compliant compiler (and libraries) even for platforms that don't support threading. After a threads library is added, is it going to be possible?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote:
now it is possible to make fully Standard compliant compiler (and libraries) even for platforms that don't support threading.
Yes. It's possible to implement a user-mode threading library - that's all that the pthread library is for Unix/Linux. The threading is supported fully within the user process; the OS doesn't even know (or care) they exist.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
The problem exist even today, not all platforms support files and directories, and yet std::fstream and std::fopen exist in the standard.
|
|
|
|
|
Maybe I'm not understanding everything, but what's the gain for moving thread processing out of the OS domain, and bring it into the language specification of C++?
I've been using CreateThread() with its associated set of API's and it's been working fine that way. What's to be gained by having a C++ 'pthread' when using CreateThread() returns a pointer to the newly created thread anyway.
I must definitely be missing out on something.
William
Fortes in fide et opere!
|
|
|
|
|
CreateThread (or better, __beginthreadex) and pthreads are the "C" way of doing things, and as many other C constructs they are not particulary safe and easy to use. Have you tried Boost threads for instance? That's the C++ way of dealing with threads.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I admit I was not exactly a fan of Simon Robinson[^]. A couple of years ago, I bought his book Professional C#[^] and found out that a more appropriate title would be "C# for total beginners who have too much time to spend on such a simple language as C#". I paid $60.00 for the book and still feel I wasted the money. I really learned C# from C# Language specificatin[^].
However, I recently run into a great offer from Amazon for Robinson's other book Advanced .NET Programming[^]. A used copy was offered for less than $6.00, so I bought it mostly for its low price. The book turned ot to be great: covers the topics I am really interested in, easy to read, practical and useful. A real refreshment among all those .NET books that describe the same basic things.
Good job, Dr Robinson.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I like to program under Unix-like environments. It is fun, and development tools are powerful, flexible and (many of them) free. Also, Unix command line shells are much better than the one that comes with Windows. What I don't like, though, is wasting time on configuring Unix-like operating systems and rebooting between them and Windows. Therefore, I use Unix emulators on Windows.
On my work machine, I have installed Windows Services for Unix (SFU)[^]. It works great with Windows, and it comes with many great tools. Even more utilities can be downloaded from the Interix website[^]. One thing that can't be downloaded for free is X server.
On my home machine, I have installed Cygwin[^], a Linux-like environment for Windows. It comes with many more utilities than SFU (including X), but it can be a little buggy, and the installation proces is awkward. Also, it is slower.
So far, I like both and still haven't decided which one to install on my laptop.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Have you heard of static classes, coming in C# 2.0 (Whidbey)? These are classes which are not intended to be instantiated. They can contain only static members. Ie:
static class Algorithms
{
public static void swap<T>(ref T left, ref T right)
{
T temp = left;
left = right;
right = temp;
}
public static T max<T> (T left, T right) where T : IComparable
{
if (left.CompareTo(right) > 0)
return left;
else
return right;
}
}
Wait a minute! Classes are supposed to be patterns from which objects are instantiated. If you can't instantiate an object from a class, well it is not a class, is it? Why not simply allow non-member methods and group them in namespaces?
I can think of only one reason: marketing. It simply does not look "OO" enough. Although static members of static classes are for all practical purposes non-member methods (with an extra inconvenience that the class' name must be typed each time you invoke them), by keeping them in "static classes" the ilusion of "pure OO" is better preserved.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I rarely take part in Soapbox forum discussions, and generally find them boring. However, this rant was really great - a sort of Declaration of Independence from STL - style programming:
Forofobia[^]
Peterchen[^] seems to be pretty angry with the trend in modern C++ to replace loops with STL-like algorithms. He says, among other things:
Look the framework we have to build to minimise (not remove, just "minimise") writing loops:
iterators. const. unidirectional. bidirectional. reverse iterators. const or not. iterator adaptor. functors. binders. composers. bind. function. lambda library. anything I forgot? most likely. We need to templatize like hell, bending the compiler to a point where we are happy it makes it through our code alive - and when not, we don't dare ask for sensible error messages. To avoid what?
...
It's a loop, for god's sake. It's not a bear trap, it's not the infamous goto-spaghetti mess, it's not a terrorist nuke we have to keep out of our code whatever sacrifice of sanity is necessary.
What can go wrong in a loop?
- you forget to increment
- you are off by one
- you invalidate the container or the iterator
The first requires some discipline, the second some basic calculus training, and the third heaven forbid thinking! whoo!
...
Resolution: From now on I'll call all algorithm aficionados loopophobics. Yes, Scott Myers, this includes you.
Some of the comments from the fellow programmers:
after a certain point, trying to turn C++ into Haskell just creates confusion for anyone unfortunate enough to have to maintain the code.
...
for loops are way too readable, the whole purpose of STL and especially Boost is to enable the production of completely unreadable code that will utterly confuse the slack-jawed imbecile who only knows C# and is asked to maintain my C++ code.
...
This seems to be complexity for complexity's sake, or possibly just to distance itself from anything obvious non-STL
...
Peterchen mentioned Meyers probably because of his article STL Algorithms vs Hand-Written Loops[^] in which he generally favors the use of algorithms rather than loops.
However, I would agree with Meyers' conclusion on this matter:
In the ongoing tussle between algorithm calls and hand-written loops, the bottom line on code clarity is that it all depends on what you need to do inside the loop. If you need to do something an algorithm already does, or if you need to do something very similar to what an algorithm does, the algorithm call is clearer. If you need a loop that does something fairly simple, but would require a confusing tangle of binders and adapters or would require a separate functor class if you were to use an algorithm, you’re probably better off just writing the loop. Finally, if you need to do something fairly long and complex inside the loop, the scales tilt back toward algorithms, because long, complex computations should generally be moved into separate functions, anyway. Once you’ve moved the loop body into a separate function, you can almost certainly find a way to pass that function to an algorithm (often for_each) such that the resulting code is direct and straightforward
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I am aware of at least three bad attempts to fix C++: Java, C# and D. Some would argue that Managed C++ (C++/CLI) is one of these attempts as well, but I just view it as a set of extensions to C++, not a new programming language.
Now, I found Heron[^], and so far I like what I see.
The main problem with Heron is that it is just another one-man project, and it has close to zero chances of ever becoming mainstram. So far the author has released a Heron front end that converts Heron to C++, an editor, and some (pretty poor and incomplete) documentation.
Having said all of that I really like the philosophy of Heron and most of its features:
- No backward compability with C and all the problems that come with it.
- No virtual functions; polymorphism is achieved through interfaces
- All fields are private
- Support for value semantics, real destructors and deterministic finalization
- No built-in garbage collector
- Rich support for meta-programming
- Support for AOP and design-by contract.
It is a pitty that Microsoft decided to copy Java when they designed C#. Something like Heron would be a much better solution, IMHO.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Thanks for the positive comments and support.
I quite understand your scepticism but I am very confident Heron will become mainstream. There has been a steadily increasing amount of interest in it. There have been a lot of preliminary benchmarks of earlier versions of Heron outperforming C++ when dealing with objects.
The documentation is a bit of a mess because I am now working hard on making a Heron to C translator (essentially a compiler). It is a challenge keeping everything up to date simultaneously.
As far as being a one-man show, many succesful languages fall into that category.
I encourage you to consider joining the Heron mailing list, which is very low-traffic, to keep abreast of new developments at http://lists.sourceforge.net/lists/listinfo/heron-misc
Christopher Diggins
http://www.heron-language.com
|
|
|
|
|
Thank you for commenting my post. I will certanly keep an eye on Heron, and maybe even write an article about it for Code Project some day.
cdiggins wrote:
I am very confident Heron will become mainstream
That would be great. However, the computing world is moving towards "managed environments" (JVM and CLI), and Heron's object model (although technicaly superior, IMHO) does not seem to fit into it very well. Do you think it would be possible to make "Managed extensions for Heron" and how it would impact the language?
Thanks.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
What do you mean specifically by managed extensions? Are you talking about Microsoft managed extensions or are you just referring to a garbage collector?
Concerning the trend towards managed environments, there will always be room for non-managed languages like Heron as they will always outperform managed evnironments when used properly. I think the pendulum could very well switch back to non-managed environments as Heron catches on.
Christopher Diggins
http://www.heron-language.com
|
|
|
|
|
Why did you name the laungage as heron? you are breaking the rule, A,B then C , C++, C#, ???
just kidding..
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
look at Ruby, you will love it
mystifier
|
|
|
|
|
Actually, I already have 
It is a nice dynamic language, but it does not really compete with C++. I would like to use Ruby i.e. for web development - btw what is the state of mod-ruby?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Thanks for pointing this out!
I'd be curious to know:
How do you feel this compares to "D", and what, in your opinion, makes it better than "D"? I have always thought "D" was really cool, but this also looks really nice. My only beef would be the lack of function pointers, and it doesn't seem like there's any form of RTTI or reflective capabilities in Heron.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
|
|
|
|
|
I am not an expert in either of them. However, I dislike the D object model: "cosmic hierarchy" and mandatory GC are enough to turn me off. It seems that Heron is more faithful to C++ semantics than D. On the other hand, I wish it took even more syntax from Pascal.
As for reflection, I noticed it was an important concept in VCF, but having worked with C# in the last two years, I found it almost dangerous: too many times you get a run-time exception where a compiler error would have occured in a more static model.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote:
having worked with C# in the last two years, I found it almost dangerous: too many times you get a run-time exception where a compiler error would have occured in a more static model.
Well of course you do! By definition the query for reflection is run time based and (probably?) can't/won't be known at compile time. So you do have to use proper error handling, no doubt.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
|
|
|
|
|
Yesterday, I installed "full" version of VS 2005 Beta 1. Installation went smoothly, which surprised me a bit, because I heard some horror stories before. Anyway, since VC++ 2005 Beta is not in a state that would allow me to do anything serious with it, I started playing with C#.
First topic: generics, of course. Here is my "generic hello world":
namespace Generics
{
class MyArray<T>
{
public MyArray(int size)
{ data_ = new T[size]; }
public T this[int index]
{
get { return data_[index]; }
set { data_[index] = value; }
}
private T[] data_;
}
class Program
{
static void Main(string[] args)
{
MyArray<string> strArray = new MyArray<string>(10);
strArray[0] = "First";
strArray[1] = "Second";
}
}
}
Couple of things to notice at a first glance:
1. Angle brackets are used for type parameters like in C++, and unlike in D where ordinary brackets are used
2. Generics accept only type parameters - no nontype parameters and generics. I'll need to investigate the consequences of this further.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I looked again at the code I posted earlier (it does not compile with Beta 1):
System::IO::StreamReader file(L"test.txt");
String^ line = file.ReadLine();
Console::WriteLine(line);
Is this really what I want to do with C++/CLI? I don't think so. In practice, if I want to read a line from a file and write it to the console, I'll do something like this:
ifstream file ("test.txt");
if (file.is_open())
{
string line;
getline(file, line);
cout << line << endl;
}
Why do I need C++/CLI then at all? Well, the world is moving towards .NET and managed environments and I don't want to stay behind. On the other hand, I don't partculary like the .NET object model and BCL, and I want to use "classic" C++ whenever possible.
A solution is to develop my "core logic" code in standard C++, and then to expose it to the .NET world through an interface (or "Facade", if you prefer GoF terminology).
I see three ways to do that. One is to "flatten" my facade classes and expose them as a set of C functions, which can be called through PInvoke. Another would be to make COM wrappers. Finally, I can use Managed C++ or C++/CLI to easily write CLS compliant wrappers for my facade classes. COM wrappers is something I would rather avoid, which leaves me with C vs MC++ dilemma. The "C" approach appeals me because it enables other non - .NET languages to use the libraries. On the other hand, if I care only about .NET, with Managed C++ I can create classes that can be used from .NET languages directly, without PInvoke hassles.
The bottom line is: C++/CLI is about making C++ code available to .NET world, and if it is easy enough to do that, than I don't necesseraly care about deterministic finalization, STL.NET and other cool programming techniques. I'll just use ISO C++ for that.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
