Skip to Content.
Sympa Menu

mathemagix-devel - Re: [Mathemagix] Re: [Fwd: [Mmx-commits] Bug report: mmx crashes on intel based macs]

Subject: Mathemagix

List archive

Re: [Mathemagix] Re: [Fwd: [Mmx-commits] Bug report: mmx crashes on intel based macs]


Chronological Thread 
  • From: Joris van der Hoeven <address@concealed>
  • To: address@concealed
  • Subject: Re: [Mathemagix] Re: [Fwd: [Mmx-commits] Bug report: mmx crashes on intel based macs]
  • Date: Mon, 22 Oct 2007 12:51:37 +0200

On Mon, Oct 22, 2007 at 12:33:13PM +0200, Grégoire Lecerf wrote:
> >After the modifications generic -> string in the two files,
> >everything compiles as a charm for me. I made the changes on SVN;
> >please retry to be sure that we are doing the same thing.
> >
> I do not like this solution because it does not prevent from future
> similar crashes. Danger might also come from the outside the basix library
> if static
> variables are not handled in a
> robust way. The solution I proposed in mixed_symbol.hpp is standard. As
> for the desallocation problem
> caused by the "new" without explicit destruction (although the
> destruction is actually done
> properly at the very end of the exit) can be simply avoided by:
> TMPL_DEF
> class mixed_symbol_rep REP_STRUCT {
> public: // FIXME: should become private
> static table<Mixed_symbol_rep*,C,eq_op>& mixed_symbol_entries () {
> static table<Mixed_symbol_rep*,C,eq_op> t((Mixed_symbol_rep*) NULL);
> return t;
> }
> Does it suit you? -- There's no speed-down :-)

Yes, that is fine too, please make the appropriate changes on SVN.
I am not completely confident though. I tried things like this too,
and I still encountered problems in more complex situations.
Now that things have been broken up in several libraries,
the complexity has been cracked down and most problems with
global variables seem to have vanished alongwith.



Archive powered by MHonArc 2.6.18.

Top of Page