texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Texmacs-dev] Mandrake (and thought about typing and ref counting)


From: Stéphane Payrard
Subject: [Texmacs-dev] Mandrake (and thought about typing and ref counting)
Date: Sun, 8 Sep 2002 17:46:57 -0400
User-agent: Mutt/1.4i

On (08/09/02 16:55), Joris van der Hoeven wrote:
> From: Joris van der Hoeven <address@hidden>
> To: address@hidden
> Subject: Re: [Texmacs-dev] Mandrake 
> Reply-To: address@hidden
> Date: Sun, 8 Sep 2002 16:55:36 +0200 (MET DST)
> 
> 
> > > > we need to submit soon a TeXmacs with its  allocation stuff 
> > > > #ifdef'ed out for linux (the first four functions of basic.cc). It
> > > > crashes with gcc 3.2 which is the default compiler for Mandrake.
> > > > And Mandrake is about to be released.
> > > 
> > > Is that the only reason why it crashes?
> > > Did you debug this carefully?

No I did not try to debug. But the fact is that the code is stable
without your allocation stuff and not without. I agree that does not
necessarily mean that the real problem is there.

My focus is on getting the Qt loop in and I noticed that removing your
allocation code solves the problem of immediate crash in that case.
And it appears that by the same removal TeXmacs seems more stable on
Mandrake cooker rc1 platform. It seems that with g++ the standard
allocation scheme is fast enough.

If performance is your concern (which must be the case because you get
out of you way to write allocation code), you can win big by 1/
passing stuff by const references when we can; 2/ also removing
reference counting would be good except if there is a strong
motivation for it (Guile). But these are totally different issues. The
combination of reference counting with pass by value is probably
disastrous. I have no figure for that but stepping in debugging mode
one spend his time in reference counting stuff.

1/ can be done by big increments because when one start to declare
  things with constraint (which is good) this must spread very fast
  because the compiler enforces it very well.

2/ is major work and 1/ is a mandatory preliminary step because strong
typing help to udserstant what own what.


Probably this should discussed in a non virtual meeting. 

Related issues that bothers me now I got more understanding of C++ (by
reading Stroustrup, Meyers and Alexandrescu, and experimenting on my
own) is the style prevaling in TeXmacs where the nature of objects is
hidden by typedef:

typedef foo*  foo_rep 

As a result it is never immediately clear when pointers are passed
around.  I understand that for esthetic reasons one does not want to
sprinkle code declaration with consts and non alphabetic chars but I
am less and less sure this style is real C++.


Sorry for this diversion, but I think we need to think and agree about
it. I think that david has already talked about that but I don't
remember exactly what.



> > 
> > I am not the only one experiencing that.  And yes. it is not the only
> > crash reason but it is a very sure and a very       one. But with gcc-2.3,
> > TeXmacs does not last 2 minutes even inactive with that code.  Also
> > when I link to Qt, with this code TeXmacs crashes immediately.
> 
> Well, I am not willing to switch to another memory allocation scheme yet,
> but I am willing to take a closer look at the problem. However,
> gcc-3.2 seems to be incompatible with all existing object code.
> Does this mean that I have to recompile X?  :^<
> 
> Why does it crash anyway?
> Has memory allocation changed in the mean time?
> Is standard C++ no longer standard?
> 

The problem with C++ is that everything must be compiled with the same
version of the same compiler. Apparently, if you don't and that you
code links with libraries, it can nevertheless crash.  But this does
not concern X libraries because they are C libraries.  Qt are C++
libraries on the other hand.

I am not a C++ specialist so everyone is welcome to step in if I
got something wrong.


--
  stef




reply via email to

[Prev in Thread] Current Thread [Next in Thread]