octave-maintainers
[Top][All Lists]
Advanced

[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


reply via email to

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