Re: To C++ or not to C++

From: Maslan (maslanbsd_at_gmail.com)
Date: 06/25/05

  • Next message: Erich Dollansky: "Re: To C++ or not to C++" 
    Date: Sat, 25 Jun 2005 01:39:21 +0300
To: Seán C. Farley <sean-freebsd@farley.org>

    i don't think this is the suitable mailling list to ask this question

    On 6/24/05, Seán C. Farley <sean-freebsd@farley.org> wrote:
    > On Fri, 24 Jun 2005, Ryan Sommers wrote:
    >
    > > Greetings all... I'm about to undertake a major software engineering
    > > project and I can't decide between C or C++ and was wondering if I
    > > could get some input from the community.
    > >
    > > As part of this project I'm going to need to make use of at least 2 C
    > > libraries (OpenSSL and ncurses) and the application must be compatible
    > > with the standard range of Linux/UNIX compilers and operating systems.
    > > All of these signs make me sway closer to just doing it in C. However,
    > > one strong point always seems to pull me back to C++, constructors and
    > > destructors.
    > >
    > > Constructors and destructors can offer so much in the way of memory
    > > leak avoidance. Of course, each language can leak memory like a sieve
    > > if used improperly. However, for statically allocated structures
    > > semi-automatic garbage collection can be a nice cushion.
    > >
    > > Anyway, without getting into too much detail. Anyone had to make this
    > > choice on a project? What were your thoughts in retrospect? What would
    > > you have done different, what would stay the same...
    > >
    > > PS For this project things like polymorphisms and inheritance really
    > > aren't needed.
    >
    > If you would like to use C but want some sort of memory handling, I can
    > recommend using the Apache Portable Runtime (APR) in
    > /usr/ports/devel/apr which uses memory pools. Although I have not used
    > it before, there is also the Boehm Garbage Collector found in
    > /usr/ports/devel/boehm-gc.
    >
    > Seán
    > --
    > sean-freebsd@farley.org
    >
    > _______________________________________________
    > freebsd-hackers@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
    >
    > 

    -- 
I'm Searching For Perfection,
So Even If U Need Portability U've To Use Assembly ;-)
http://www.maslanlab.org
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: Erich Dollansky: "Re: To C++ or not to C++"

    Relevant Pages

    • Re: To C++ or not to C++
      ... > Constructors and destructors can offer so much in the way of memory ... > leak avoidance. ... each language can leak memory like a sieve ... > semi-automatic garbage collection can be a nice cushion. ...
      (freebsd-hackers)
    • Re: Destructor: not gauranteed to be called?
      ... > implementation detail for destructors in C++. ... Destruction is a language ... Resource automatic freeing (mainly memory), ... The problem is that most developper know about finalizers (which ...
      (microsoft.public.dotnet.languages.vc)
    • Re: Garbage collection
      ... which is nothing to do with allocation or destructors. ... If a program is not invoking destructors properly, ... in my reasoning, it is better, yes, to free up objects as soon as possible (after all, this saves memory footprint and generally makes performance better). ... //done with buffer so I no longer give a crap ...
      (comp.std.c)
    • Re: Overloading new[]
      ... It would be prudent to run destructors before freeing the memory. ...
      (microsoft.public.vc.language)
    • Re: Destructor: not gauranteed to be called?
      ... destructors in managed code and destructors in native code. ... > finalizers, which are a different beast.CLI "destructors" have been ... perspective as a language designer, I see IDisposable as the implementation ... The main reason for GC is to avoid raw memory ...
      (microsoft.public.dotnet.languages.vc)