[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Re: TeXmacs port to IRIX
From: |
david |
Subject: |
Re: [Texmacs-dev] Re: TeXmacs port to IRIX |
Date: |
Tue, 14 Jan 2003 15:37:29 +0100 |
User-agent: |
Mutt/1.4i |
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.