Mirror of forum.nim-lang.org

962 :: Strange code gen for procs returning arrays

• robohamburger (orginal) [2015-03-03T23:23:14+01:00] view original

  I have matrix type that looks like:

  type Mat4f* = array[0..15, float]
  Run

  A proc that returns a matrix:

  proc get_rot_mat*(camera:Camera) : Mat4f
  Run

  And some code that calls:

  var mat:Mat4f = cam.get_rot_mat()
  Run

  The code generating at the call side is quite odd. It compiles in C and fails to compile in C++

  C code:

  mat4f708077 mat;
  nimln(48, "main.nim");
  glloadidentity_502807();
  memset((void*)mat, 0, sizeof(mat));
  nimln(59, "main.nim");
  chckNil((void*)mat);
  memset((void*)mat, 0, sizeof(mat));
  getrotmat_711021((&cam_716039), mat);
  Run

  C++ code:

  mat4f708077 mat;
  memset((void*)mat, 0, sizeof(mat));
  nimln(59, "main.nim");
  chckNil((void*)mat);
  memset((void*)mat, 0, sizeof(mat));
  getrotmat_711021((&cam_716039), mat);
  Run

  It is interesting in both of these the redundant memetset and chckNil. I assume that is an optimization that might happen if I ran nim with the right flags?

  C++ Compiler error:

  /Users/amcharg/projects/voxamles/nimcache/main.cpp:286:2: error: no matching function for call to 'getrotmat_711021'
          getrotmat_711021((&cam_716039), mat);
          ^~~~~~~~~~~~~~~~
  /Users/amcharg/projects/voxamles/nimcache/main.cpp:117:17: note: candidate function not viable: no known conversion from 'mat4f708077' (aka 'NF   [16]') to 'mat4f708077 *'
        (aka 'NF (*)[16]') for 2nd argument; take the address of the argument with &
  N_NIMCALL(void, getrotmat_711021)(camera711013* camera, mat4f708077* Result);

  I imagine most people pass these as refs or put them in an object? I prefer just having an array. I assume the compile error is a bug though.

---

• Araq (orginal) [2015-03-04T03:13:13+01:00] view original

  Report the C++ codegen bug please, but returning arrays is weird because C doesn't support it at all.

---

• robohamburger (orginal) [2015-03-04T03:50:32+01:00] view original

  Done: https://github.com/Araq/Nim/issues/2259

  Yeah looking at the C code I am not sure how it works ether. The function takes a pointer to a matrix but only a matrix is being passed in.

---

• novist (orginal) [2015-03-04T08:36:28+01:00] view original

  @Araq: well c might not support it but it does not mean its a bad thing. vcc does interesting thing in c++ - when you return object from the stack it actually is not returned from function at all. Caller allocates that object and passes it as call param all behind the scenes. So even if we return local std::string() its pretty fast because in reality proc operates on result living in parent stack right away. That sounds useful to me.

---