Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 25 Aug 2004 14:46:55 -0400 From: Luke Stras To: cygwin AT cygwin DOT com Subject: Re: Trouble with std::vector in g++ Message-ID: <20040825184655.GL9503@arrow.utias.utoronto.ca> Reply-To: stras AT utias DOT utoronto DOT ca References: <20040825164918 DOT GF9503 AT arrow DOT utias DOT utoronto DOT ca> <11845274424 DOT 20040825191645 AT familiehaase DOT de> <20040825172547 DOT GI9503 AT arrow DOT utias DOT utoronto DOT ca> <412CDD2B DOT 2040601 AT etr-usa DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <412CDD2B.2040601@etr-usa.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j On Wed, Aug 25, 2004 at 12:40:43PM -0600, Warren Young wrote: > I would have said that the right solution is to 'new' that Element > object, or to declare it globally. The stack is not intended for > storing megabytes of data, especially temporary data. Well, yes. Normally, I'd do that, but I'm hunting the source of some subtle memory corruption which seems to crop up if a member gets added to a class, but which (mostly) fixes itself if the member is made large enough. Hence, the large array. In any case, this is getting significantly off-topic for the list. -- Luke Stras "The meek can have the Earth; the rest of us have other plans" --Henry Spencer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/