🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: nl.comp.programmeren
Article #224

Re: Lijnen tellen van een project

#224
From: Sjoerd A. Schreuder
Date: Tue, 01 Feb 2005 01:38
109 lines
5427 bytes
moi wrote:
> Johan Wevers wrote:
> 
>> Sjoerd A. Schreuder <sa_schreuder@wanadoo.nl> wrote:
> 
> Even gewacht... Toch maar bijten!
> 
>>> Een boel C compilers zijn ook C++ compilers. En in C++
>>> is (void*)0 geen goede waarde voor NULL, omdat een (void*)
>>> niet omgezet mag worden in b.v. een (char*). C++ heeft immers
>>> een strictere type-checking dan C.
> 
> Onzinnig argument. Wat die compiler-fabrikanten doen, moeten
> zij weten. (C != C++) heet dat. Het zijn verschillende talen met
> verschillende regels. Als ze de compiler combineren met een broodrooster 
> is dat ook nog geen vrijbrief voor warmere objects.

Klopt.

> Dat van de typechecking is ook niet waar, althans voor ANSII-C.

In C++ is:
   char *p = (void*)0;
niet toegestaan volgens het type-systeem. NULL als (void*)0 definieren
kan dus niet, want dan zou:
   char *p = NULL;
niet kunnen en zou je altijd:
   char *p = (char*)NULL;
moeten schrijven.

Ik ken C99 niet goed genoeg, maar ik neem aan dat:
   mytype_t *x = malloc(sizeof(mytype_t));
nog steeds mogelijk is (anders te veel code oncompileerbaar).
Maar dat betekent dat het returntype van malloc(), (void*) of (char*)
of wat dan ook, zonder cast naar (mytype_t*) moet zijn om te zetten.

Als mijn aanname over C juist is, dan zit er dus wel degelijk een
groot verschil tussen C en C++ op dit punt.

> ( signed als default type vooral voor char zal wel het enige verschil 
> kunnen zijn, maar ik ken geen C++)

C++ heeft 4 char types: char, unsigned char, signed char en wchar_t.
Of 'char' de waarden -128..127 of 0..255 heeft (even aangenomen dat
CHAR_BITS == 8), is implementation-specifed.

>> Hmmm. Een void* kun je toch casten naar elk ander soort pointer,
>> ook in C++? Ik heb dat soort constructies vaak genoeg gebruikt
>> (void* casten naar een klasse naar keuze).

Die cast moet altijd expliciet zijn.

Je kunt in C++ van (subclass*) naar (superclass*) gaan zonder cast,
en van (T*) naar (void*), plus nog wat varianten. Andersom vereist
een cast.

[knip.... de "dat" in de volgende zin slaat niet op bovenstaande]

>>> Dat is handig in de volgende situatie:
>>>
>>> void foo(long);
>>> void foo(void*);
>>>
>>> int main()
>>> {
>>>  foo(NULL); // roept foo(long) aan
>>> }
>>
>> Dit vind ik levensgevaarlijke code. In zo'n geval kan het van de
>> compilerversie afhangen welke van de 2 overoaded functies aangeroepen
>> wordt. Leuk als je zoiets moet debuggen als het fout gaat. :-(
>>
>>> Bottomline: dit soort details zorgt ervoor dat C en C++ toch als
>>> verschillende programmeertalen moeten worden gezien.
> 
> Helemaal mee eens.
> Dat voorbeeld van die functies met verschillende signatuur geeft al aan
> hoe schijnbaar de typesafety van C++ is: de mogelijkheid om een andere 
> betekenis te geven wordt meteen geexploiteerd.

Huh?

Voor templates is het handig dat functies die conceptueel hetzelfde doen,
ook dezelfde naam hebben. Dan kun je in dezelfde template voor
verschillende typen gebruiken. Als je voor float fabs() en voor
longs labs() moet aanroepen, gaat er een boel gemak van templates
(het eenmalig schrijven van dezelfde code) verloren.

De richtlijn is: Functies die conceptueel verschillende dingen doen,
moeten een verschillende naam hebben. Functies die conceptueel hetzelfde
doen, kunnen dezelfde naam krijgen.

Als functies met dezelfde naam toch conceptueel hetzelfde doen, dan
maakt het niet uit welke versie je aanroept. De enige verschillen
zitten dan nog in performance en nauwkeurigheid.

>> Ja, al vind ik persoonlijk dat dat verschil zo klein mogelijk gemaakt zou
>> moeten worden i.p.v. zo groot mogelijk, waar sommige C++ ontwerpers
>> blijkbaar naar streven.
> 
> Dat weet ik niet. Of er nou grove verschillen zij of kleine: je moet op 
> je hoede zijn. Grote verschillen zijn wellicht makkelijker te 
> onthouden/detekteren.

Gelukkig zijn de verschillen zodanig dat je er zelden last van hebt.
En een beetje compiler zorgt dat er een warning wordt gegeven in
de gevallen dat er wel verschil zit.

Sjoerd
Technical Details
Message-ID: <41fedd9a$0$30144$abc4f4c3@news.wanadoo.nl>
Path: arc1-ca.pugleaf.net!g2news1.google.com!news1.google.com!proxad.net!212.101.4.254.MISMATCH!solnet.ch!solnet.ch!news2.euro.net!postnews1.euro.net!news.wanadoo.nl!not-for-mail
References: <%XJId.2415$OZ2.252982@phobos.telenet-ops.be> <ct9k2f.4js.1@news.isolution.nl> <IAzIFp.1qJ@vulcan.xs4all.nl> <41fa3d30$0$96924$abc4f4c3@news.wanadoo.nl> <IB6JF0.2FL@vulcan.xs4all.nl> <y6CdnR8nao-u5GPcRVnyvA@casema.nl>

Show Full Headers
Complete Article Headers
X-Google-Thread: 107324,ab34a8b99e320381
X-Google-Thread: fcea4,ab34a8b99e320381
X-Google-Attributes: gid107324,gidfcea4,public
X-Google-Language: DUTCH,ASCII-7-bit
Path: arc1-ca.pugleaf.net!g2news1.google.com!news1.google.com!proxad.net!212.101.4.254.MISMATCH!solnet.ch!solnet.ch!news2.euro.net!postnews1.euro.net!news.wanadoo.nl!not-for-mail
Date: Tue, 01 Feb 2005 02:38:33 +0100
From: "Sjoerd A. Schreuder" <sa_schreuder@wanadoo.nl>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: nl.comp.programmeren,be.comp.programming
Subject: Re: Lijnen tellen van een project
References: <%XJId.2415$OZ2.252982@phobos.telenet-ops.be> <ct9k2f.4js.1@news.isolution.nl> <IAzIFp.1qJ@vulcan.xs4all.nl> <41fa3d30$0$96924$abc4f4c3@news.wanadoo.nl> <IB6JF0.2FL@vulcan.xs4all.nl> <y6CdnR8nao-u5GPcRVnyvA@casema.nl>
In-Reply-To: <y6CdnR8nao-u5GPcRVnyvA@casema.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 110
Message-ID: <41fedd9a$0$30144$abc4f4c3@news.wanadoo.nl>
Organization: Wanadoo
NNTP-Posting-Date: 01 Feb 2005 01:38:35 GMT
NNTP-Posting-Host: c3eea3bf1.cable.wanadoo.nl
X-Trace: 1107221915 flip.euronet.nl 30144 62.234.59.241:1418
X-Complaints-To: abuse@wanadoo.nl