[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
eliminate streamoff type? (was Re: CVS build error with new sort)
From: |
John W. Eaton |
Subject: |
eliminate streamoff type? (was Re: CVS build error with new sort) |
Date: |
Wed, 02 Apr 2008 13:11:59 -0400 |
On 2-Apr-2008, John W. Eaton wrote:
| On 2-Apr-2008, Thomas Treichl wrote:
|
| | Some time has been passed on this thread but the problem still follows me
on
| | MacOSX. You have been right with std::streamoff==long long int. I also
tried to
| | use several variations of -weak options for the linker but has not been
successful.
| |
| | So I gave it a try to write a configure test for it. Can somebody please
have a
| | look at it and tell me if this would be the right way to do it (can the
| | AC_CHECK_TYPES for std::streamoff be neglected)? If so then I can prepare a
| | changeset for the current sources the following days. My idea was then to
change
| |
| | liboctave/Array-i.cc:#if defined (HAVE_LONG_LONG_INT)
| |
| | into
| |
| | liboctave/Array-i.cc:#if defined (HAVE_LONG_LONG_INT) &&
| | !defined (HAVE_LONG_LONG_INT_STREAMOFF)
|
| I think we need to check whether streamoff is actually a typedef for
| "long long int", not just that it has the same size. For example, if
| it is a class that happens to have the same size, I think we would
| need to instantiate arrays of streamoff objects separately from Arrays
| of "long long int" objects.
Another possibility is to eliminate the streamoff type. Do we really
need it now? As I recall, the original reason for having it was to
handle file positions for C++ streams. But now the streams that are
created with fopen/popen/etc. in Octave are all managed as C-style
FILE pointers, so maybe the streamoff type is no longer needed?
jwe