From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18457 invoked by alias); 23 Jun 2002 01:03:51 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 18449 invoked from network); 23 Jun 2002 01:03:47 -0000 Received: from unknown (HELO brouhaha.com) (209.66.107.17) by sources.redhat.com with SMTP; 23 Jun 2002 01:03:47 -0000 Received: (qmail 23915 invoked by uid 1032); 23 Jun 2002 01:03:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 Jun 2002 01:03:49 -0000 Date: Sun, 23 Jun 2002 14:56:00 -0000 From: Scott Dattalo X-X-Sender: sdattalo@ruckus.brouhaha.com cc: ecos-discuss@sources.redhat.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: [ECOS] malloc vs. new X-SW-Source: 2002-06/txt/msg00410.txt.bz2 On Sat, 22 Jun 2002, Dan Conti wrote: > new shouldn't be broken, since it just calls malloc. does malloc work > when making allocations of the exact same size? malloc works fine but new fails. I did a real simple case where I malloc'd 75 bytes and new'd a 75 byte char array. > > two things to try as workarounds: > > 1) write your own operator new/new[]/delete/delete[]. tossing the > following into some file should work: I thought about this, but when you overload new and delete the constructor is no longer called (actually, that's an assumption on my part). So I'll have to add special code to initialize the objects as they're new'd. > 2) use placement new, which is what you were getting at below. be wary > of alignment considerations for the buffer you use. also at clean up you > have to manually call the destructor IIRC. C++ is not my forte. > > #include > > char buffer[1024] __attribute__((align(4)); > > CObject* pObj = new(buffer) CObject(); > > ... > pObj->~CObject(); > > Good luck. Thanks for the help. Little tid-bits about alignment and such are good to know. I'm going to dig a little deeper with the debugger and determine exactly the mode of failure. new'ing is such a fundamental thing that I'd be extremely surprised if it didn't work in an eCos world. While I could work around new (with malloc for example), I don't wish to artificially constrain other developers that will eventually be working on the code base that I'm creating. OTOH, this *is* an embedded application and most of the desktop assumptions (like infinite memory) are invalid! Scott -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss