From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 13 Sep 2015 14:27:28 +0000 Message-ID: References: <838ugdf251.fsf@gnu.org> <87bnl1vmqf.fsf@lifelogs.com> <87vbj8tow4.fsf@lifelogs.com> <87r3twtagf.fsf@lifelogs.com> <85siebl7ws.fsf@stephe-leake.org> <85a90ilwmm.fsf@stephe-leake.org> <83386a6f7z.fsf@gnu.org> <85h9upjz7v.fsf@stephe-leake.org> <83wq3k3kl4.fsf@gnu.org> <85bnkwil1c.fsf@stephe-leake.org> <83pp9cwky8.fsf@gnu.org> <85a90ggf2d.fsf@stephe-leake.org> <54E0A40F.5080603@dancol.org> <83sie7un20.fsf@gnu.org> <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@[87.69.4.28]> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <55F584E7.7090406@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3693c338c04051fa1c09d X-Trace: ger.gmane.org 1442154479 18519 80.91.229.3 (13 Sep 2015 14:27:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Sep 2015 14:27:59 +0000 (UTC) Cc: stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Daniel Colascione , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 13 16:27:57 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zb8G5-0006Z4-3z for ged-emacs-devel@m.gmane.org; Sun, 13 Sep 2015 16:27:57 +0200 Original-Received: from localhost ([::1]:36036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zb8G4-0006gz-Ig for ged-emacs-devel@m.gmane.org; Sun, 13 Sep 2015 10:27:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zb8Fp-0006gW-W7 for emacs-devel@gnu.org; Sun, 13 Sep 2015 10:27:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zb8Fo-0002JL-Rq for emacs-devel@gnu.org; Sun, 13 Sep 2015 10:27:41 -0400 Original-Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:35688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zb8Fm-0002I2-Sw; Sun, 13 Sep 2015 10:27:39 -0400 Original-Received: by wicge5 with SMTP id ge5so112366866wic.0; Sun, 13 Sep 2015 07:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=kG7WFYe5tP+CpKv1rNsu/95f3HRjmMVQsD49VTUIOeE=; b=MpZ0jPbAPrtTHC9C/CEl1NNQ9VJn5x1CVZvQM6MuM/9JUCw81XWVFCFCC/1TiZTmtw khotz80CY/G4COr5yWfAOtWZCQdm+2Wxk3M9rKsVr+AiT6TDdjMnMEKd/+syasCTLxLV qZCOQX9oNkBJu9Qqy+ysJT6g4vUhDF0eJI1xLgz6N6sjjNafxZDfc08ekWiN/oBFBPhG NmZPHA2iz4hvpM15rIYZF5UyEFY5bCTRA0H4BVniyD0f2KkiOogTmJoryndk/afc7z8T jmSAbLvzBiBGIMfRjaFEUo8N0+mcSveSunGvPXFl9ZKoelxn6xZ6N8xwYvMszp1GUJQe FyJA== X-Received: by 10.180.211.39 with SMTP id mz7mr16577235wic.65.1442154458350; Sun, 13 Sep 2015 07:27:38 -0700 (PDT) In-Reply-To: <55F584E7.7090406@dancol.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189894 Archived-At: --001a11c3693c338c04051fa1c09d Content-Type: text/plain; charset=UTF-8 Daniel Colascione schrieb am So., 13. Sep. 2015 um 16:15 Uhr: > On 09/13/2015 06:04 AM, Philipp Stephani wrote: > > Daniel Colascione > schrieb > > am So., 15. Feb. 2015 um 21:21 Uhr: > > > > typedef struct emacs_value_tag* emacs_value; > > > > > > Would it make sense to not use a typedef here? Using a typedef means > > that the type including its size is opaque and subject to change, which > > can break ABI compatibility. I'd rather have something like: > > > > struct emacs_value { > > // contains private fields > > }; > > > > and then pass /struct emacs_value*/ around. > > You may have missed the "*" in the typedef. The difference is stylistic. > There's no difference between foo and bar here. > > typedef struct valuex* value; > void foo(struct valuex* x); > void bar(value y); > > I find the typedef much more readable, however. > > There's no difference in your design, but using a typedef makes it possible to use a non-pointer type without changing the API in obvious ways. E.g. Linus is strongly against such typedefs: http://lkml.iu.edu/hypermail/linux/kernel/0206.1/0402.html --001a11c3693c338c04051fa1c09d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Daniel= Colascione <dancol@dancol.org&= gt; schrieb am So., 13. Sep. 2015 um 16:15=C2=A0Uhr:
On 09/13/2015 06:04 AM, Philipp Stephani wrote:
> Daniel Colascione <dancol@dancol.org <mailto:dancol@dancol.org>> schrieb
> am So., 15. Feb. 2015 um 21:21 Uhr:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0typedef struct emacs_value_tag* emacs_value;=
>
>
> Would it make sense to not use a typedef here? Using a typedef means > that the type including its size is opaque and subject to change, whic= h
> can break ABI compatibility. I'd rather have something like:
>
> struct emacs_value {
>=C2=A0 =C2=A0// contains private fields
> };
>
> and then pass /struct emacs_value*/ around.

You may have missed the "*" in the typedef. The difference is sty= listic.
There's no difference between foo and bar here.

typedef struct valuex* value;
void foo(struct valuex* x);
void bar(value y);

I find the typedef much more readable, however.


There's no difference in your desi= gn, but using a typedef makes it possible to use a non-pointer type without= changing the API in obvious ways.=C2=A0
E.g. Linus is strongly a= gainst such typedefs:=C2=A0http://lkml.iu.edu/hypermail/linux/kernel/0206.1/040= 2.html
--001a11c3693c338c04051fa1c09d--