Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Memory Checker Tools For C++?

kdawson posted more than 7 years ago | from the heaps-and-bounds dept.

Programming 398

An anonymous reader writes "These newfangled memory-managed languages like Java and C# leave an old C++ dev like me feeling like I am missing the love. Are there any good C++ tools out there that do really good memory validation and heap checking? I have used BoundsChecker but I was looking for something a little faster. For my problem I happen to need something that will work on Windows XP 64. It's a legacy app so I can't just use Boosts' uber nifty shared_ptr. Thanks for any ideas."

cancel ×

398 comments

Sorry! There are no comments related to the filter you selected.

um (5, Informative)

Anonymous Coward | more than 7 years ago | (#19408479)

boost::shared_ptr is not a memory checker, it's a reference-counted smart pointer, and works fine in legacy apps (such as compiled under VC++ 6).

Re:um (2, Informative)

RegularFry (137639) | more than 7 years ago | (#19408817)

It's an alternative to needing a memory checker, though, so it would provide an valid solution to the problem for a new application.

two points (3, Interesting)

sentientbrendan (316150) | more than 7 years ago | (#19408497)

This isn't really an answer to your question, but it's on topic and there's some questions I wanted to get answered myself.

First of all, shared_ptr is going into the standard library as part of TR1. Does anyone know when common development environments, i.e. GCC and MSVC, will start including TR1?

Second, I believe that there are a number of garbage collectors available as libraries for C++. I've heard boehm's garbage collector mentioned numerous times. My question is, are any of these libraries any good? Are they really practical to use in real world applications? Do you have to modify all of your types to use it, or can primitive and stl types work with it?

Re:two points (5, Informative)

Anonymous Coward | more than 7 years ago | (#19408509)

Boehm's garbage collector is used in Inkscape -- and they did gradually introduce its use, so you can start using it for some things and gradually extend the usage.

Boudewijn

Re:two points (0)

Anonymous Coward | more than 7 years ago | (#19408661)

Inkscape is hardly a good example of memory management in C(++).
Its memory use is vastly inefficient compared to Illustrator (for example).

Re:two points (0)

Anonymous Coward | more than 7 years ago | (#19408799)

Are there any attempts at porting boost or likewise libs to a functional version with continuation passing style? Later a runtime GC could use reference counts and make up for unwarranted memory allocation... the single assignment facade can be maintained to a decent extent.. Just curious. I have no idea but iterators can be implemented as a some form of list generators I guess. things are looking pretty convoluted however. I guess someone could be bored and do it just for the heck of it ...

Re:two points (4, Informative)

Anonymous Coward | more than 7 years ago | (#19408567)

gcc 4.2 includes a good part of tr1 as was released (late) a few weeks ago.

shared_ptr is a blessing and a curse. It saves you from manually destructing objects held in a collecton (good) but too many developers use it for lifetime management (bad).

I've used... (2, Funny)

grusin (1112113) | more than 7 years ago | (#19408503)

Some time ago i was using valgrind, but afaik it does not run under windows. I think that MS Dev has some memory leak detection built in, but it is far behind valgrind. Besides, who codes stable stuff for windows? :)

Re:I've used... (4, Informative)

TapeCutter (624760) | more than 7 years ago | (#19408805)

If you use MS compilers the memory debug stuff is in crtdbg.h, IIRC it has been there in one form or another since V1.5 but for some reason seems too obscure for the average Windows programmer to find. ;)

It is a very handy feature for finding leaks, buffer overflows, ect. The only other product I've used to find memory problems on recent incarnations of Windows is Purify. The MS solution is infinitely simpler because it's built into the environment and it's narrowly focused on memory problems. To state the obvious and in fairness to Purify, MSDev is infuriatingly fussy when it comes to building debug modules for IBM's Purify.

Fluid Studio's Memory Manager (MMGR) (5, Interesting)

Rezonant (775417) | more than 7 years ago | (#19408505)

Yep, Paul Nettle's little memory manager rocks. It WILL find leaks in your program. http://www.paulnettle.com/ [paulnettle.com] (Yes, you have to navigate through a horrible flash site to get it, but it's worth it).

Re:Fluid Studio's Memory Manager (MMGR) (1, Interesting)

Anonymous Coward | more than 7 years ago | (#19408705)

It seems to be single-thread only?

Re:Fluid Studio's Memory Manager (MMGR) (3, Informative)

Rezonant (775417) | more than 7 years ago | (#19408763)

It's true that MMGR is single thread only, and if your program allocates and frees memory on multiple threads you should choose another alternative. However, many many programs only allocate and free memory on one thread, and for those MMGR is simple to use and is pretty damn good at finding leaks, overruns and similar problems.

Re:Fluid Studio's Memory Manager (MMGR) (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19408959)

If you don't know what Cmd-Shift-1 and Cmd-Shift-2 are for, GTFO.
If you think Firefox is a decent Mac application, GTFO.
If you're still looking for the "maximize" button, GTFO.
If the name "Clarus" means nothing to you, GTFO.

Bandwagon jumpers are not welcome among real [imageshack.us] Mac [imageshack.us] users [imageshack.us] . Keep your filthy, beige [imageshack.us] PC fingers to yourself.

Duh! (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19408511)

Replace new/delete, malloc/free, whatever/whichever, with your own tracking version. In the end you may come out with an even better idea of memory handling for whatever you are working on at the time. God-awful simple you idiot !! You disgust me that you are so stupid !!

Cartman you big fat slob (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#19408633)

Cartman you big fat slob.

Re:Duh! (4, Funny)

WrongSizeGlass (838941) | more than 7 years ago | (#19408641)

Replace new/delete, malloc/free, whatever/whichever, with your own tracking version. In the end you may come out with an even better idea of memory handling for whatever you are working on at the time. God-awful simple you idiot !! You disgust me that you are so stupid !!
Just replace that post with your own comment system, such as replacing God-awful with I'm, idiot with smart, disgust with inspire and stupid with curious.

valgrind, libgc (2, Informative)

Anonymous Coward | more than 7 years ago | (#19408517)

Use valgrind. It's for Linux only, but what it does is invaluable for most of the tasks. I don't know of any other tool of such help.

Note this is not 'memory management tool', but one to help you find and clean up the memory leaks. There is no way to do proper garbage collection using the STL's allocators, though there is a 'gc' library http://www.hpl.hp.com/personal/Hans_Boehm/gc/ [hp.com] which tends to do the job. Haven't used it, though projects like Mono http://www.mono-project.org/ [mono-project.org] use it extensively.

Re:valgrind, libgc (0)

Anonymous Coward | more than 7 years ago | (#19408757)

Use valgrind. It's for Linux only, but what it does is invaluable for most of the tasks. I don't know of any other tool of such help.

And if the App is windows-only, you can even use wine with valgrind.

Note this is not 'memory management tool', but one to help you find and clean up the memory leaks. There is no way to do proper garbage collection using the STL's allocators, though there is a 'gc' library http://www.hpl.hp.com/personal/Hans_Boehm/gc/ [hp.com] which tends to do the job. Haven't used it, though projects like Mono http://www.mono-project.org/ [mono-project.org] use it extensively.

Boehm's GC is also used in gcj (GNU Compiler for Java).

Purify (2, Informative)

Anonymous Coward | more than 7 years ago | (#19408525)

Purify works quite well. It is big and slow, and doens't play nicely with ACE_Tao stuff sometimes (tao do cleaver things that scare s purify sometimes)

I must agree - Purify is it. (3, Informative)

Anonymous Coward | more than 7 years ago | (#19408835)

I used to select tools for my team. For UNIX, I selected Purify and for Windows, BoundsChecker. After a few days with BoundsSlacker, **all** and I mean every one of my team was asking for Purify for Windows licenses. 17 licenses later and our code crashes have dropped byat least 90%.

Yes, it isn't cheap. Just do it. You'll thank me.

The productivity increase alone will make it worthwhile for management.

Re:I must agree - Purify is it. (1)

CodeArtisan (795142) | more than 7 years ago | (#19409219)

used to select tools for my team. For UNIX, I selected Purify and for Windows, BoundsChecker. After a few days with BoundsSlacker, **all** and I mean every one of my team was asking for Purify for Windows licenses. 17 licenses later and our code crashes have dropped byat least 90%.
I have had my team use Purify too, with great success. A few years ago I also tried out Insure++ from Parasoft, which seemed to be of similar, if not slightly better, quality.

Re:Purify (1)

priyank_bolia (1024411) | more than 7 years ago | (#19408839)

I had tried GlowCode, it works with ACE_TAO, I guess and is very nice tool.

Re:Purify (2, Interesting)

0123456 (636235) | more than 7 years ago | (#19408965)

Yeah, I haven't used Purify in a few years, but when I tried it out it seemed very effective and found some bugs that would have been hard to track down otherwise. We didn't use it in the end because, at least at that time, it didn't like us dynamically generating machine code... otherwise it was better than anything else we tried; for normal C and C++ code it should work well.

Re:Purify (0)

Anonymous Coward | more than 7 years ago | (#19409105)

Mostly agree.

On HP/UX, we've had odd problems with purify making a signal() call return failure when it otherwise returned success, but otherwise it is definitely da bomb!

Can't think... (0)

Anonymous Coward | more than 7 years ago | (#19408531)

After seeing some of http://www.worsethanfailure.com/ [worsethanfailure.com] OMGWTF C Calculator Contest submissions today, I do believe you could get some fine examples of what you're looking..

*hides*

valgrind and gc.h (1, Informative)

Anonymous Coward | more than 7 years ago | (#19408535)

Use valgrind to find the bugs and Hans Boehm's GC to not have to fix them.

If you didn't already know of such tools then go do some research; what you want probably already exists.

STLPort (4, Informative)

kazade84 (1078337) | more than 7 years ago | (#19408541)

I know this isn't exactly what the article is looking for. But, if you are using the STL (which you SHOULD be!) you may be interested to know that the STLPort [stlport.org] STL implementation includes a debug mode which contains loads of error checking to make sure you aren't misusing STL.

Re:STLPort (1)

Chris_Jefferson (581445) | more than 7 years ago | (#19408671)

Everyone includes such a debug mode, including Visual C++ and g++. In my opinion both g++'s and visual C++'s are suprior to the one found in STLport. However, it won't really help you find memory leaks, only corruption from the standard containers.

Re:STLPort (1)

kazade84 (1078337) | more than 7 years ago | (#19408685)

I'm pretty sure VC++ and g++ don't do this [stlport.org]

Re:STLPort (4, Informative)

Chris_Jefferson (581445) | more than 7 years ago | (#19408863)

Actually, yes they do. In g++ use " -D_GLIBCXX_DEBUG ", in VC++ enable debugging. You'll get all these errors and more. I don't understand why everyone seems to know this part of stlport and don't realise other librarys have it as well.

Re:STLPort (1)

kazade84 (1078337) | more than 7 years ago | (#19408895)

Ahh, sorry my mistake. My information came from Scott Meyer's Effective STL. I guess STLPort just advertise it a little more than the others :)

Re:STLPort (1)

Chris_Jefferson (581445) | more than 7 years ago | (#19408981)

Thanks a lot! I bet that (very good) book is where everyone keeps getting this fact from. It's nice to know. It might have of course have been true when it came out that g++ and VC++ hadn't got such debug libraries yet, I'd trust Scott Meyer to check.

Most tools I've tried are useless (3, Insightful)

DrXym (126579) | more than 7 years ago | (#19408549)

I've played with Boundschecker, Purify (& Quantify) and Fortify. My experience of these tools is that they either take a painfully long time to run, throw up too many spurious warnings or crash outright after eating all available memory / disk space.

They might be useful for small apps but if you have a massive app they are almost more trouble than they are worth.

It's hard to say what you can do except foster safe coding practice and highlight the common pitfalls such as memory leaks, buffer overflows etc. Many compilers can help detect heap / memory overruns because the debug libs put guard bytes on the stack & heap that trigger exceptions when something bad happens. There are also 3rd party libs such as Boehm [hp.com] which help with memory leeak / garbage collection issues and dump stats. I'd say using STL & Boost is also a very good way of minimizing errors too simply because doing so avoids having to write your own implementations of arrays, strings etc. which are bound to be less stable.

Re:Most tools I've tried are useless (2, Interesting)

cerberusss (660701) | more than 7 years ago | (#19408663)

They might be useful for small apps but if you have a massive app they are almost more trouble than they are worth.
I'm of the opinion that the larger the application, the harder it is to write. So my philosophy is to chop programs up in different processes. The fact that you're stating that the memory checkers are only useful for small apps, might be a sign that your app is too big.

Re:Most tools I've tried are useless (1)

tepples (727027) | more than 7 years ago | (#19408967)

So my philosophy is to chop programs up in different processes.
I'd like to see details of how you would apply your approach. How would you propose that the program "Mozilla Firefox web browser" be chopped up into processes?

Re:Most tools I've tried are useless (1)

cerberusss (660701) | more than 7 years ago | (#19409121)

Hehheh you got me there, however I got from the parent that he was talking about a monolithic piece of business software. I.e. backend stuff. We're currently doing a project where we read measurement data from one or more instruments and functions are split up into processes. So we have one daemon for reading out one particular instrument, one process for the plotting backend, one for archiving data, et cetera.

Re:Most tools I've tried are useless (1)

andy_t_roo (912592) | more than 7 years ago | (#19409215)

- GUI stuff
- network communication stuff
- parsing (and running, if needed) stuff (xml/javascript/dhtml/...)

theres three relatively discrete components, which are (theoretically anyway) only connected via requests for data and replies - i'm sure that each of those could be broken down further (plausible independent subsets of 'GUI stuff' could include menus, action bars, the actual webpage)

Re:Most tools I've tried are useless (2, Insightful)

gladish (982899) | more than 7 years ago | (#19408707)

This is a result of the way that most people are developing code. They build some huge app and then finally realize that it doesn't work because it's riddled with defects and memory leaks. What should have been taking place is the creation of small units tests which were then run under some runtime analyzer like pruify. With that said, I've used purify, insure++, and valgrind. I found insure++ to be the best. I will admint that the code runs much more slowly but I was amazed at the stuff that it found. I've never used the windows version, but you can get it for windows with dev studio integration.

Re:Most tools I've tried are useless (1, Interesting)

ShakaUVM (157947) | more than 7 years ago | (#19408715)

>> foster safe coding practice

Agreed. Most skilled coders I know don't write code that has memory leaks. Even simple things like making sure your source code looks symetrical, matching allocations with deallocations (of whatever flavor), etc., is usually enough to avoid any problems with memory. It's easy (easy!) to write loops that never overflow, though you wouldn't know it with the amazing number of overflow exploits that have been found over the years.

However, it gets nasty when dealing with legacy code that is already leaking, or when you unfortunately get partnered with somebody that doesn't know how to practice safe coding techniques. In those cases, I guess these sorts of tools are useful.

Re:Most tools I've tried are useless (2, Insightful)

peterpi (585134) | more than 7 years ago | (#19409199)

I love this comment, from Bjarne Stroustrup's home page (href=http://www.research.att.com/~bs/bs_faq2.html #memory-leaks [att.com] )

Q) How do I deal with memory leaks?

A) By writing code that doesn't have any. (goes on to advocate vector & string)

And also: C++ Is my favorite garbage collected language because it generates so little garbage (http://www.research.att.com/~bs/bs_faq.html#reall y-say-that [att.com] )

Over the past 6 months or so, I've really made an effort to better my usage of C++ (using Effective C++, Effective STL and C++ Coding Standards). With a combination of STL, references, RAII, std::string and boost::shared_ptr, all of my memory, ownership & null-pointer problems just went away. I hardly ever actually write 'new' any more. The Java model of just leaking objects and hoping they'll get collected sooner or later seems horrible.

But I'm not maintaining old code, so this is completely -1 Offtopic.

Boost? Ugh (3, Interesting)

Viol8 (599362) | more than 7 years ago | (#19408559)

Talk about a sledgehammer to crack a nut. Boost strikes me as the sort of library used by people who want to show off how up to date their skills are , not people who really need to write a program to get a job done. Its bloated , has a wierd syntax that differs from the C++ norm and doesn't solve any problem that isn't already solved or could be done quite easily by standard C++ anyway. What is its point except as intellectual masturbation by its authors? No this isn't a Troll, this is a post by someone who was forced to use Boost for a year and I loath it. Yeah , mod me down , whatever...

Re:Boost? Ugh (5, Interesting)

pzs (857406) | more than 7 years ago | (#19408603)

I would be inclined to agree with this. I used the Boost Graph Library for some research code a few years ago. It's been designed to be extremely generic, which although a good thing sometimes makes it pretty difficult to just start coding something without all the bells and whistles. For operations on graphs, such as walking through, you can use their specialised functions for doing things but it takes days and days to work out how to use them and I ended up just using regular loops because they were much easier to understand.

Getting it to compile was a bit of a nightmare too. It has its own native compilation management tool that you have to download as well. What the hell is wrong with using make like everybody else? It also uses a very complex template hierarchy that produces terrifying error messages.

I'm sure that once you become an expert, BGL is really powerful and efficient, but I found the learning curve too steep. I just want to get in and build a working prototype quickly so I can see what I'm doing, not spend hours wading through manuals and examples to build the simplest program.

I'll be with the parent post and get modded a troll by boost developers.

Peter

Re:Boost? Ugh (2, Informative)

Cyberax (705495) | more than 7 years ago | (#19408901)

You don't usually need to build anything to use BGL - it's mostly header-only library. It has only two small helper files.

And Boost.Build is muuuuuch more powerful than makefiles. You can try to use Boost.Build v2 in your own projects - it's very very useful.

Re:Boost? Ugh (2, Informative)

rabidgnat (923944) | more than 7 years ago | (#19408997)

In 1.34, Boost made a Windows install tool that makes it much more easy to use. Just run the installer, put it in the directory you want, and change the Visual Studio settings to include $BOOST_ROOT. You could easily get going in 5 minutes

By the way, if you're not developing for Boost and aren't using one of 8 or 9 libraries, you don't *have* to run their build system. Just pointing Visual Studio or GCC to $BOOST_ROOT is all you need to do. It sounds like taking 5 minutes to read the "getting started" page would have saved you a lot of grief ;)

Re:Boost? Ugh (2, Informative)

dzorz (706431) | more than 7 years ago | (#19409023)

Boost is a collection of a lots of libraries and you can use only pieces that suite you. For example, shared_ptr has a very simple usage pattern and solves a problem that wasn't that easy to solve. It is already included in TR1. You really can't say that shared_ptr is bloated, too complicated or that it is a nightmare to compile - it only needs header files!
I would also recommend checking scoped_ptr, boost::random, boost::threads, boost::date_time and boost::filesystem. I use them all extensively in a single library that has to compile on gcc (Mac & Linux), MSVC80 and (!) Borland C++.
As for the complaints about the boost build system - bjam. I really have to disagree with you. You *don't* need to use it. Use it only to compile boost libraries, and then integrate them using whatever tool you want. I personally recommend cmake - it generates Xcode, MSVC, Borland projects or simple Makefiles among others... I use it to generate all of these.
Yes, it generates awful error messages, but, one could argue that STL and template metaprogramming in general generate awful error messages. It is something that is deemed to be fixed in new C++ standard.
I will agree with grandparent that some boost libraries are mental masturbation - boost::lambda comes to my mind :-) Some boost libraries rely on really ugly hacks (e.g. in boost::serialization - order of include files matters!!) and produce very bloated code, but you should judge it on a library per library basis.

Re:Boost? Ugh (2, Interesting)

MikeTheMan (944825) | more than 7 years ago | (#19409123)

I pretty much had the exact same experience. I tried to use the Boost Graph Library to create a visibility graph for a motion planning problem, and while it eventually did work, it was painful to get it working. At one point, I spent 3 hours (!!) trying to get the program to just compile. Errors were awful, kinda like STL errors but on steroids. In a standard-size terminal, each error took up about 8 lines.

And they weren't helpful errors, mind you. Due to some template magic, something had broken, and instead of telling me what really happened, Boost (at some point during compilation) replaced a template with an actual class called boost::error_property_map_not_found. What followed was a slew of errors saying that boost::error_property_map_not_found did not support the + operation, or the - operation, or...you get the idea.

The library seems plenty powerful. I think it would benefit from more examples, though. LOTS more examples.

Re:Boost? Ugh (1, Interesting)

Rakshasa Taisab (244699) | more than 7 years ago | (#19409151)

Erhmm... As I read the two parent comments, it's obvious you don't know _what_ boost really is.

It's not primarily meant for production use, rather it is a _testbed_ for future improvements to the C++ standard library. Pretty much a place where they intentionally test the bounds of the C++ language and check what kind of features would make sense in the standard.

Re:Boost? Ugh (1)

bms20 (827647) | more than 7 years ago | (#19408605)

Agreed - in part. I have had good results using the the threading library, and spirit, but particularly poor ones with their serialization library (I ended up re-implementing it). -bms20

Re:Boost? Ugh (1, Informative)

Anonymous Coward | more than 7 years ago | (#19408623)

That's a pretty harsh comment. Would you mind please giving some examples?

Personally, I find that

shared_ptr f (new Foo); ... // don't need to worry about when 'delete f' happens!

and also scoped_ptr are simple to use and very useful.

As with a lot of things there can sometimes be a tradeoff between the slope of the learning curve and the expressive power that you get as a result. Yes, there are more than a couple of Boost libraries that are over my head and where I write "standard" code instead. But Boost is not all-or-nothing - you should just use the bits that you like.

Re:Boost? Ugh (0)

Anonymous Coward | more than 7 years ago | (#19408869)

IMHO shared_ptr is an acknowledge that Java got it right (there is no need for objects, references, pointers and smart pointers, one is enough).

Yes, Java got it own problems ... a lot of them.

Re:Boost? Ugh (1)

maxwell demon (590494) | more than 7 years ago | (#19409131)

IMHO shared_ptr is an acknowledge that Java got it right (there is no need for objects, references, pointers and smart pointers, one is enough).

I disagree. Java doesn't have shared_ptr. Java has GC. If anything, shared_ptr is an acknowledge that raw pointers (as inherited from the low-level C language) are simply not the ideal tool for high level programming. Which doesn't say anything about if Java got it right, or if it got it wrong in just another way that C. Note that shared_ptr is not the only smart pointer, which is more of a hint that "one size fits all" doesn't really work (which again can be seen as an argument against the Java model).

Re:Boost? Ugh (2, Insightful)

kazade84 (1078337) | more than 7 years ago | (#19408659)

If you wanna "get the job done" then boost is sometimes exactly what you need. I'm not saying that you should memorize the whole library but sometimes a boost library is available for what you want to do. I couldn't live without boost::lexical_cast, boost::shared_ptr, boost::tokenizer and boost::python is genius. You *could* write all of those things yourself but honestly, why?

If you wanna code in C++ then you'd better get used to the "weird syntax" of templates and especially the boost libraries, they ARE the basis of most of the additions to the standard library in TR1 so they will become the "C++ norm"

Re:Boost? Ugh (4, Insightful)

Viol8 (599362) | more than 7 years ago | (#19408693)

"you'd better get used to the "weird syntax" of templates and especially the boost libraries"

I'm used to templates syntax (though I think its ugly and Stroustrup could have done a lot better) but Boost makes it worse by overloading operators and then using them in ways never intended that produce syntax that a plain C++ wouldn't even recognise, never mind understand what its doing.eg the gratiutous overload of () for matrix ops where a simple function call would have been much cleaner and easier to follow.

Re:Boost? Ugh (0, Insightful)

Anonymous Coward | more than 7 years ago | (#19408761)

Overloading operators is exactly the norm in standard C++ it is one of the most ingrained principles
with which C++ was designed. Creating DSEL (Domain Specific Embedded Languages) like boost::spirit (where you basically write EBNF syntax in C++ to generate parsers) was and is a key goal when C++ was developed.

So you now don't know what an operator like does? So what, it does the what it is supposed to do in this context.
This helps to really rise the abstraction level of the language to solve problems of the problem domain, in a very efficient way.

Re:Boost? Ugh (1)

Viol8 (599362) | more than 7 years ago | (#19408923)

"was and is a key goal when C++ was developed."

Oh really? Well thats the first time I've heard of it. Provide a link.

"So you now don't know what an operator like does? So what, it does the what it is supposed to do in this context."

Well thats helpful when you're a maintenance programmer faced with 10,000 lines of code that could be doing anything and you have no idea what because the guy who wrote it thought it would be cool to overload every operator he could think off and to hell with readability and comprehension 2 years down the line.

"This helps to really rise the abstraction level of the language to solve problems of the problem domain, in a very efficient way."

Bullshit. Its no more efficient than function calling , its just a way for coders show off.

Re:Boost? Ugh (1)

ardor (673957) | more than 7 years ago | (#19408969)

BS again. Overloading a + operator is just "showing off"? I suppose you like adding vector components manually, instead of doing v1 + v2? How about bigint classes, operator overloading is a bless there. Correct use of templates can significantly reduce the amount of written code and clarify it, as shown in the earlier vector example.

Re:Boost? Ugh (-1, Flamebait)

Viol8 (599362) | more than 7 years ago | (#19409017)

"I suppose you like adding vector components manually, instead of doing v1 + v2?"

No , something like vectorAdd(v1,v2) would be a lot more readable and a damn site easier to grep for. Idiot.

Re:Boost? Ugh (1)

ardor (673957) | more than 7 years ago | (#19409127)

If v1 + v2 is not readable for you, I suggest you learn some math.
The grep argument is valid, though I use egrep and a regexp in this case.
Also, I suspect you also hate extremely hard to read associative container access like table["entry"] = value; right?

Re:Boost? Ugh (0)

Anonymous Coward | more than 7 years ago | (#19409221)

If v1 + v2 is not readable for you, I suggest you learn some math.
I think I speak for many programmers when I say that math is a lot more readible if you spell out what you're doing. Of course, in this instance, we all know that you mean simple vector addition. But in the context of C++ programming, this isn't clear at all. Having a full function name (and real variable names instead of v1 and v2) would make it much more clear what is actually going on.

Re:Boost? Ugh (1)

Big Smirk (692056) | more than 7 years ago | (#19408731)

Yes,

I have found that most of what I get out of boost is a foot print for the way the class should be written and then I end up re-writting the class.

For example, shared_ptr is not thread safe. You may say, "so what?" but unless I'm writting a massive program using IOcompletion or select, I pretty much no when something is allocated and when it is no longer needed. shared_ptr does nothing. But, if multithreaded, when thing finish up in orders that I cannot (or don't want to) predict, shared ptr would be ideal.

template <class T, LockMechanism L, Allocator A>

class shared_ptr {.... After all, boost has threads now right? right?

Re:Boost? Ugh (2, Informative)

oergiR (992541) | more than 7 years ago | (#19408765)

You are misinformed. You probably don't have any experience with Boost, nor do you get your facts right. Boost consists of different parts, and for using boost::shared_ptr you need only a couple of headers. There is even a tool that extracts the necessary bits for you [boost.org] .

Its bloated , has a wierd syntax that differs from the C++ norm and doesn't solve any problem that isn't already solved or could be done quite easily by standard C++ anyway.
boost::shared_ptr has been in standard library implementations for a couple of years now as std::tr1::shared_ptr. It will most likely be included in the next C++ standard [wikipedia.org] . Apparently the C++ standard committee did think that shared_ptr solves problems that the old C++ standard does not.

Re:Boost? Ugh (1)

Viol8 (599362) | more than 7 years ago | (#19408931)

"Apparently the C++ standard committee"

Ah yes , the C++ commitee. The people who turned C++ from a learn OO version of C into the bloated mess we have today. Sorry , but they're hardly a name to drop in an argument to bolster your case.

Re:Boost? Ugh (1)

ardor (673957) | more than 7 years ago | (#19408961)

Correction: the people who gave C++ templates, which are a killer feature. Thanks to templates, I can do generic programming and metaprogramming in C++, which are orders of magnitude more powerful than OO only.

No, Java generics are not the same.

Re:Boost? Ugh (0)

Viol8 (599362) | more than 7 years ago | (#19409043)

"which are orders of magnitude more powerful than OO only."

In what way powerful? They save a few lines of code. Period. At the expense of readability in most cases. If you really believe templates increase the problem solving domain of the language then you obviously have little experience of real programming.

Re:Boost? Ugh (1)

ardor (673957) | more than 7 years ago | (#19409113)

Simple. Generic programming allows N+M work, whereas pure OO forces N*M. N being the number of algorithms, M the types. Translating to real code, the advantages of a generic vector container like the STL vector should be obvious, unless you feel inclined towards writing such a container for every type. This is true because generic programming identifies the properties of an object directly (for example, a + operator), and plain OO identifies types (thus ensuring that an object has certain properties).

Template metaprogramming also allows policy-based design, which essentially introduces permutations. Context vs. Context for instance. This way, you can optionally add thread safety at compile-time. Impossible with pure OO, and very big timesaver. How about iterators? Impossible in OO at compile-time and without downcasts (thats what Java does). Generic find algorithm? MVC signals? (These are extremely handy for GUI toolkits) Or how about stuff like boost::bind?

Without templates, C++ loses its real advantage.

Re:Boost? Ugh (1)

ardor (673957) | more than 7 years ago | (#19409145)

Context vs. Context
should be Context < SingleThreaded > vs. Context < MultiThreaded >

Re:Boost? Ugh (1)

Pretor (2506) | more than 7 years ago | (#19408773)

You must be kidding. Have you actually tried to use boost for more than a second? You only have to use the parts of boost that you need. It's not that you have to link or include every boost library for you application. I've been using boost professionally for several years. And it really makes coding in C++ a lot nicer. Please note that you need a modern compiler like G++ > 3 or Visual C++ 2005. Otherwise you'll have to play with the compatible syntax which is horrible.

Here are some of the parts that we use:

  • boost::smart_ptr
    This is probably the entry for a lot of the Boost users. Simple smart pointers that does the work most of the time. Create a RAII helper class or use LOKI Smart pointers if you have special cases that you cannot solve with boost::smart_ptr.

  • boost::python
    Easy to use and extend if you want to package you c++ library as a Python package. It does require a fair amount of CPU and Memory. But if you have an old/underpowered computer as a professional developer you ask your boss for a better computer or get a new job. In my personal opinion it's much nicer that SWIG and you get the added benefit of using the C++ compiler instead of a special pre-processor.

  • boost::signals
    Easy to implement the observer and the mvc patterns.

  • boost::bind and boost::function
    Handles a lot more cases than the standard template library binders and adapters (bind2nd, bin2st, mem_fun, ptr_fun and etc).

  • boost::threads
    Cross platform threading. We are using both Linux and Windows.


As a side note I do prefer libsigc++ to the boost::signal and boost::bind. But this is an additional dependency that we don't bother with when we're already using boost.

Re:Boost? Ugh (0, Flamebait)

Viol8 (599362) | more than 7 years ago | (#19409003)

Do you actually write real programs or do you just play around with coding paradigms all day? You seem to like name dropping - RAil , LOKI, SWIG (whatever the hell that is) ,binders, adapters, observer , mvc patterns (oooh , patterns , theres a word no-nothings drool over) but can you actually code? Could you sit down and write for example a network server to do real time trading and failover without being surrounded by a mountain of books to give you all the latest buzzwords & TLAs to impress your boss with and blocks of code you don't really understand and you couldn't write yourself to use as lego bricks to build your slow, bloated app? I doubt it somehow.

Sorry , but I get tired of people of your ilk. Perhaps I'm too old for coding , but when all it consists of is buzzword of the month and seeing the bloatware that gets dished up these days as "code" I do wonder about the general level of ability in the IT industry. It seems its gone the way of politics - all image , spin and buzzwords but little ability to get any decent work done.

Re:Boost? Ugh (1)

ardor (673957) | more than 7 years ago | (#19409013)

MVC and RAII are basics, not "fancy new toys". It is likely that you already know them, just not by this name. Happens to me often, too, I implement design patterns and don't know that this is actually pattern XYZ.

Re:Boost? Ugh (1)

JonasG (629786) | more than 7 years ago | (#19408783)

Some parts are very useful. Smart pointers, bind, filesystem (we would have used the Windows API in my current project if I hadn't found it) and also string, which contains lots of things missing from C++'s standard string functions (like a split function). I find the mentioned parts of Boost to be quite easy to use too.

During the project I'm currently working on we would also use a graph. I checked out Boost's graph library and we chose not use it but implement our own graph. I now partly regret this, however I'm not sure Boost's graph would have been easy enough to use.

You are looking for PageHeap (4, Informative)

Photo_Nut (676334) | more than 7 years ago | (#19408581)

PageHeap is a debugging tool for Windows created by Microsoft. It does what you want.

For more information look here:
http://support.microsoft.com/kb/286470 [microsoft.com]

Valgrind (5, Informative)

bms20 (827647) | more than 7 years ago | (#19408593)

Use valgrind : www.valgrind.org It is (in my opinion) the best tool available for this purpose. In fact, I develop C++ exclusively on linux first because of valgrind, then port to Win32 later. By the way, you're not missing out on anything special by not programming in Java or C#. Both of those languages are slow, and introduce their own language complexities. -bms20

Re:Valgrind (0)

Anonymous Coward | more than 7 years ago | (#19408695)

It's not accurate to say that Java/ C# are slow. If you really need to optimise, then maybe C/ C++ will do the trick. However current VM implementations are very sufficient for 90% of the application needs.

Re:Valgrind (3, Informative)

HRogge (973545) | more than 7 years ago | (#19408723)

If you still think Java/C# are slow, especially in terms of memory management you might want to read this:
http://www.ibm.com/developerworks/java/library/j-j tp09275.html [ibm.com]

Re:Valgrind (1)

bms20 (827647) | more than 7 years ago | (#19408819)

Thanks for the article reference. Unfortunately, I don't buy the argument at all.

If they re-implemented perl in java and could decisively show that "most perl benchmarks are faster in jperl than perl" then I would be interested. Until that day C/C++ will remain a faster language.

Remember, in C++ one can always implement a custom (read dynamic) allocator, specifically for the job. Or better yet, the code paths could likely be optimized to reduce the number of calls to malloc/free, reducing the overall complexity greatly.

-bms20

Re:Valgrind (3, Interesting)

HRogge (973545) | more than 7 years ago | (#19408865)

Another link you might like to read (just done some search on google):
http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html [idiom.com]

Of course you can create your own "dynamic" allocator in C++... but that doesn't make allocation/deallocation automatically faster.

Maybe you should search for some numbers to support your argument... just by stating "I don't buy it, C++ is still faster" it doesn't become reality.

All the world is not a PC (1)

tepples (727027) | more than 7 years ago | (#19409053)

How fast does Java run on a handheld device with a 67 MHz CPU and 4 MB of RAM? Over forty million of these devices have already been deployed.

Re:All the world is not a PC (1)

HRogge (973545) | more than 7 years ago | (#19409099)

1.) cpu speed is a red red herring [fallacyfiles.org] . Of course both C++ and java will be x times faster/slower on a machine with an x times faster/slower processor (if anything else stays the same).

2.) just look up the phrase "j2me" for java runtimes designed for embedded devices.

Netcraft confirms: Java is slow (1)

zBoD (86938) | more than 7 years ago | (#19408847)

... not

Re:Valgrind (2, Interesting)

DrXym (126579) | more than 7 years ago | (#19408937)

By the way, you're not missing out on anything special by not programming in Java or C#. Both of those languages are slow, and introduce their own language complexities. -bms20

Speed isn't everything. If your server application is network or database bound then stability and API richness is considerably more important than speed of execution. After all, does it matter that your app completes 2ms faster if it has to wait 500ms for the database to return? Or that it crashes more frequently? Or that you can't port it to new hardware because half the libs you use don't compile? Since Java offers dozens of cross-platform APIs (network communication, web services, XML parsing, crypto, database, RMI etc. ) and runs (without recompiling) on dozens of platforms AND is generally harder to bring down than C++ I would favour where speed and UI are not factors.

Even where a UI is present, Java has it's uses. Eclipse demonstrates that Java can produce excellent cross-platform desktop applications. I think Java's weakness is definitely its UI though. While Swing is a very rich API, it's also hard to write native look and feel apps. The file picker dialog is one place where Java apps always suck. Poor look & feel is probably why Eclipse chose to use SWT instead.

C# (.NET) obviously doesn't benefit from robust cross-platform support but it does inherit most of the same advantages of Java. It also has excellent UI support (and better layout tools) on Windows meaning that you can accomplish quite a lot in C# without dropping to C++.

Re:Valgrind (1)

bms20 (827647) | more than 7 years ago | (#19409069)

You have a good point about the supplied standard libraries.

Much of application development comes down to choosing the correct tool for the job these days.

I have done a hell of a lot of work in Python using Twisted these days, as it is the correct tool for the job that I am doing. C++ would have increased the amount of time required to implement the job by a large margin.

-bms20

Re:Valgrind (1)

oever (233119) | more than 7 years ago | (#19409177)

I think Java's weakness is definitely its UI though.
Which is where Jambi [trolltech.com] comes in.

A second vote for Valgrind (3, Insightful)

RatCommander (212548) | more than 7 years ago | (#19409015)

Valgrind's default memcheck tool is an excellent way of finding memory errors - ranging from extremely subtle to obvious. In addition, Valgrind can be used as a code profiler, cache simulator and many other things. It really is an excellent tool - I recommend it to anybody writing C++.

And a third one (1)

Lisandro (799651) | more than 7 years ago | (#19409093)

Valgrind is, by far, one of the most useful tools i've ever came across for C/C++ developing. It's a shame it runs only on Linux - i bet a lot of Windows software would be much less leak-proof if such an excellent (and free) tool were available for them.

Re:Valgrind (2, Informative)

Idaho (12907) | more than 7 years ago | (#19409167)

Use valgrind : www.valgrind.org It is (in my opinion) the best tool available for this purpose. In fact, I develop C++ exclusively on linux first because of valgrind, then port to Win32 later.


It's been a few years since I last programmed in C++, but Valgrind indeed really saved the day on a regular basis. Also look into (KDE-)frontends if you think looking at text output is not very convenient. Couldn't agree more with this part, it's the best tool I've seen - and it's free software, too.

By the way, you're not missing out on anything special by not programming in Java or C#. Both of those languages are slow, and introduce their own language complexities. -bms20


Afraid I have to disagree here though. First of all, a language is not the thing that's "slow" or "fast". It may be the case that no very efficient compilers or virtual machines exist (for a particular language). I will admit that it is hard(er) to create efficient implementations of some languages (functional languages, logic-based languages), but C# and Java are definitely not among those. Second, Java VM's used to be slow in 1997. It's 2007 now, I'd suggest you try again (and be surprised). Third, I definitely do not agree that "you're not missing out on anything special" by using C++ instead of any garbage collected language (not necessarily Java or C#). For one, you're (do I need to state the obvious here?) missing out on garbage collection! I would say garbage collection is a clear advantage in the vast majority of programming scenario's. I would even argue that it's the biggest practical advancement in programming since the introduction of the procedural paradigm - perhaps even more important than object orientation.

Last of all, you're complaining about "language complexities" in Java/C# and (thereby) suggesting C++ is better in this regard? Hmm, I guess my sarcasm detector must be broken or something :D

Windows Resource Kit (0)

Anonymous Coward | more than 7 years ago | (#19408601)

I am not sure about its availability for Windows XP, but I have used the Windows Server 2003 Resource Kit tools to successfully locate memory leaks in Windows dlls. First, you have to link with /DEBUG to get any meaningful results. Then run memtriage on the pid to get the heap address range and size allocation of all dlls attached to the given process, then use dh (dump heap) to determine which of the address ranges is for your resource.

If you see growth in successive executions of memtriage (which can be set to sample the heap over any defined time interval and for any number of iterations and all heap data is written to a log file) then analysis of corresponding executions of dh will tell you where memory is being allocated and not being freed.

eFence (4, Interesting)

cannonfodda (557893) | more than 7 years ago | (#19408613)

I haven't used it for a while, but I used to use Bruce Peren's efence [perens.com] for bits of malloc debugging, it hasn't been actively developed for ages but it's pretty light weight if that's what you need. There appears to be an up to date branch DUMA [sourceforge.net] which I haven't tried. As far as I remember you can use efence under WIN and DUMA claims to work......

Unfortunately, what you prolly want is valgrind or purify.

Re:eFence (1)

jcupitt65 (68879) | more than 7 years ago | (#19409119)

Programs run quickly under efence, but sadly memory use will balloon. It (I hope I have this right) puts each malloc into a separate page with guards either end. So every tiny strdup() will use some huge amount of your address space. It's not practical for anything bigger than rather small.

valgrind takes the opposite approach: it does all the checking in software, so it runs slowly (about 1/20th of real speed, the last time I measured it), but is much more modest in the amount of RAM it needs (though it still needs a lot).

This is one area where every developer really needs 64-bit processor. I have 8GB in my desktop machine now and I can run even the largest project I work on with full memory checks. It's wonderful.

Purify is what you need (1, Insightful)

Anonymous Coward | more than 7 years ago | (#19408713)

Purify has been considered the best solution for this problem for many years. (How many readers have their 'Purify Mug'?)

Linux developers can use Valgrind, which is also very good and is free. But it won't run on your platform.

Then there are the static checking tools like Coverity. I believe that they do great things, though I have never used them. If you are a big company I think it would be well worth getting them to talk to you; you would probably find it intellectually interesting, if nothing else. There are other tools in the same field; Wikipedia has a list.

You may find that Purify is too slow. It has various options that you can tweak. It also benefits from having loads of RAM (steal it from your colleagues while they have lunch). But basically you need to live with the speed and either be patient or hack your application to go straight to the problematic bit.

In my experience this sort of debugging is always painful, and the lesson it teaches us is to *not put the f***ing bugs in the code in the first place!* By that I mean:

- Avoid dynamic memory allocation when possible (i.e. use std containers instead).
- Every time you type 'new' or 'malloc', think to yourself "where does this get deleted/freed?"; ideally the call to delete or free should be a few lines away from the call to new or malloc and it should be blindingly obvious that they occur in pairs.
- Be really clear about ownership of pointers.
- Use smart pointers (like the Boost scoped_ptr and shared_ptr) when appropriate.
- Avoid pointer arithmetic.
- Don't use a NULL sentinel value.

Every time you find yourself doing one of these "bad" things, try to remember your last epic all-night debug session with Purify and fix it....

By following these sorts of practices, I have managed to avoid any nasty memory-allocated related bugs for a few years. But of course it doesn't help with your legacy codebase.

Re:Purify is what you need (1)

ardor (673957) | more than 7 years ago | (#19408927)

You forgot one important thing: RAII.

Stuff the mem allocation in the constructor, or at least set the pointer to zero there. Call delete in the destructor. This avoids memleaks and is exception-safe.

Re:Purify is what you need (1)

HRogge (973545) | more than 7 years ago | (#19409021)

You will just get a "chicken-egg" problem with this argument, because it transform the problem "who deallocate my resource" to "who deallocate my class".

RAII helps to reduce the complexity of resource allocation because you can group them, but it doesn't solve the basic problem.

Re:Purify is what you need (1)

ardor (673957) | more than 7 years ago | (#19409155)

Ideally, dynamic allocation should be encapsulated in classes which are guaranteed to be deallocated, either by simply being stack objects, or by a delete call that always - really always gets called.

Then, RAII does work.

Visual Leak Detector (3, Interesting)

Tucano (1112131) | more than 7 years ago | (#19408721)

I have tried mainly Boundschecker and Purify, and they were usually quite slow and difficult to set up and produced lots of spurious results. Also, quite often they simply didn't work at all and refused to run certain programs. A few years ago I reduced the problem to a 10 line C++ program that would crash Boundschecker or Purify, can't remember anymore which one it was.

In any case, Visual Leak Detector is a free memory checking tool. It's only for Windows / Visual Studio, but if you are using that, VLD is awesome: http://www.codeproject.com/tools/visualleakdetecto r.asp [codeproject.com]

It's super easy to set up, just #include "vld.h" somewhere in your program, and then run the debug mode. No need to rebuild everything in instrumented mode, and no false results (at least I haven't got any). Real memory leaks will be reported in the output window of the IDE.

valgrind (1)

sashang (608223) | more than 7 years ago | (#19408735)

valgrind...oh but you're using windows.

Roll Your Own (1)

bsmoor01 (150458) | more than 7 years ago | (#19408741)

I write C++ for embedded systems, and I needed a decent heap checker, so I rolled my own. It only took a few hours to write.

Of course, I basically copied the mechanism of tools like efence or DUMA, but I was able to tweak the tool to do exactly what I needed it to do. You may want to try the same approach.

-Seth

Python memory checker? (0)

Anonymous Coward | more than 7 years ago | (#19408871)

Does anyone know of any good memory checkers that can understand python's weird ass memory manager from back in '92.

Glowcode! (1)

Soulshift (1044432) | more than 7 years ago | (#19408883)

Glowcode is a memory allocation watchdog and code profiler rolled into one. IMO, it has the best implemented features [glowcode.com] of its class, and is speedy and lightweight to boot. On top of that, it's useful for checking run-time memory leakage that may be masked by the deallocations that happen at the end of your program. I use it to find those odd leaks that only happen when you do a specific action, for example. A very useful tool.

Detailed article on memory usage (3, Informative)

Tronster (25566) | more than 7 years ago | (#19409149)

Last week on Gamasutra was a good article on memory leak detection, and how to role your own tool:

"Monitoring Your PC's Memory Usage For Game Development" [gamasutra.com]

While the title says it's for game development, I found that the meat of the article applies to any windows developer.

Purify (1)

supersnail (106701) | more than 7 years ago | (#19409179)

Expensive little toy from Rational.

It profiles memory allocation on existing executables.

Produces thousands of lines of output, most of which you can ignore after revewing the code, but it does catch almost everything.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>