Path: csiph.com!weretis.net!feeder4.news.weretis.net!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 25 Nov 2017 11:13:01 -0600
From: Gareth Owen <gwowen@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: "The long goodbye to C" by Eric Raymond
References: <oufppg$aqa$1@dont-email.me> <ov3nk8$22k$1@dont-email.me> <qPeRB.161561$ej.98762@fx46.am4> <ov42lr$h15$1@dont-email.me> <gehRB.43977$X11.19172@fx20.am4> <AQhRB.69183$2W2.36073@fx38.iad> <h0lRB.173971$Ts.135631@fx40.am4> <JzlRB.81276$XT.63127@fx37.am4> <ov60va$aqb$1@dont-email.me> <wlARB.45066$x74.29841@fx33.am4> <f7ok9lF1omrU8@mid.individual.net> <fnFRB.60641$W61.14006@fx08.am4> <f7om67F1omrU10@mid.individual.net> <87zi7cjib7.fsf@gmail.com> <f7pulbF1omrU11@mid.individual.net> <2OTRB.38544$UP1.27354@fx31.am4> <f7rmquF1omrU12@mid.individual.net> <g_2SB.84186$XT.46521@fx37.am4> <9H3SB.60877$Da3.11719@fx39.iad> <5G4SB.52862$321.17122@fx12.am4> <i4gSB.243322$bx3.99686@fx20.iad>
Date: Sat, 25 Nov 2017 17:13:01 +0000
Message-ID: <874lpigu3m.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
Cancel-Lock: sha1:CEgo+VNxbKpBlfkxBDkntRArqV8=
MIME-Version: 1.0
Content-Type: text/plain
Lines: 20
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-sNrFnmgMqF3Fm3vPVXqk7BsASrV2MFdDME7yWS927YY39xQIO9OIBCotvT7INosuYWkAJsyI44hjl99!ndJkdfokoMlw92WK7BZjz+7kuSpnWP5gwQo2QDx/eCgAAz5RnDKFfRapeEC2J5o3m7R4
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2500
Xref: csiph.com comp.lang.c:123490

Richard Damon <Richard@Damon-Family.org> writes:

> On 11/24/17 9:36 PM, bartc wrote:
>> I noticed that 'for (auto x:a)' didn't work on such an array (it
>> gave some interesting error messages), so I guess a few more things
>> need to be added to make it a drop-in replacement for a normal
>> array<>.
>
> That points out a second problem with this implemention, if the
> derivation from std::array had be public, this should have
> worked. Keeping it the default private means the new class needs to
> forward ALL of the member functions to keep full functionality.

That's definitely a case for public inheritance, but there's also a case
against it - mainly that std::array<> has a non-virtual destructor.

Personally, I'd use composition over either type of inheritance, just as
a general principle.

The generated code won't differ much in any of the cases.