Re: [Texmacs-dev] Re: TeXmacs port to IRIX

[david]

On Tue, Jan 14, 2003 at 12:17:05PM +0100, Joris van der Hoeven wrote:

> > I've attached an initial diff-set (beware: these were by a script and thus
> > include diffs of auto-generated files such as configure), hoping that you 
> > and
> > the other developers will review those changes and include them, as you see
> > fit. It includes the followings changes:
> 
> Thanks for this extensive work.
> Would it be possible for you to cut this huge patch into
> a few smaller ones: essentially one for each of the points below?
> You may then post them at Savannah to the patch manager and
> I will apply them one by one.

I have designed a shell script to help with producing incremental
patches. If you are interested, I may post it here with some
instructions, but in that particular case (since you just have to
produce 3 or 4 patches) that would probably as simple for you to do
the work by hand.

> In the meantime, I took a rapid look at the changes.
> 
> >   1. Recognition of systems running Irix in the configure phase; this
> >      includes the handling of specific flags to system utilities (chmod
> >      doesn't have a -f option on Irix), compiler flags and permiting
> >      non-GNU compilers. (I'll need to do some more work in this area to
> >      check whether a 7.4.x or higher compiler is used, as older compilers
> >      have issues with the c++ code).
> 
> I will look at this in more detail later.
> David should also have a look at this.

I had a look on what is relevant to me. The message

        AC_MSG_ERROR(cannot find GNU C++ compiler)

should be updated. Something like:

        AC_MSG_ERROR(cannot find C++ compiler)

Also, on non-GNU compiler the default debugging options should
probably be -g instead of -ggdb. What is the option to get the most
debugging information out of your compiler?


> >   3. Removal of all uses of variable-length arrays from the C++ code.
> >      While C99 permits VLAs, the ISO C++ standard doesn't allow them (the
> >      currently discussed revision of the standard will support these, but
> >      it's probably going to be about 2 more years until that). Our compilers
> >      would allow VLAs for built-in types, but other may not. So I simply
> >      rewrote all occurences of this for the sake of consistency, standards
> >      conformance and portability.
> 
> It would be good to make this a configuration option,
> so that we do use variable-length arrays on systems where
> they are available (for speed reasons: by looking the changes,
> I identified several parts where direct allocation on the heap
> will really speed up the editor).
> 

I think then that it may be interesting to factor-out the
implementation of 'fast_array' to use stack allocation when available.
I thought of using compile-time dispatch, but that does not help.
Instead we may use a macro (yuck!).

  #if CONFIG_USE_VLA
  #define VARIABLE_LENGTH_ARRAY(TYPE,NAME,NUMBER) TYPE NAME[NUMBER]
  #else
  #define VARIABLE_LENGTH_ARRAY(TYPE,NAME,NUMBER) fast_array<TYPE> NAME(NUMBER);
  #endif

  template<class T> class fast_array<T> {
    T *a;
  public:
    inline fast_array(int n) { this->a = new T[n]; }
    inline T& operator[] (const int i) { return this->a[i]; }
    inline ~fast_array() { delete[] this->a; }
  };

Used as

  VARIABLE_LENGTH_ARRAY(char, data, byte_width * h);

Instead of 

  char data [byte_width * h];

That way we get all the speed we can, without cluttering the code with
ifdefs and gotos (YUCK!!!).


> >   5. Reordering to code in the header files that use templates to avoid
> >      problems with references to friend methods that aren't declared yet.
> 
> David should take a look at this.
> 

> >   6. A few (2 or 3) explicit casts to type (X**) for the result of a
> >      "new (X*) [...]" operation to work around an apparent bug in our
> >      7.4 compilers (I've also given notice about this to our C++ front-end
> >      engineers).
> 
> No problem; we will correct that too.

I am unsure that is really a compiler problem, and unsure the fix is
right. For the record, the original code looks like:

   tree** rs= new (tree*)[nr_rows];

ISO C++, section 5.3.4 [expr.new], clause 5:

  When the allocate object is an array (that is, the
  /direct-new-declarator/ syntax is used or the /new-type-id/ or
  /type-id/ denotes an array type, the /new-expression/ yields a
  pointer to the initial element (if any) of the array [Note: both 'new
  int' and 'new int[10]' have type 'int*' and the type of 'new
  int[i][10]' is 'int (*)[10]'.]

That means that no cast (implicit or explicit) should be involved in
this statement.

In ISO C++ section 5.3.4 [expr.new], clauses 1, 2 et 3 one see that
parenthesis in new-expressions can have suprising effects. It seems
that in that code (tree*) may be interpreted as a parenthesised
type-id and [nr_rows] as a new_initializer (which would yield a syntax
error). Actually the standard seems a bit ambiguous on that point,
which would explain that different compilers behave differently.

What is the actual error you are getting from your compiler?

Actually it seems that tree*[nr_rows] effectively means 'array of
nr_rows pointers to tree'. So the following is correct:

  tree** rs= new tree*[nr_rows];

A similar example is given in section 8.1 [dcl.name].

Actually, it does not even seems that the seemingly unambiguous

  tree** rs= new ((tree*)[nr_rows]);

is correct.

If one want to avoid type-id syntax, one should instead use typedef.

-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://alqua.com/tmresources
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.