GNOME Bugzilla – Bug 570821
Support array += without array size variable
Last modified: 2018-05-22 13:17:31 UTC
Please describe the problem: In the testcase I get an error (from ccode) if the string array is public. If it is private, then it compiles. It looks like vala tries to take the size of the array from the class that contains the array. Steps to reproduce: Testcase: using GLib; public class TestKlass : GLib.Object { public string[] ar; public void test_it() { ar = new string[0]; ar += "hello"; } public static int main(string[] args) { TestKlass ff = new TestKlass(); ff.test_it(); return 0; } } /* if ar is public then: refarraytest.c: In Funktion »test_klass_test_it«: refarraytest.c:33: Fehler: »TestKlass« hat kein Element namens »ar_size« error: cc exited with status 256 Compilation failed: 1 error(s), 0 warning(s) */ Actual results: Expected results: Does this happen every time? Other information: Vala 0.5.6
with vala 0.7.3 the problem still exists if the array is declared as public
Confirming.
Problem still exists on 0.7.9: "has no member named ‘ar_size’"
*** Bug 614010 has been marked as a duplicate of this bug. ***
Problem still in 0.8.1; in more complex code that can't easily be stripped down to a minimal testcase I also get: ERROR:valaccodearraymodule.c:1406:vala_ccode_array_module_real_get_array_size_cexpression: code should not be reached
The problem is still here It can also be triggered with this: public class Test { public int[] ia = {}; public void run() { ia += 4; } public static void main() { var t= new Test(); t.run(); } } That gives me gcc error: /home/me/Desktop/arraytest.c: In function ‘test_run’: /home/me/Desktop/arraytest.c:73: error: ‘Test’ has no member named ‘_ia_size_’ If the class(!) is made private, it works as expected: class Test { public int[] ia = {}; public void run() { ia += 4; } public static void main() { var t= new Test(); t.run(); } } It is a pity that this doesn't work because I have to use an ultra slow GLib.List instead.
(In reply to comment #6) > It is a pity that this doesn't work because I have to use an ultra slow > GLib.List instead. It's only slow if you append to it. If you prepend to it, it's fast.
Yes, I know. But this bug is not about GLib.List Just forget what I said about it.
I think this bug is related with #627093: instead of an array in a public class, it is an array in a public struct. https://bugzilla.gnome.org/show_bug.cgi?id=627093
commit 89c0afc73b3d0d9aa34403f831361610c1bddf45 Author: Jürg Billeter <j@bitron.ch> Date: Thu Sep 9 17:58:10 2010 +0200 codegen: Report error on unsupported use of array concatenation
*** Bug 627093 has been marked as a duplicate of this bug. ***
I'm considering deprecating += support in favor of really good GArray bindings. GArray in recent GLib versions (2.22+) supports reference counting; memory management could be fixed and missing convenience methods could be added in the bindings. To me this sounds like a better plan than trying to make low level arrays usable with extra operators. Any comments?
Good idea! What will be the equivalent syntax of += with GArray? Because += is convenient to use.
(In reply to comment #13) > What will be the equivalent syntax of += with GArray? Because += is convenient > to use. That's Array.append_val(). As g_array_append_val() is a macro, we might need to improve code generator / bindings to work properly in all cases. It might also make sense to rename it to just append().
While I appreciate this to work based on GArray, I'm not so fond of deprecating a syntax that is in _wide_ use already. Moving all the usages of += to GArray will be a lot of work on behalf of the users.
(In reply to comment #15) > While I appreciate this to work based on GArray, I'm not so fond of deprecating > a syntax that is in _wide_ use already. Moving all the usages of += to GArray > will be a lot of work on behalf of the users. I certainly understand this. While deprecated syntax is meant to be removed completely at some point, in this case I'd definitely go with a very long deprecation period. The main point of this deprecation for the near-term future would be that we don't extend the scope of the current += support (i.e., WONTFIX this bug), prepare nice GArray bindings, and point all users to GArray for new code. Please note that you can hide deprecation warnings with --enable-deprecated, so that you can put off porting until you have time for that without getting constantly distracted. Do you consider this deprecation problematic even with a long deprecation period or do you have any counter proposals?
No, I think this is perfectly acceptible and the benefits will outweigh the inconvenience in the long run.
Would it be possible to have convenience functions for GArray to easiely convert a GArray to a low level array? This would make living without += operator a lot easier, specially because low level arrays are available in bindings very much.
(In reply to comment #18) > Would it be possible to have convenience functions for GArray to easiely > convert a GArray to a low level array? This would make living without += > operator a lot easier, specially because low level arrays are available in > bindings very much. Yes, I definitely want to allow convenient access to the underlying low level array. That way, you just have to port code that owns/creates/modifies the array and can still use regular C arrays to pass things around (either as unowned array or as a copy).
That sounds like a good solution
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/25.