Sun 03 Apr 2016 07:27:45 PM UTC, comment #12:
I think sized int types are always better, and are more consistent with the way integers are used throughout Octave already.
If more constructors are added, what type of octave_value should the following produce?
Right now, it matches the Array<octave_idx_type> and converts into an octave_matrix (a double-valued array).
I'm in favor of sized int types, but I think adding more constructors may end up adding confusion or breakage.
Users should use int32NDArray if that's what they meant to return.
|
Fri 01 Apr 2016 10:23:51 PM UTC, comment #11:
By "and that's it", I meant those would be the only constructors for integer types. The other constructors would, of course, remain.
|
Fri 01 Apr 2016 10:13:06 PM UTC, comment #10:
Should we change the Array<T> constructors so that we provide constructors for T = {u,}int{8,16,32,64}_t and that's it?
If so, then we should not have any duplicate constructors because of some typedef.
However, what should happen for these constructors? Should they create integer octave_values? That would be OK with me, but then we might have to be more careful when we actually do want to create double precision octave_value objects from integers. I think we are fairly careful about that now, but I'm not sure every case is handled correctly.
We already have constructors for T = octave_{u,}int{8,16,32,64}, but not for the bare C types.
Should we deprecate the value extractors that use C names like int_value, short_value, long_value, etc.?
Is it a good idea to always use sized int types? Then at least you know what range of values you can expect.
|
Tue 29 Mar 2016 04:35:33 AM UTC, comment #9:
Is there a way to give a clearer error than the current one? (I don't know much about compiler pragmas and such.) The current one will will still be unclear to most users, but I agree that no fix to the actual behaviour seems justified.
|
Mon 28 Mar 2016 10:13:34 PM UTC, comment #8:
I want to say this is invalid and should be closed as won't fix, but leaving open for now for other opinions.
There actually is no constructor for octave_value(const Array<int>&), there is only a constructor that takes an Array<octave_idx_type>. If octave_idx_type is not exactly "int", then it fails to construct and shows the full list of other constructors that one Array<> type may be converted (via copying) into another Array<> type.
There are valid constructors for all of the sized integer types that Octave uses, so those should be used instead, or octave_idx_type if the values being returned are actually indices into an Octave array.
|
Mon 28 Mar 2016 09:45:32 PM UTC, comment #7:
Ok, I can now confirm this with a 64-bit-indexing build of Octave on Debian also.
|
Sun 27 Mar 2016 12:28:26 PM UTC, comment #6:
When running mkoctfile helloworld_con.cc, with source file content of:
output:
|
Fri 25 Mar 2016 03:41:35 PM UTC, comment #5:
I'm doing a rebuild for win64, enable-64 currently, so when it is done, I will attach the whole list.
|
Fri 25 Mar 2016 03:38:21 PM UTC, comment #4:
The unanswered question for me still is which octave_value constructors are considered ambiguous under Windows with --enable-64? I don't have a 64-bit-index build on Debian at the moment to see if this is a problem there also. Can someone with a Windows build show the whole error or list which sets of constructors are considered ambiguous?
|
Fri 25 Mar 2016 03:30:01 PM UTC, comment #3:
The code is a simplified example of a function in octave forge netcdf package.
As such, would normally be compiled via mkoctfile from within pkg install.
If the array is changed from Array<int> to Array<double>, it does not have the error.
|
Fri 25 Mar 2016 03:41:14 AM UTC, comment #2:
Could you please be more specific? The code is C++ code, not Octave code. How are you trying to compile it? Is it with mkoctfile?
|
Tue 15 Mar 2016 10:22:46 AM UTC, comment #1:
For more info, this is only when octave was configured with --enable-64
|
Tue 15 Mar 2016 10:00:12 AM UTC, original submission:
In bug #46060, I have been told that the code below does not work on win32 and win64 versions of octave 4.0.1-rc3, while it works fine under Linux.
#include <octave/oct.h>
DEFUN_DLD (helloworld_con, args, nargout,
"Hello World Help String")
{
int nargin = args.length ();
Array<int> data = Array<int>(dim_vector(1,3));;
data(0) = 0;
data(1) = 1;
data(2) = 2;
return octave_value(int32NDArray(data));
// return octave_value(data); // same error
}
The produced error message is:
error: call of overloaded 'octave_value(Array<int>&)' is ambiguous
I don't see why this function call should be ambiguous and since it happens only on Windows I suspect an issue in octave.
I don't use windows so I cannot reproduce this myself, but maybe John Donoghue is available to provide more information if necessary.
|