tag:blogger.com,1999:blog-6322478114067402666.post3207471648464862442..comments2016-12-11T14:08:51.363-07:00Comments on Code by Dave: Memory Leak Detection with Visual Studio 2008Anonymoushttp://www.blogger.com/profile/11557154250788184716noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-6322478114067402666.post-23497015568210615762016-12-11T07:57:17.172-07:002016-12-11T07:57:17.172-07:00This comment has been removed by a blog administrator.Anonymoushttps://www.blogger.com/profile/15700032899978400956noreply@blogger.comtag:blogger.com,1999:blog-6322478114067402666.post-64243168052462200632014-04-04T20:44:03.642-07:002014-04-04T20:44:03.642-07:00The one and only company that can resolve your pro...The one and only company that can resolve your problem in no time is Absolute Maintenance and Consulting. They are experts in terms of <a href="http://www.lamoldexperts.com/leak-detection.php" rel="nofollow">Leak detection los angeles</a>les. They have the most updated technological devices to determine the leaks that might be lurking in the corners, ready to make havoc in your home. Their thermal scan will do X-ray and will find the accurate place where the leak started. They have highly trained technicians to fix any intrusion or water leak because they can waterproof your home to ensure your family's safety. After a hard day's work at the office, you can go home and relax knowing that AMC has solved the problem.Anonymoushttps://www.blogger.com/profile/09279447815252141648noreply@blogger.comtag:blogger.com,1999:blog-6322478114067402666.post-6775218748770263362007-12-07T08:36:00.000-07:002007-12-07T08:36:00.000-07:00That's lame that they won't be available for Expre...That's lame that they won't be available for Express Edition, but what are you going to do about it.<BR/><BR/>I had also assumed that TR1 had already been standardized, so it definitely makes sense to put it in std::tr1 since it's still open to changes.<BR/><BR/>I just checked out the shared_ptr code and it's just like you said. It's actually a pretty smooth idea, but I'm still hesitant to believe that it was the best solution. I guess from a general library type of perspective it's a good option, but it just feels a little too Java-ish to me (sacrificing memory and CPU time in all cases just to make a specific use case a little simpler). I guess the problem is that I just can't get over the fact that you could get the source compatibility using a typedef. Yes, you would lose binary compatibility that way and I guess not having to recompile client code was really important to them for some reason. But like I said before, you're never going to make everyone happy.Anonymoushttps://www.blogger.com/profile/11557154250788184716noreply@blogger.comtag:blogger.com,1999:blog-6322478114067402666.post-34709285929487452982007-12-06T15:27:00.000-07:002007-12-06T15:27:00.000-07:00Yeah, hopefully Microsoft's TR1 support will be go...Yeah, hopefully Microsoft's TR1 support will be good when it is finally released in VC++ 2008 Pro+ next year. I'm mostly worried about when they are going to make it available in the Express edition, which won't be until much later.<BR/><BR/>I think the reason it's going into std::tr1:: instead of std:: is that Microsoft is releasing it before it officially gets standardized. My understanding is that everything will go into std:: once the C++0x is finally completed. I'm pretty gcc also puts their advance versions of TR1 stuff into std::tr1:: as well.<BR/><BR/>I've looked through the shared_ptr code, and it's actually not crazy at all. It's just done via a virtual dispose method on a non-template base class which is overriden in a template subclass for the given pointer and deleter types. It's pretty elegant, although there's basically two additional objects created on the heap for every object being pointed to by a shared_ptr (the reference count and the deleter wrapper) which I'm not crazy about. But, I don't think there's really any other way to accomplish this and I think the benefits outweigh the drawbacks.Bradhttps://www.blogger.com/profile/05704377356630619601noreply@blogger.comtag:blogger.com,1999:blog-6322478114067402666.post-19950000277732551482007-12-06T07:32:00.000-07:002007-12-06T07:32:00.000-07:00I definitely agree that the fact that it's in TR1 ...I definitely agree that the fact that it's in TR1 is pretty sweet, and I'm really glad that Microsoft seems to be doing such a good job of supporting it. But my biggest questions is why is the namespace "std::tr1::"? What's wrong with just putting it in "std::"? I'm sure that was a fairly highly debated topic and no matter what they picked someone was gonna be pissed.<BR/><BR/>I'll have to check out that bcp extraction tool, because that would make using boost in small projects SO much easier.<BR/><BR/>I think that there's a part of me that doesn't like the boost::shared_ptr because I don't understand how they pulled off the custom deleter. So I'm definitely gonna have to take some time and look through that code to see how they did that, because that's some coding magic that I haven't seen yet.Anonymoushttps://www.blogger.com/profile/11557154250788184716noreply@blogger.comtag:blogger.com,1999:blog-6322478114067402666.post-26939203189492327992007-12-05T19:14:00.000-07:002007-12-05T19:14:00.000-07:00Yeah, it took me a long time to start using boost ...Yeah, it took me a long time to start using boost because I didn't want a huge dependency in my code. The thing that changed my mind was the fact that boost::shared_ptr, boost::weak_ptr, and boost::enable_shared_from_this are all in TR1 for the next C++ standard (although of course they will all be in std::, not boost::). I figured I could either hack my own smart pointers, or I could go with something that is mature, tested, and standard (or which will soon be standard).<BR/><BR/>I have yet to use any other part of boost, mainly because I want to stick with stuff that is being standardized. Also, I discovered the bcp utility which allows you to extract only the parts of boost that you need. In the case of boost::shared_ptr and friends, bcp extracts only the few necessary header files which you can start using immediately without any compilation (there are no implementation files, just headers, for the smart pointer stuff).<BR/><BR/>There are a few other deal sealing features that have made me a convert to shared_ptr. One of them is the fact that the reference counting is done with atomic operations, so it is entirely safe to use shared_ptrs in multi-threaded applications without needing to worry about synchronizing the pointers themselves (of course you still need to synchronize operations to the pointed object if necessary).<BR/><BR/>Lastly, I do understand their reasoning behind not making the deleter a template parameter, even though it can be an inconvenience sometimes. It allows other code to be ignorant of the deleter, which really is the way it should be. Code that uses the smart pointer shouldn't need to be aware of the deallocation stuff.Bradhttps://www.blogger.com/profile/05704377356630619601noreply@blogger.comtag:blogger.com,1999:blog-6322478114067402666.post-20119784643219616612007-12-05T14:07:00.000-07:002007-12-05T14:07:00.000-07:00I've been thinking about creating a Google Code pr...I've been thinking about creating a Google Code project or something to store all of the code, but I've just been waiting until I go and actually clean everything up to the point that I'm not ashamed of it. So I'll let you know when I finally do something like that, because I'd love to get some feedback on it and it would be even cooler if it actually became something useful to someone other than me.<BR/><BR/>Ya, I read through a lot of the comments they wrote about their shared pointer and I just don't buy into a lot of the reasoning they use. I hope that it's just that I'm being a little too narrow minded and they're really creating a wonderful and broadly applicable library, but sometimes I wonder.<BR/><BR/>Also, the big reason that I steered away from using the boost shared_ptr is because Boost is a monstrosity. You can't just grab a single header or two and use them in a program, and it's usually not worth including some enormous amount of code when you just need one tiny piece of the provided functionality. Plus, above all, I wanted to maintain the whole SQLite idea of small, simple, and self-contained, so someone could drop this wrapper in and start using it immediately just like with SQLite.Anonymoushttps://www.blogger.com/profile/11557154250788184716noreply@blogger.comtag:blogger.com,1999:blog-6322478114067402666.post-2600416423408728482007-12-05T10:11:00.000-07:002007-12-05T10:11:00.000-07:00Hey, when you're done with your SQLite wrapper, I'...Hey, when you're done with your SQLite wrapper, I'd be interested in seeing it! I've got one of my own, but it might be fun to compare or even collaborate.<BR/><BR/>It is rather inconvenient that the custom deleter for boost::shared_ptr has to be passed in the constructor, although I realize why they designed it that way (there's a blurb on the documentation page about the benefits of the design, such as source and binary compatibility independent of the deleter used).Bradhttps://www.blogger.com/profile/05704377356630619601noreply@blogger.com