bugGNU Octave - Bugs: bug #47416, call of overloaded...

 
 

bug #47416: call of overloaded 'octave_value(Array<int>&)' is ambiguous

Submitted by:  Alexander Barth <abarth>
Submitted on:  Tue 15 Mar 2016 10:00:12 AM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Build Failure
Status: Wont FixAssigned to: None
Originator Name: Alexander BarthOpen/Closed: Closed
Release: 4.0.1Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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.

Mike Miller <mtmiller>
Project Administrator
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.

John W. Eaton <jwe>
Project Administrator
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.

John W. Eaton <jwe>
Project Administrator
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.

Lachlan Andrew <lachlan>
Project Member
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.

Mike Miller <mtmiller>
Project Administrator
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.

Mike Miller <mtmiller>
Project Administrator
Sun 27 Mar 2016 12:28:26 PM UTC, comment #6:

When running mkoctfile helloworld_con.cc, with source file content of:

output:

John Donoghue <lostbard>
Project Member
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.

John Donoghue <lostbard>
Project Member
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?

Mike Miller <mtmiller>
Project Administrator
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.

John Donoghue <lostbard>
Project Member
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?

Lachlan Andrew <lachlan>
Project Member
Tue 15 Mar 2016 10:22:46 AM UTC, comment #1:

For more info, this is only when octave was configured with --enable-64

John Donoghue <lostbard>
Project Member
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.

Alexander Barth <abarth>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #36647:  helloworld_con.cc added by abarth (282B - text/x-c++src)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Updated the item)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by lachlan (Posted a comment)
  • -unavailable- added by lostbard (Posted a comment)
  • -unavailable- added by abarth (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 23 Nov 2016 11:58:41 PM UTCmtmillerOpen/ClosedOpen=>Closed
    Wed 24 Aug 2016 03:40:04 AM UTCrik5Severity4 - Important=>3 - Normal
    Fri 01 Jul 2016 05:24:02 PM UTCrik5Severity3 - Normal=>4 - Important
    Mon 28 Mar 2016 10:13:34 PM UTCmtmillerStatusConfirmed=>Wont Fix
    Mon 28 Mar 2016 09:45:32 PM UTCmtmillerStatusNeed Info=>Confirmed
      Operating SystemMicrosoft Windows=>Any
    Fri 25 Mar 2016 10:10:21 PM UTCmtmillerRelease4.0.1-rc1=>4.0.1
    Fri 25 Mar 2016 03:38:21 PM UTCmtmillerStatusNone=>Need Info
    Tue 15 Mar 2016 10:00:12 AM UTCabarthAttached File-=>Added helloworld_con.cc, #36647

    Back to the top


    Powered by Savane 3.1-cleanup1