Thanks for the help. Key and value both need to accept null, so I think "string?" is required. The issue wasn't value being null but rather that it referenced invalid/freed memory. I usually got two or three random letters instead of my input string along with an occasional "glibc detected *** double free or corruption." or segmentation fault.
Ultimately I couldn't resolve the issue with the generic and refactored it into a normal class. With only the generic G,H replaced with string?, things are now working properly. Regards, Dennis Am 29.08.2012 10:26, schrieb Nor Jaidi Tuah: >> Anyway, I've removed every weak/un/owned keyword from the code to start >> from the beginning. Since I only use GObject based classes, strings and >> arrays of strings, shouldn't the worst case scenario be that I end up >> with circular references that don't get freed? Instead the TreeNode's >> add method now adds "empty" nodes (invalid string references I suppose). > If you're not expecting null node.value, I suggest putting > assert(value != null) before adding to the LinkedList, and > putting assert(node.value != null) after reading from it. > > Personally, there are many times when assert reveals my own > lapses after 100% sure that the Vala compiler must be buggy :-) > > >> I've made the generic TreeNode's add-method virtual and overrode it in >> Variable so that I can print out the values. Now however, the Node >> actually stores the values properly (for a while). Why? All I did was >> copy and paste the generic's code and fill in the types, which is the >> same Vala would do, right? > C++ would do that. I don't think that is the Vala's way. > Vala's generics are not "instantiated" into specifics. > They remain generics in the compiled version. (Unless > I've totally misunderstood Vala's generics). > > Nice day > Nor Jaidi Tuah > > > > PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you > are neither the addressee (intended recipient) nor an authorised recipient of > the addressee, and have received this message in error, please destroy this > message (including attachments) and notify the sender immediately. STRICT > PROHIBITION: This message, whether in part or in whole, should not be > reviewed, retained, copied, reused, disclosed, distributed or used for any > purpose whatsoever. Such unauthorised use may be unlawful and may contain > material protected by the Official Secrets Act (Cap 153) of the Laws of > Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei > Darussalam, accept[s] no responsibility for loss or damage arising from the > use of this message in any manner whatsoever. Our messages are checked for > viruses but we do not accept liability for any viruses which may be > transmitted in or with this message. > _______________________________________________ > vala-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/vala-list _______________________________________________ vala-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/vala-list
