• Category Archives Technology
  • Technology and Software Development

  • virtual methods in Constructors == Havok

    Recently I wrapped up a Test Driven Development course for some co-workers in Beaverton, Oregon which went quite well (some good enthusiasm from the folks there). As always every time I teach or rather ‘share’ something with people I end up learning something new (such as Mock Object frameworks). This time I wanted to point out a very interesting deviation between programming languages in reference to virtual methods being called in constructors (and depending on your language destructor’s too).

    In our environment here in Kelowna, BC we use Borland Developer Studio 2006 (C++), as well as Visual Studio 2003 (C#). In the past a colleague and myself worked on a small Java project in Workforce 5.x. The link I am about to mention brings together all 3 worlds.

    With that said check this out: http://codefeed.com/blog/?p=77

    Using virtual methods is important in TDD. Since TDD is a big part of code quality, I find it essential to know what your language does as it may come to bite you in unexpected ways otherwise. Our team has created a lot (in the past year) of C++ tests (both Unit and FIT). In C++ we have a HUGE deviation in how virtual methods get handled in constructors and destructor’s, BUT one caveat for those using Borland’s flavour of C++:

    If you derive your class from the VCL class TObject, your virtual method’s will get called in the same order as C# (since TObject is in fact a Pascal class and does NOT follow C++ convention). This was found recently went a collegue create a new unit test around a pure C++ class and started getting runtime errors about a pure virtual method getting called!

    To summarize, I find the link mentioned above interesting as its rare to see Java painted in such a negative way, but of course that all depends on what perspective you come from.

    Thanks.


  • The Choo Choo Discount

    I’m sitting here in beautiful Beaverton Oregon, it’s 5:22 am and I’m wide awake. I recall the previous day during checkin to the hotel the following events:

    Me: Hello, I was wondering if you knew of company X as I’m here to train some employees.

    Hotel Staff: Yes we know company X, are you with them?

    Me: Yes, could you tell me how to get to their address?

    Hotel Staff: Sure, but first if you show me some documentation showing you are doing some work for them you will get a much better rate for your room.

    Me: Ok.. (co-worker shows a letter from our boss)

    Hotel Staff: Glad to have you, hope you enjoy your stay.

    time passes…

    1:30 am Choo Choo.. LOUD choo choo

    5:30 am Choo Choo LOUD choo choo

    As I go to check email… hey there’s co-worker X also logging into MSM 🙂

    Choo choo all the way! Thats the Choo Choo discount!

    (which is ok, gives more time to prepare for the day anyhow :))


  • Discovering memory leaks and application crashes in BDS 2006

    Over the past couple of days I plunged into our product suite (see http://www.kronos.com/Products/TotalCare.htm) to look for memory leaks and check for any code smells (an Agile term). I remembered back to the good old days when I would use memproof under BCB6 and quickly find and fix my issues, alas in BDS2006 I had no such success. Memproof has not been updated to support BDS2006 so I checked out what my options were. Ultimately I ended up compiling all our packages, application and workspace plugin dll’s under Codeguard which is built into BDS2006. In some ways codeguard is good and in other ways it is aweful. One particular situation to note was that during application exit, the program would crash with an access violation error. This would ONLY happen when one of the plugin DLL’s was fully loaded. Codeguard would not tell me what the problem was but gave me a clue… the clue was the CPU window showed that recently the c++ runtime library was unloading. After many recompiles and compiler setting changes… somehow.. i am not sure.. I think it was a fluke.. but codeguard stopped on a line of code during the access violation! Wonderful! Here was the code:

    void __fastcall MyFunc()

    {

         ostrstream out1;

         out1 << “myField = ” << iID << ends;

         AnsiString asFilter = out1.str();

    }

    Now i have simplified the code but in essence the ostrstream object was the cause of the crash. I noticed this posting on google: http://groups.google.ca/group/borland.public.cppbuilder.ide/browse_thread/thread/caaee99d8be8d0bf/d77d653639e82abd?lnk=st&q=ostrstream+bug&rnum=3&hl=en#d77d653639e82abd

    which at some point mentiones:

    “Also, is there any reason why you’re not using ostringstream, since
    the strstream classes are depreicated?  

    If you need to use the strstream class, note that you’re leaking
    memory, since you’re responsible for deleting (delete[]) the pointer
    returned by the call to str().)”

    So the fact that this DLL was leaking memory had caused a crash at application shutdown.. and to “mask” the problem someone has changed the linker options for that DLL and disabled Use Dynamic RTL.

    Instead of “cleaning up” after the .str() calls I replaced the filter statements with typical AnsiString.sprintf()’s and voila… compile the DLL using dynamic RTL and no more crash on exit. It always troubles me when a workaround is used which nobody knows why it was used 🙂 Now we know what was going on and it was fixed. One thing I have found out about Codeguard… it is somewhat unwieldy to use but almost always is correct in telling you “something is wrong” just not any more detail than that.


  • A Technical follow-up to the security rollout from Microsoft and how to change your own program to not be affected

    After realising in Microsoft’s hotfix regarding the ANI security update that they won’t be pushing out that hotfix I decided to update CallerID to load the htmlhelp subsystem at the end of dll initialization, thus avoiding this problem altogether. For anyone using Borland Compilers goto the Advanced Linker Tab and click the ellipses on the Dlls to delay load. Add the name hhctrl.ocx to the list (most likely already empty). Recompile your program and voila. How do you know it fixed it? Before doing this change open your application using depends:

    http://www.dependencywalker.com/

    And see if hhctrl.ocx is at the top of the list. Recompile your program and refresh or reopen it with depends and now the ocx is loaded at the end.

    Hope this helps.


  • Interesting Security

    Just recently I installed a security “fix” from Microsoft Auto Update which involved modifying how some windows system DLL’s load. Well as soon as I reboot after applying this “auto update” CallerID would crash with the following message when windows starts:

    Well what is going on? CallerID didn’t change so why are we getting this error? What changed? Aha the security “fix” must have changed something! After searching on Google I found this link:

    http://support.microsoft.com/kb/935448/en-us

    which talks about a new “hotfix” for the security update. After downloading and installing this hotfix, CallerID is working as it always did, now back to what I was working on before this costly event 🙂

    Just a note about CallerID, I not only author the application, I myself rely on it. I work between home and business offices and rely on my call info/voicemail getting passed from one location to another using the “network” feature, which to me is totally awesome.

    Anyone out there who cannot or does not want to get the hotfix from Microsoft, just replace the EXE in the zipfile at:

    http://www.soft-haus.com/vsoft/files/2-1-0-9.zip

    overtop of the one in your callerid installation folder.