[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dist-obj] Sourcesafe to CVS migration, C++ GC

Hi all,

Here are a couple of questions which I thought Smart People out there may be able to help with.

1. We've been using Sourcesafe as our code repository, but have just migrated over to CVS. This
was accomplished by tarring up the latest snapshot of all the sources in Sourcesafe, and creating a new CVS module
from them.
Unfortunately, this means that the full check-in history over the last 6 months or so of development in Sourcesafe have
been 'flattened'.
Is anyone aware of a simple way to re-express that Sourcesafe history in CVS? Maybe some script utilitty that knows
how to read Sourcesafe databases and create the equivalent CVS logs?

2. A while back, there was some discussion in which Joe K commented on the efforts for C++ GC:
>(b) the Boehm-Demers-Weiser is still the most popular free GC for C/C++.
>There are a couple of commercial alternatives as well these days; they seem
>to come and go over the years.  Finally, note that garbage collection is
>now "native" to gcc 3, so you have a built-in derivative to use as well.
>There are several GC FAQs and similar online that give you all the options.

I had a look at the C++ GC included in gcc - it's available at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
which also has a pile of interesting links on all sorts of subjects related to memory mgmt.

We are building a Windows client app in C++/COM, and are looking to use a fairly popular commercial tool
(Numega BoundsChecker -  http://www.compuware.com/products/numega/dps/vc/bounds.htm)
for development-time memory leak detection.

I've recently been debating with a colleague of mine the pros & cons of runtime GC vs. development -time
leak detection/correction.

There's an interesting essay on this subject at http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html

My bias, given my Java background and reluctance to working in C++, is for runtime GC. My colleague prefers
to do things in a more traditional C++ manner, considering memory leaks as bugs, not as an acceptable
design, handled by runtime housekeeping task.

For context, our application is not 'mission critical' in the sense of terrible loss in the event of a crash/restart,.
It's an ActiveX control which typically sits open for hours, possibly days at a time, hooked up to a real time market feed,
caching that feed, processing & displaying it. Memory leaks can (and do!) accumulate over time and hog up physical
RAM on the system, requiring periodic restarts to clear it out, which is highly undesirable but not cataclysmic.

The app has to keep up with a real-time feed, and do a fair bit of screen painting and user-response. Hence, there
is some legitimate concern about CPU overhead in a housekeeping GC. We optimize a fair bit on screen repainting
and double buffering, so runtime CPU is an issue. On the other hand, we're in a 'quick to market' and
'zero defect' development mindset, meaning we want high quality code quickly, which my instinct means GC to avoid the notorious
hidden, lurking C++ leaks that take forever to find and fix.

The debate isn't necessarily exclusively Boundschecker vs. GC. I suppose it's possible to merge both. Suggestions
from anyone with experience in this area would be of great interest.

Regards,
Ron



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

==========================================================================
To manage your subscription, mailto:dist-obj-help@distributedcoalition.org 
Archives, FAQ, etc.     http://www.distributedcoalition.org/mailing_lists/