From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18834 invoked by alias); 5 Jun 2012 18:34:15 -0000 Received: (qmail 18825 invoked by uid 22791); 5 Jun 2012 18:34:14 -0000 X-SWARE-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_FN,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Jun 2012 18:33:40 +0000 Received: by qady23 with SMTP id y23so2814507qad.14 for ; Tue, 05 Jun 2012 11:33:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=FVsZG49z4i/YN+ApAZCQ+wMLSFtoLnDI/cgAto7ndRU=; b=l4mTipCtDtszog7BSlDWC0ieHl+t2c9yZQ2WZ2/d96kF/KFUNbAn/kequXs1uEJhge hHD48wK+P2AjmGyvYRwvT9SZ98+IZpJ2O0t88Sy/kNxpX++GRQYnubi3ovA2Ot1Kay5G ZVXfM6ly+qjnBo9+Ic3s25pQnmls/oICKKS9r6nBEYy5R+xiSXdRI2QkKEpsbSOQQxfT 2wSq9o64gSwuHrqUv5X6tBDuNKOGEpJ3FSlv11UtNg1YhrKtN5g1A+KLPeBKtAD9nxIx O29tvE3I9/h8pOZ1wpAle92HNqMvGpkT2564NM8NuQBG3vj67bD+76VEAy7qV7JyDk1q 0BXg== Received: by 10.229.134.199 with SMTP id k7mr4993289qct.99.1338921219283; Tue, 05 Jun 2012 11:33:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.134.199 with SMTP id k7mr4993283qct.99.1338921219142; Tue, 05 Jun 2012 11:33:39 -0700 (PDT) Received: by 10.224.131.26 with HTTP; Tue, 5 Jun 2012 11:33:39 -0700 (PDT) In-Reply-To: <87aa0in6ii.fsf@fleche.redhat.com> References: <87aa0in6ii.fsf@fleche.redhat.com> Date: Tue, 05 Jun 2012 18:34:00 -0000 Message-ID: Subject: Re: [RFC] Extend existing support for evaluating expressions using overloaded operators From: Siva Chandra To: Tom Tromey Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQn7hNbDiLX1yRAzKz1r/4bR96V1n41ag5++YCLcvjyi0rMbpCkqymaZ/q1uvegft9jkemt1irm+T0EG5kAW4t88vs2WQEC5RbCvxHqmSd8lCjQBdGc+Li0uxqgh01g7lOsteeLdezPTl0UO2hh1aAWaDc8Hpg== X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-06/txt/msg00136.txt.bz2 Siva> =A0 =A0 =A0 =A0 * valarith.c (value_binop): Extend to handle overload= ed Siva> =A0 =A0 =A0 =A0 binary operations on compound types. Tom> I don't understand why value_binop must be modified. Tom> I think in the current design it is up to the caller to check this. Tom> (I don't necessarily think this is a good design -- but changing it Tom> would require more changes elsewhere.) If we want to extend the operator overloading support into Python, then we will have to have code to decide whether to call value_binop or value_x_binop in the py-value.c. Another client of these two functions is evaluate_subexp_standard, which also has code to decide whether to call value_binop or value_x_binop. Though I did not mention in my post, my intention is avoid such repetitive code and get all clients to depend only on value_binop and treat value_x_binop as 'internal'. I would like to follow this patch with another patch to do this change. Note that, only evaluate_subexp_standard calls value_x_binop currently. Hence, replacing these calls with value_binop should not be much work (though I have not yet come up with a way to deal with the 'noside' argument of value_x_binop). Siva> +int Siva> +is_compound_type (struct type *type) Siva> +{ Siva> + =A0enum type_code type_code; Siva> + Siva> + =A0CHECK_TYPEDEF (type); Siva> + Siva> + =A0type_code =3D TYPE_CODE (type); Siva> + =A0if (type_code =3D=3D TYPE_CODE_STRUCT || type_code =3D=3D TYPE_C= ODE_UNION) Tom> It seems to me that there is other code which assumes that only Tom> TYPE_CODE_STRUCT can be overloaded. =A0At least binop_types_user_defin= ed_p, Tom> but maybe others. =A0Those spots should be updated. Actually, AFAICT binop_types_user_defined_p has a copy-paste typo due to which it is currently wrong. Even otherwise, with the change I have in mind this function can go away I think. Tom> It would be nice if the test suite tested this case as well. I agree, I will add more tests after we finalize this patch. Siva> + =A0 =A0 =A0TRY_CATCH (except, RETURN_MASK_ERROR) Siva> + =A0 =A0 =A0 =A0{ Siva> + =A0 =A0 =A0 =A0 =A0/* Retrieve the list of methods with the name NA= ME. =A0*/ Siva> + =A0 =A0 =A0 =A0 =A0fns_ptr =3D value_find_oload_method_list (&temp,= name, Siva> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 0, &num_fns, Siva> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&basetype, &boffset); Siva> + =A0 =A0 =A0 =A0} Siva> + =A0 =A0 =A0if (except.reason < 0) Siva> + =A0 =A0 =A0 =A0fns_ptr =3D NULL; Tom> I'll have to go read this in more depth; but I wonder why it is ok to Tom> ignore exceptions here. An exception is thrown if we are trying to lookup methods of a non-struct and non-union type. One can ask that, in such cases, why call value_find_oload_method_list at all. My argument is, if value_find_oload_method_list is doing the check, why should we repeat before calling it. Thanks, Siva Chandra