Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Apr 2003 00:34:11 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        gmarco@scotty.masternet.it
Cc:        hackers@freebsd.org
Subject:   Re: gcc iussue or ... ?
Message-ID:  <20030412.003411.28085408.imp@bsdimp.com>
In-Reply-To: <5.2.0.9.2.20030412080941.016d0978@194.184.65.7>
References:  <5.2.0.9.2.20030411223601.053eaeb8@194.184.65.7> <20030411.230438.53067150.imp@bsdimp.com> <5.2.0.9.2.20030412080941.016d0978@194.184.65.7>

next in thread | previous in thread | raw e-mail | index | archive | help
OK.  Looks like you are creating an array of PacketReader objects.  It
looks like this array has a non-default constructor for its buffer
object (hard to tell for sure, but it appears that way).  This is
causing it to wind up in the data section.

I'm not sure why other systems aren't resulting in this.  That seems
odd to me.

Better if you hack CArray to have, instead of its LB intearnalArray[c]
a LB *internalArray and have it new/delete in its ctor/dtor.  That
likely would reduce the size a *LOT*.

template <const int c, class LB> CArray<c, LB>::CArray(std::string s):
 maxxx(c), error(0), arrayName(s), fn(NULL)
{
	internalArray = new LB[c];
}

But using a template for this is code-space wasteful since you get a
separate class generated for each size of the array that you want to
instantiate.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030412.003411.28085408.imp>