🚀 go-pugleaf

Dr.Ruud wrote:
> Ik hou de literals overigens graag links van de '==', dus zo:
> 
>      if (('F' == sex) || (('f' == sex) && (sex = 'F'))) do_female;
>      else if (('M' == sex) || (sex = 'M')) do_male;

Gatver. Daar houd ik totaal niet van. Bekijk eens:
   if (a.getB().getC() == "foo")
versus:
   if ("foo" == a.getB().getC())

In het eerste geval staan de dingen die je met elkaar vergelijkt
direct naast elkaar, in het tweede geval staan ze ver uiteen.
Als je snel leest, zie je bij versie twee alleen "foo" == a
en dat geeft een foute indruk.

Aangezien ik regelmatig door code moet scannen, vind ik het
prettig om dingen die bij elkaar horen bij elkaar te zetten.

Ik ken het argument dat het bugs voorkomt, maar elke compiler
geeft tegenwoordig wel een waarschuwing voor een assignment
binnen een conditie. En iedereen heeft toch (bijna) alle
warnings aan staan? (Ik weet het, dat is te optimistisch)

Maar misschien is het een kwestie van gewenning. Ik ben in ieder
geval totaal niet gewend om de literal voorop te zien staan.

Sjoerd

Toen ik Sjoerd A. Schreuder kietelde, kwam er dit uit:


>    [literal voor de "=="]
>
>    if (a.getB().getC() == "foo")
>    if ("foo" == a.getB().getC())
>
> In het eerste geval staan de dingen die je met elkaar vergelijkt
> direct naast elkaar, in het tweede geval staan ze ver uiteen.

Ja, dat vind ik een goed voorbeeld van waar het niet 'werkt'.


> Maar misschien is het een kwestie van gewenning. Ik ben in ieder
> geval totaal niet gewend om de literal voorop te zien staan.


De mainstream is het om 'm achterop te zetten. Dat zal vast wel
zo blijven, maar het blijft educatief om code tegen te komen waar
hij voorop staat.

-- 
Affijn, Ruud   `  -  �
               + ` � *
                 � `     Jvr qvg yrrfg,
               �  =  `   fgresg wbatre.

Dr.Ruud wrote:
> Toen ik moi kietelde, kwam er dit uit:

hihihi, je mag jezelf ook wel eens kietelen !

>>Dr.Ruud:

> Het was een voorbeeld van hoe je zoiets niet doet. Bij een charset
> waarin de 'F' of 'M' nul is, gaat het nog mis ook.
> 

Oeps. Slecht gelezen. Me Bad ...

> Het blijft altijd verstandig om zo te coderen dat 'M' niet aan
> sex wordt toegekend als sex al 'M' is; je weet immers niet of
> dat extra acties tot gevolg heeft, zoals een refresh van een
> window, of een update in een wereldwijd gerepliceerde database.
> 

[ wel gemeen om het opeens te compliceren ...]
Is een ander probleem. kwas er al vanuit gegaan, dat variabele
een temp/kopie was.

> Dat stond er al, zie het woord "onnodige".

Lezen is ook een kunst! sorry.

> 
>>>Ik legde het op aan beginnende C-programmeurs, dat scheelde een hoop

>>Nee, dat is een illusie. je *kan* ze niks uitleggen. 
> Er stond "opleggen".

Dat kan ook niet. om dezelfde reden ;-)

>>Variabelenamen om te HuiLen ....
> En dat was de bedoeling.

Humor niet gezien... dat is erg.
ehh: weel extra punten voor
detekteren van Slechte Smaak ?

>>>  for (i = 0; i++; i < uiLen) ...

>>Dit zijn tikfouten (of denkfouten) die ze moeten
>>leren herkennen. Als denkfout gaat het vanzelf over

> De tikfout zie ik even niet, maar ik ben ook best moe nu.
> 
> Of wacht, ik heb de test en de einde-loop-statement ver-
> wisseld. Ik bedoelde:
> 
>   for (i = 0; i < uiLen; i++) ...
> 
> en dat die i dan vanwege overflow naar negatief kan omklappen.

Dat kan niet. Ze zijn beiden signed.
[t kan wel, maar dan is het in wezen een initialisatie/variabele-range 
probleem]

>>BTW leuk draadje, waar ging het over, eigenlijk ?
> Iets van 10 eurocent per regel code, geloof ik.
> 

Shit! Teveel gesnipt...

Sorry voor mijn gebrek aan leesvaardigheid.
Iets teveel overgeslagen van het begin van het draadje,
en dus ook van het begin van de style-war.

AvK

Dr.Ruud wrote:

> Toen ik John Bokma kietelde, kwam er dit uit:
> 
>> Mijn C kennis is outdated, maar als een pointer naar geheugenadres 0
>> kan wijzen, en null kan zijn, dan geeft:
>>
>> if ( ptr ) {
>> } else {
>>     printf("ptr is een NULL pointer!");
>> }
>>
>> Toch die melding?
> 
> Ja. "if (!ptr)" kan ook. En "if (NULL == ptr)" natuurlijk.

Maar, bij die eerste, zijn NULL en 0 niet beide false?

>> if ( sex == 'F' ) { .... }
>>
>> Als geslacht is vrouwelijk ....
> 
> Als vrouwelijk het geslacht is.

C met Yoda blij is erg.


-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Dr.Ruud wrote:

> Toen ik John Bokma kietelde, kwam er dit uit:
> 
>> Wellicht ben ik een van de weinige die zijn editor op 8 of 9 punts
>> fontje heeft staan
> 
> Ik doe zo'n beetje alles in 8 punts Courier New: mail, news,
> coden.

9 of 8 hier, maar veel mensen vinden dat dus veeel te klein (17", 1280 x 
1024)

>> Komt er gelijk een nadeel van Windows boven: het window met de
>> focus wil bovenop.
> 
> En de focus overnemen, soms zelfs meerdere keren tijdens het opstarten.
> Echt heel erg is dat.

Aargh, ja dat is helemaal storend. Zeker als je aan het tikken ben. Ik heb 
ooit een chat gebruikt die private messages in een soort tabbed window 
deed, en de nieuwe prater kreeg de focus. Erg lekker als je met iemand aan 
het praten was, en je drukt return op het moment dat iemand anders de focus 
krijgt :-D.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

moi wrote:

> Dr.Ruud wrote:

>>>>     if (('F' == sex) || (('f' == sex) && (sex = 'F'))) do_female;
>>>>     else if (('M' == sex) || (sex = 'M')) do_male;
> 
> Mijn bezwaar hiertegen is, dat het veel-te-veel tokens zijn.
> Het *dwingt* de lezer om op de () te letten, zoals ook sommige
> construkties de lezer in de *illusie* brengen dat
> whitespace/indentering belangrijk is. Die belachelijke ('f' == gender)
> is *defensief*. 

Eens, een truuk om fouten op te vangen die je normaal met de compiler
hoort te zien. 

> Het voordeel van de switch is, dat ie makkelijk is, omdat iedereen
> hem onmiddelijk herkent. Bovendien *weet* iedereen dat er meer-dan 1 
> cases kunnen zijn (itt if/else, waarbij er altijd precies twee opties 
> zijn) Vandaar:
> switch(gender) {
> case 'm': gender = 'M';
> case 'M': do_gozert();
>    break;
> case 'f': gender = 'F';
> case 'F': do_wijffie();
>    break;
> default: do_teiltje("illegal gender: %x\n",  gender);
>      }
> 
> Iedere "getrainde" lezer zal hier een switch herkennen, zich
> realiseren dat fall-tru mogelijk is, en (wellicht bij tweede lezing)
> constateren dat dat ook daadwerkelijk (hopelijk) goed gebruikt wordt.
> IMHO kost de switch 2* zo weinig tijd *om te lezen* als de geneste 
> if-construktie. De rest van de tijd kan besteed worden aan begrijpen,
> wat 4* zo weinig tijd kost.

Bij langere zaken, in Perl, (maar ook in C hoor) gebruik ik een hash
table ipv. een lange switch. (Switch, Perl heeft geen switch, maar
gelukkig kan je op veel manieren er een maken, of je gebruikt de Switch
module :-) ). 

>> Je bent dan vast e1n van de velen die de "==" en "!=" niet echt als
>> symmetrische symbolen lezen. Ik zie veel liever een
>> if (NULL != lange-en-complexe-expressie)
>> dan andersom (en het liefst dus inclusief de onnodige "NULL !="),
>> want je weet meteen waarmee vergeleken wordt.
> 
> 
> Nee hoor. Ook hier kan je weer eea *weglaten*, waardoor de
> leesbaarheid verhoogd wordt: die "NULL !=" kan worden vervangen door
> "". Vergelijk:
> 
> while (NULL != (cp = fgets(fp, buff, sizeof buff))) {}
> 
> met:
> 
> while (cp = fgets(fp, buff, sizeof buff)) {}

Dit soort dingen kunnen fout gaan als cp zowel NULL als 0 kan worden,
vzviw. 

>>   unsigned int uiLen;
>>   int i;
> Variabelenamen om te HuiLen ....

Yup, Hungarian zou verboden moeten worden :-D.

> BTW leuk draadje, waar ging het over, eigenlijk ?

Iets met afvallen?

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Dr.Ruud wrote:

> Toen ik moi kietelde, kwam er dit uit:

[ ... ]

> Het blijft altijd verstandig om zo te coderen dat 'M' niet aan
> sex wordt toegekend als sex al 'M' is; je weet immers niet of
> dat extra acties tot gevolg heeft,

Natuurlijk *weet* je dat wel.

> zoals een refresh van een
> window, of een update in een wereldwijd gerepliceerde database.

Ik vind het altijd een zeer kwalijke zaak als men programmeerd op "het 
zou wel eens kunnen". Een ander voorbeeld:

i = 1;
while (1) {

    	... code die i *niet* aanpast;
    	i++;
    	if ( i > 10 ) break;
}

i kan niet groter dan 10 worden, dus waarom in hemelsnaam daar op 
testen? Ik zou dus i == 10 er van maken, want.. i > 10 zet mij aan het 
denken, waar wordt i nog meer aangepast.

Dus iets a la:

if ( var != 'M' ) var = 'M';

als gewoon

var = 'M';

volstaat, zou ik zeer zeker aanraden. (Is wellicht zelfs sneller, en 
bovenal minder ruis).

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Sjoerd A. Schreuder wrote:

[ 'foo' == ugly ]

> Ik ken het argument dat het bugs voorkomt, maar elke compiler
> geeft tegenwoordig wel een waarschuwing voor een assignment
> binnen een conditie. En iedereen heeft toch (bijna) alle
> warnings aan staan? (Ik weet het, dat is te optimistisch)

Maar eh, is het niet zo dat een beetje compiler gewoon een pragma heeft om 
warnings ff tijdelijk laag te zetten als je het nodig hebt?

(Ben te lang uit C, en Perl kan dat gewoon )

> Maar misschien is het een kwestie van gewenning. Ik ben in ieder
> geval totaal niet gewend om de literal voorop te zien staan.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

John Bokma wrote:
> moi wrote:

> 
> Eens, een truuk om fouten op te vangen die je normaal met de compiler
> hoort te zien. 
> 

Eens. eens. Ooit.
't is gewoon defensief. Net als overmaat () haakjes.

>>Het voordeel van de switch is, dat ie makkelijk is, omdat iedereen
>>hem onmiddelijk herkent. Bovendien *weet* iedereen dat er meer-dan 1 
>>cases kunnen zijn (itt if/else, waarbij er altijd precies twee opties 
>>zijn) 
> 
> Bij langere zaken, in Perl, (maar ook in C hoor) gebruik ik een hash
> table ipv. een lange switch. (Switch, Perl heeft geen switch, maar
> gelukkig kan je op veel manieren er een maken, of je gebruikt de Switch
> module :-) ). 
> 

Het eigenlijke onderwerp is "human readability", IMHO.
er is een continuum tussen ja/nee, multiple choice, en "open vragen".
Daartussen zijn allerlei gradaties mogelijk. Daarvoor moet de
schrijver verstandige keuzes maken. Belangrijk voor de keuze is het
overbrengen van de bedoeling.
in C is de keuze makkelijk: 1,2,veel.
veel is dus altijd lastig, dus switch(){} , dus lastig.

Er zijn twee soorten "veel": makkelijk_veel en moeilijk_veel.

Moeilijk_veel wil meestal zeggen dat de "switch" heel veel losliggende
cases kent ("sparse"), die dus ook nog in clusters optreden
(voorbeeld: [a-zA-Z] [0-9] [+-@_] [ \t] , etc. Of nog erger: 
instruktiesets!)
Er zijn twee strategieen: een extra laag van abstraktie
(isalnum() etc), of data_als_data_behandelen.

Voor dat laatste geval heeft perl (terecht) associatieve arrays,
die C programmeurs node moeten missen 8-)
[ik kan geen perl, trouwens, maar ik hoop, dat ik
-op een onbewoond eiland, met alleen maar de code, en heel veel tijd
om te lezen, de bedoeling van de programmeur, en ook nog
de wetten van perl zou kunnen doorgronden ]

>>
>>while (cp = fgets(fp, buff, sizeof buff)) {}
> 
> 
> Dit soort dingen kunnen fout gaan als cp zowel NULL als 0 kan worden,
> vzviw. 
> 

Hier moet ik je corrigeren: return type is char*.
Zelfs als het int zou zijn, zou de test syntacties valide zijn.
Indien geen prototype_in_scope zou de compiler moeten klagen.
[wederom  defensief, dus ...]


>>>  unsigned int uiLen;
>>>  int i;
>>
>>Variabelenamen om te HuiLen ....
> 
> 
> Yup, Hungarian zou verboden moeten worden :-D.

Bij nader inzien bleek het humor.
[meestal als je iets niet snapt is het kunst. Of humor!]
Hongaars is ook defensief, BTW...

>>BTW leuk draadje, waar ging het over, eigenlijk ?
> 
> 
> Iets met afvallen?
> 

Ik moet U hier afvallen ;-)

AvK

moi wrote:

> John Bokma wrote:
>> moi wrote:
> 
>> 
>> Eens, een truuk om fouten op te vangen die je normaal met de compiler
>> hoort te zien. 
> 
> Eens. eens. Ooit.
> 't is gewoon defensief. Net als overmaat () haakjes.

Ik ga voor leesbare code, dus overmaat aan haakjes gebruik ik niet. Soms
kan je door een expressie iets anders op te schrijven *en* duidelijk
maken hoe het berekend wordt, en haakjes besparen. 

En defensief programmeren: je bedoelt de compiler warnings bijna uit
zetten, en dan de rommel met truukjes opvangen? Liever niet. 

>> Bij langere zaken, in Perl, (maar ook in C hoor) gebruik ik een hash
>> table ipv. een lange switch. (Switch, Perl heeft geen switch, maar
>> gelukkig kan je op veel manieren er een maken, of je gebruikt de
>> Switch module :-) ). 
> 
> Het eigenlijke onderwerp is "human readability", IMHO.
> er is een continuum tussen ja/nee, multiple choice, en "open vragen".
> Daartussen zijn allerlei gradaties mogelijk. Daarvoor moet de
> schrijver verstandige keuzes maken. Belangrijk voor de keuze is het
> overbrengen van de bedoeling.
> in C is de keuze makkelijk: 1,2,veel.
> veel is dus altijd lastig, dus switch(){} , dus lastig.

Eh, dus switch? Welnee, hashtables zijn een prima optie. Of soms een
array. 

> Er zijn twee soorten "veel": makkelijk_veel en moeilijk_veel.
> 
> Moeilijk_veel wil meestal zeggen dat de "switch" heel veel losliggende
> cases kent ("sparse"), die dus ook nog in clusters optreden
> (voorbeeld: [a-zA-Z] [0-9] [+-@_] [ \t] , etc. Of nog erger: 
> instruktiesets!)
> Er zijn twee strategieen: een extra laag van abstraktie
> (isalnum() etc), of data_als_data_behandelen.

Als: array vullen met pointers naar functies?
 
> Voor dat laatste geval heeft perl (terecht) associatieve arrays,

Of een gewoon array. En daarnaast natuurlijk reguliere expressies.

> die C programmeurs node moeten missen 8-)

Een hash table schrijf je zo zelf, vaak genoeg gedaan in C :-D (De hash
functie is meestal het lastigste). 

> [ik kan geen perl, trouwens, maar ik hoop, dat ik
> -op een onbewoond eiland, met alleen maar de code, en heel veel tijd
> om te lezen, de bedoeling van de programmeur, en ook nog
> de wetten van perl zou kunnen doorgronden ]

De syntax van Perl is niet zo heel veel anders vergeleken met C. Alleen
heeft Perl wat extra dingen om de notatie te vereenvoudigen (reguliere
expressies b.v.). 

>>>while (cp = fgets(fp, buff, sizeof buff)) {}
>> 
>> Dit soort dingen kunnen fout gaan als cp zowel NULL als 0 kan worden,
>> vzviw. 
> 
> Hier moet ik je corrigeren: return type is char*.

En wat als die char * naar adres 0 wijst?

>> Yup, Hungarian zou verboden moeten worden :-D.
> 
> Bij nader inzien bleek het humor.
> [meestal als je iets niet snapt is het kunst. Of humor!]
> Hongaars is ook defensief, BTW...

Nee, het is een vreselijke notatie die niemand hopelijk meer gebruikt in
een nieuw project. 

>>>BTW leuk draadje, waar ging het over, eigenlijk ?
>> 
>> Iets met afvallen?
> 
> Ik moet U hier afvallen ;-)

Lijnen = afvallen :-D.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Toen ik John Bokma kietelde, kwam er dit uit:

>>> if ( ptr ) {
>>> } else {
>>>     printf("ptr is een NULL pointer!");
>>> }

>> "if (!ptr)" kan ook. En "if (NULL == ptr)" natuurlijk.

> Maar, bij die eerste, zijn NULL en 0 niet beide false?

Ik bedoelde:

  if (!ptr) printf("ptr is een NULL pointer!");

Die "!" is een logische NOT.

NULL en 0 zijn logisch false. NULL is in C bijvoorbeeld
gedefinieerd als 0L, ofwel (long) 0.
Zowel !NULL als !0 zijn dus logisch true.

Iets als "" (lege string) is in C true, het is immers
een pointer (naar een geheugenplek met daarin een 0-byte),
en die pointer (een getypeerd geheugenadres) heeft
(normaal gesproken) een waarde <> 0.

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

Toen ik John Bokma kietelde, kwam er dit uit:
> Dr.Ruud:

>> Het blijft altijd verstandig om zo te coderen dat 'M' niet aan
>> sex wordt toegekend als sex al 'M' is; je weet immers niet of
>> dat extra acties tot gevolg heeft,

> Natuurlijk *weet* je dat wel.

Dat ligt eraan hoe je zo'n stuk code opvat. "sex = 'M'"
is een toekenning, wat meestal simpelweg betekent dat een
geheugenplaats een andere waarde krijgt. Maar er zijn
talloze omstandigheden waarin op 'schrijven' een dusdanige
'straf' staat, dat je het met alle macht probeert te
vermijden.


>> zoals een refresh van een
>> window, of een update in een wereldwijd gerepliceerde database.
>
> Ik vind het altijd een zeer kwalijke zaak als men programmeerd op
> "het zou wel eens kunnen".

Als het niet meer moeite kost om er wel rekening mee te houden,
dan doe ik dat toch graag. Het gaat dan om vrij algemene code
die in meerdere omgevingen onaangepast bruikbaar is. En met die
switch{} lukt dat heel aardig.


> Een ander voorbeeld:
>
> i = 1;
> while (1) {
>
>     ... code die i *niet* aanpast;
>     i++;
>     if ( i > 10 ) break;
> }
>
> i kan niet groter dan 10 worden, dus waarom in hemelsnaam daar op
> testen? Ik zou dus i == 10 er van maken, want.. i > 10 zet mij aan het
> denken, waar wordt i nog meer aangepast.

Dat wordt inderdaad vaak zo wordt gecodeerd. Een for-loop is daar
natuurlijk meer op zijn plaats, maar dat is niet wat je aan wilt
geven. Eigenlijk zou je een 'assert(i<10)' voor de i++ moeten
zetten, en dan daarna inderdaad 'if (i == 10)' gebruiken.

Tout-le-monde codeert: for (i=0; i < 10; i++)
en bijna niemand:      for (i=0; i != 10; assert(i<10), i++)
(of een betere versie daarvan, ik heb er niet echt over nagedacht)
en dat is inderdaad best wel vreemd.


> Dus iets a la:
>   if ( var != 'M' ) var = 'M';
> als gewoon
>   var = 'M';
> volstaat, zou ik zeer zeker aanraden. (Is wellicht zelfs sneller,
> en bovenal minder ruis).

Als het volstaat, dan OK. Maar als er side-effects zijn, dan wordt
het anders. Dat er bijvoorbeeld een dirty-flag wordt gezet, of een
oldvalue-property aangepast wordt, etc.

In C zou je daar een define van kunnen maken, met in de ene
omgeving dit:
  #define SET( var, value ) (if ((var) != (value)) {(var) = (value);})
en in de andere dit:
  #define SET( var, value ) ((var) = (value))
al zijn die niet echt evenwaardig, denk aan "if (SET(a,10))".

En in C++ heb je ook nog operator-overloading.

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

Dr.Ruud wrote:

> Toen ik John Bokma kietelde, kwam er dit uit:
> 
>>>> if ( ptr ) {
>>>> } else {
>>>>     printf("ptr is een NULL pointer!");
>>>> }
> 
>>> "if (!ptr)" kan ook. En "if (NULL == ptr)" natuurlijk.
> 
>> Maar, bij die eerste, zijn NULL en 0 niet beide false?
> 
> Ik bedoelde:
> 
>   if (!ptr) printf("ptr is een NULL pointer!");
> 
> Die "!" is een logische NOT.
> 
> NULL en 0 zijn logisch false. NULL is in C bijvoorbeeld
> gedefinieerd als 0L, ofwel (long) 0.
> Zowel !NULL als !0 zijn dus logisch true.

Precies wat ik dus bedoelde, en dus is het *soms* gevaarlijk om zomaar:

if ( !ptr ) ... te gebruiken.

Even terug naar mijn Perl voorbeeldje:

$filename ||= 'default.txt';

geeft dus een probleem als je een bestand 0 wilt noemen.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Toen ik moi kietelde, kwam er dit uit:
> Dr.Ruud:

>> Het blijft altijd verstandig om zo te coderen dat 'M' niet aan
>> sex wordt toegekend als sex al 'M' is; je weet immers niet of
>> dat extra acties tot gevolg heeft, zoals een refresh van een
>> window, of een update in een wereldwijd gerepliceerde database.

> [ wel gemeen om het opeens te compliceren ...]

Zeker, en je kunt (en mag) niet met alles rekening houden. Maar ik
vind het wel prettig om er toch rekening mee te houden.

Jouw switch-versie is trouwens gewoon 'goed' hoor (hij vermijdt het
zetten van gender als die al 'M' is).


> ehh: weel extra punten voor
> detekteren van Slechte Smaak ?

Ongetwijfeld. :)


>>   for (i = 0; i < uiLen; i++) ...
>>
>> en dat die i dan vanwege overflow naar negatief kan omklappen.
>
> Dat kan niet. Ze zijn beiden signed.

Nee toch? Ik had die ui juist expres unsigned gemaakt.

-- 
Affijn, Ruud   `  -  �
               + ` � *
                 � `     Jvr qvg yrrfg,
               �  =  `   fgresg wbatre.

Toen ik John Bokma kietelde, kwam er dit uit:

> dus is het *soms* gevaarlijk om zomaar:
>
>   if ( !ptr ) ... te gebruiken.

Die redenering begrijp ik niet. In C is !ptr heel eenduidig
(als er geen geniepige redefine van 'ptr' meespeelt).

Ik nam aan dat je met ptr een variabele van een
integer type beDoelt, specifiek beDoeld en geschikt
voor het bevatten van een geheugenadres. In C.
Maar misschien bedoelde je het wel heel anders.

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

Dr.Ruud wrote:
> Toen ik moi kietelde, kwam er dit uit:
> 

>>[ wel gemeen om het opeens te compliceren ...]
> 
> 
> Zeker, en je kunt (en mag) niet met alles rekening houden. Maar ik
> vind het wel prettig om er toch rekening mee te houden.

Dat vind ik weer een vorm van *defensief*. Als eea in de toekomst gaat
veranderen, dan zal men tzt zowiezo moeten bezien of de code nog wel
opgaat in de nieuwe situatie. Daarbij komt nog, dat de nieuwe 
randvoorwaarden in het heden wellicht niet getest kunnen/zullen worden.

Trouwens, ook hier: de compiler is je vriend:
const char *gender;
doet wonderen!


> 
>>>  for (i = 0; i < uiLen; i++) ...
>>>
>>>en dat die i dan vanwege overflow naar negatief kan omklappen.
>>
>>Dat kan niet. Ze zijn beiden signed.
> 
> 
> Nee toch? Ik had die ui juist expres unsigned gemaakt.
> 

Oeps. Niet alleen de definities genegeerd en gesnipt,
maar ook nog onvoldoende begrip van de Hongaarse Taal ;-[
I stand corrected!

AvK

John Bokma wrote:
> moi wrote: 
>>'t is gewoon defensief. Net als overmaat () haakjes.
> 
> 
> En defensief programmeren: je bedoelt de compiler warnings bijna uit
> zetten, en dan de rommel met truukjes opvangen? Liever niet. 
> 

Nee, juist andersom: testen van condities die niet voor (mogen/kunnen) 
komen. Wegens: je weet maar nooit, tkan geen kwaad. Levert allemaal ruis 
op ("visual clutter").
(jullie "if (++i > 10) break;" is ook zon voorbeeld)
Ook een slecht voorbeeld:
char * cp = (char*) malloc(100);


>>>Bij langere zaken, in Perl, (maar ook in C hoor) gebruik ik een hash
>>>table ipv. een lange switch. (Switch, Perl heeft geen switch, maar



> Eh, dus switch? Welnee, hashtables zijn een prima optie. Of soms een
> array. 
> 
IMO allebei een vorm van "data als data behandelen"

>
>>Er zijn twee strategieen: een extra laag van abstraktie
>>(isalnum() etc), of data_als_data_behandelen.
> 
> 
> Als: array vullen met pointers naar functies?
Niet perse. Als "het vlees" in de switch-cases heel erg variabel is,
is dat wel de meest flexibele methode. (en met inline functies is er 
geen verschil tov een dikke wollige switch)

>>Voor dat laatste geval heeft perl (terecht) associatieve arrays,
> Of een gewoon array. En daarnaast natuurlijk reguliere expressies.
>>die C programmeurs node moeten missen 8-)
Is hetzelfde, alleen bij perl moet je minder zelf bouwen, vzv ik weet.

> Een hash table schrijf je zo zelf, vaak genoeg gedaan in C :-D (De hash
> functie is meestal het lastigste). 

Leuke tak van sport. Bij "fixed domains" (zoals bij switch()) is er 
zelfs een "perfect hash" mogelijk. Is nog een GNU programmaatje voor, IIRC.


>>[ik kan geen perl, trouwens, maar ik hoop, dat ik
>>-op een onbewoond eiland, met alleen maar de code, en heel veel tijd
>>om te lezen, de bedoeling van de programmeur, en ook nog
>>de wetten van perl zou kunnen doorgronden ]
> 
> 
> De syntax van Perl is niet zo heel veel anders vergeleken met C. Alleen
> heeft Perl wat extra dingen om de notatie te vereenvoudigen (reguliere
> expressies b.v.). 

Ja, als je C+awk+sed+sh kent, kan je het bijna lezen!
(running gag van Larry Wall is om bij iedere nieuwe versie
een nieuwe betekenis van ':' te bedenken: "everybody wants the colon!" :-)

>>>>while (cp = fgets(fp, buff, sizeof buff)) {}
>>>
>>>Dit soort dingen kunnen fout gaan als cp zowel NULL als 0 kan worden,
>>>vzviw. 
>>
>>Hier moet ik je corrigeren: return type is char*.
> 
> 
> En wat als die char * naar adres 0 wijst?
> 

Dan wordt er een NULL aan cp geassigneerd (cp=NULL; dus).
NULL is een valide waarde voor een pointer, je mag hem alleen niet 
derefereren.

>>>Yup, Hungarian zou verboden moeten worden :-D.
>
>>Hongaars is ook defensief, BTW...
> 
> Nee, het is een vreselijke notatie die niemand hopelijk meer gebruikt in
> een nieuw project. 

Hongaars is gebaseerd op angst.
Strong typing + vertrouwen op compilerwarnings geeft meer gemoedsrust.

>>>>BTW leuk draadje, waar ging het over, eigenlijk ?
>>>
>>>Iets met afvallen?
>>
>>Ik moet U hier afvallen ;-)
> 
> 
> Lijnen = afvallen :-D.
> 

Is dat de regel ?

NB er was een backslash weggevallen in de "find . -name \*.java|wc -l"
Anders gaat ie globben.

AvK

Toen ik moi kietelde, kwam er dit uit:

> de compiler is je vriend:
> const char *gender;
> doet wonderen!

Goed dat je die opnoemt, hoef ik er
niet meer over te beginnen.

Nou moest die gender wel te veranderen zijn,
en was het geen char-pointer...

-- 
Affijn, Ruud   `  -  �
               + ` � *
                 � `     Jvr qvg yrrfg,
               �  =  `   fgresg wbatre.

John Bokma wrote:
> Dus iets a la:
> 
> if ( var != 'M' ) var = 'M';
> 
> als gewoon
> 
> var = 'M';
> 
> volstaat, zou ik zeer zeker aanraden. (Is wellicht zelfs sneller, en 
> bovenal minder ruis).

Ik zou die extra test afraden. De extra read van var is erg
kostbaar (veel klok-cycli) als var niet in een register zit.
(De write is veel minder kostbaar: die gebeurt gewoon op de
achtergrond terwijl de volgende instructies worden uitgevoerd)
Verder is altijd een write doen veel beter te paralleliseren dan
een read en een write naar hetzelfde adres vlak na elkaar,
omdat daarmee mogelijkheden tot reordening worden beperkt.
Om over de branch-prediction (en de kosten als die fout gebeurt)
die de if introduceert maar niet te spreken.

Dus ik denk dat op een moderne processor, de test-versie veel
trager is dan de write-always versie.

Als var een propertie of zo is, en je bang bent voor onnodig
neveneffecten als gevolg van het setten, dan moet je in de
set-functie maar iets als:
void setFoo(char new_value)
   if (m_gender != new_value)
   {
      m_gender = new_value;
      NotifyListeners();
   }
opnemen. In Delphi zie je dat ook overal gebeuren.

Sjoerd

Johan Wevers wrote:
> Dr.Ruud <rvtol+news@isolution.nl> wrote:
> 
>>NULL en 0 zijn logisch false. NULL is in C bijvoorbeeld
>>gedefinieerd als 0L, ofwel (long) 0.
> 
> Sinds wanneer niet meer als (void*)0 ?

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.

In plaats van een uitzondering voor (void*)0 te maken, is
er in C++ een uitzondering voor 0 (beter: elke compile-time
expressie met als resultaat 0) gemaakt.

Dus om de ene uitzondering niet te hoeven maken, is er een
andere uitzondering gemaakt. Tja, over hoe logisch dat is
valt te twisten, maar feit is dat in C++ NULL niet (void*)0
kan zijn.

Dat gezegd hebbend, het zou natuurlijk best mogelijk zijn
geweest om:
#ifndef NULL
#  ifdef __cplusplus
#    define NULL (0)
#  else
#    define NULL ((void*)0)
#  endif
#endif
op te nemen. En dan zouden C en C++ dus een verschillende NULL
hebben gehad.

Maar ik ken de C standaard niet zo goed; C++ ken ik een stuk
beter. Gelukkig heeft 'moi' daar al wat over gepost.

Overigens zijn er voorstellen om in de volgende C++ standaard
(2009 of zo) een 'nullptr' op te nemen om van de NULL af te zijn.
Dat is handig in de volgende situatie:

void foo(long);
void foo(void*);

int main()
{
   foo(NULL); // roept foo(long) aan
}

Bottomline: dit soort details zorgt ervoor dat C en C++ toch als
verschillende programmeertalen moeten worden gezien.

Sjoerd

Sjoerd A. Schreuder wrote:

> Ik ken C op dit gebied minder goed dan C++, maar in C++ wordt een zero
> omgezet in een pointer die als NULL pointer dient (C vereist dacht ik
> wel gewoon een zero, maar dat weet ik niet zeker). De C++ standaard
> doet zijn best om niet te zeggen dat dat adres 0 is en de optie open
> te laten daar b.v. 0xFFFFFFFF van te maken. Maar elke compiler die ik
> ken, representeert een NULL pointer door een pointer naar adres 0,
> en ik ken een heleboel code die fout zou gaan als dat niet het geval
> zou zijn (code die memset(), memzero() en zo gebruikt om een pointer
> te initialiseren). Maar een compiler mag dat dus anders doen!

Ja, ook dat kan ik mij herinneren, en ik herinner dat toen ik nogal veel 
C programmeerde ik altijd dingen deed als

if ( ptr == NULL ) { ... } etc.

Ik vind het ook leesbaarder (ik deed veel dingen met trees, graphs, en 
linked lists, en dan kan je het zelfs documentatie noemen :-D.

>> Zie boven. Ik bedoel dat ptr twee false waarden kan hebben. Indien
>> niet, dan gaat dat deel van mijn verhaal niet op.
> 
> Er is maar 1 false waarde (nl NULL), maar i.h.a. wordt de pointer
> naar adres 0 opgeofferd om die NULL waarde te representeren.

Ah, dus NULL is altijd "0", maar kan intern door de compiler anders 
gerepresenteerd worden. Dus intern kan die 0 0xffffffff zijn?

> Overigens is het best mogelijk om zo'n pointer te gebruiken in C.
> Je zult dan het geheugen op adres 0 proberen te benaderen, en als
> dat precies is wat je wilt (in een embedded device of zo),

Of in een systeem waar dat geen kwaad kan :-D.

>> Ander voorbeeld:
>> 
>> $speed ||= 5;         # use default
>> 
>> Probeer $speed nu maar eens op 0 te zetten.
> 
> Misschien is dat ook wel niet handig (maar dan zou ik if (speed < 1)
> o.i.d. verwachten).

Het komt nogal eens voor dat een programmeur er in stinkt. Ikzelf 
gebruik meestal iets als:

defined $speed or $speed = 5;

Ik lees dat zelf als: speed moet gedefinieerd zijn, of anders zet 'm op 
5.


-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

John Bokma <postmaster@castleamber.com> wrote:

>> en optimalisatie (de assignment binnen de if).
>Optimalisatie van wat?

Van de executietijd/aantal instructies als de assignment anders toch zou
moeten worden uitgevoerd.

>Pfft, dat is toch overduidelijk. Om je warning nivo van je compiler op 
>maximaal te kunnen zetten,

Tegenwoordig zeuren sommige compilers te snel IMO. Zeker nu er dankzij de
.net doctrine opeens een hoop handige dingen "deprecated" zijn.

Gelukkig heeft met dat bij Borland ook ingezien en kun je compiler
warnings selectief uitzetten voor een heel project. Wordt zelfs bij
je projectinstellingen opgeslagen. Ik heb geen zin om mijn code te
verzieken met pragma's omdat een of andere fundamentalist bedacht heeft
dat een bepaalde constructie opeens niet meer zou mogen.

-- 
ir. J.C.A. Wevers         //  Physics and science fiction site:
johanw@vulcan.xs4all.nl   //  http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

>It has never been wise to use NULL in place of an arbitrary pointer as a
>function argument, however, since pointers to different types need not be
>the same size.

Volgens mij moet je wel heel exotische hardware hebben wil dat zich
voordoen. Ook in de embedded wereld heb ik het nog nooit gezien. Ik
heb de indruk dat hardware waar dit zich voordoet het soort is waar
ik niet mee werk omdat ik geen COBOL beheers.

-- 
ir. J.C.A. Wevers         //  Physics and science fiction site:
johanw@vulcan.xs4all.nl   //  http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

John Bokma <postmaster@castleamber.com> wrote:

>Ah, dus NULL is altijd "0", maar kan intern door de compiler anders 
>gerepresenteerd worden. Dus intern kan die 0 0xffffffff zijn?

Dat is niet verboden door de standaard. Ik heb nog nooit gehoord dat het
ooit voorgekomen is.

-- 
ir. J.C.A. Wevers         //  Physics and science fiction site:
johanw@vulcan.xs4all.nl   //  http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

Sjoerd A. Schreuder <sa_schreuder@wanadoo.nl> wrote:

>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.

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).

>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.

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.

-- 
ir. J.C.A. Wevers         //  Physics and science fiction site:
johanw@vulcan.xs4all.nl   //  http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

John Bokma <postmaster@castleamber.com> wrote:

>> Bovendien wil ik m'n code ook graag in
>> textmode editen. Dus 80x25.
>
>Eh, full screen in vi? Brrr, dat zijn koeie letters voor mij.

Ik heb dan ook nog een 15" scherm hier (maximale resolutie 1024x768).

>> In Delphi (en CBuilder) kun je losse applicaties inpluggen in de IDE.
>Als het daarmee een onderdeel wordt van de IDE, nee.

Dat niet, je kunt ze vanuit de IDE aanroepen. Met een editor heb ik dat nog
nooit gedaan, wel met versiebeheer tools (RCS).

>Dat als ik van venster A een deel wil zien, en venster B (van een andere 
>applicatie alles, dat zodra ik iets in A doe, er een stuk van B 
>afgegeten wordt. Stom vervelend. Als je een tijdje met RISC OS of X 
>gewerkt hebt, dan snap je wat er fijn is aan niet naar voren springen.

Is dat zoiets als de focus in het windows waar de muispointer is? Ik wist
niet hoe gauw ik daar vanaf moest komen onder X. Misschien is zoiets een
kwestie van gewenning.

Maar goed, ik gebruik momenteel fvwm95 als windowmanager onder X, die heeft
dat gelukkig niet. Iets als Gnome en KDE hoeven van mij niet zo, als ik
zoiets wil kan ik ook rebooten naar windows.

-- 
ir. J.C.A. Wevers         //  Physics and science fiction site:
johanw@vulcan.xs4all.nl   //  http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

In nl.comp.programmeren,
Johan Wevers <johanw@vulcan.xs4all.nl> wrote:
>Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>
>>It has never been wise to use NULL in place of an arbitrary pointer as a
>>function argument, however, since pointers to different types need not be
>>the same size.
>
>Volgens mij moet je wel heel exotische hardware hebben wil dat zich
>voordoen. Ook in de embedded wereld heb ik het nog nooit gezien. Ik
>heb de indruk dat hardware waar dit zich voordoet het soort is waar
>ik niet mee werk omdat ik geen COBOL beheers.
>
Tja, een standaard wil ook exotische hardware niet bij voorbaat
uitsluiten. ;-)

Maar is een 8051 zo exotisch dan? Met de SDCC (maar volgens mij ook
Keil IAR) compiler kun je aangeven of een pointer specifiek naar een
bepaald soort geheugen (ram, xram, code) wijst of dat je een generieke
pointer wil. Die laatste is 24-bit i.p.v. 16 omdat er een extra byte
in zit die het soort geheugen bijhoudt. Is wel geen verschillende
pointergrootte afhankelijk van type maar wel van locatie.

Overigens gaf een grep op NULL in de SDCC header files geen resultaat,
zal wel geen toeval zijn.

Ik kan me ook voorstellen dat compilers voor AVR en andere harvard
architectuur processoren dergelijke truuken gebruiken. Dus weer
verschillende pointers per soort geheugen.

Of de aloude far/near pointers op de x86. Geen idee of daar het
meegeven van NULL een probleem zou zijn.

Verschillende pointergrootten voor verschillende typen variabelen ben
ik ook nog niet tegengekomen. Maar wat niet is kan nog komen. Zo schijn
je mainframes te hebben met 36-bit woorden waar 6 6-bit chars in een
woord gepacked worden, terwijl het geheugen alleen per word
adresseerbaar is. Zal ook wel interessante pointers geven. Maar daar
zal je idd wel veel in COBOL op doen. ;-)


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

There will be big changes for you but you will be happy.

Johan Wevers wrote:

> John Bokma <postmaster@castleamber.com> wrote:
> 
>>> en optimalisatie (de assignment binnen de if).
>>Optimalisatie van wat?
> 
> Van de executietijd/aantal instructies als de assignment anders toch
> zou moeten worden uitgevoerd.

De vraag is, wat is sneller:

sex = 'M';

of

if ( sex != 'M' ) sex = 'M';

Uit mijn ARM assembly tijd weet ik dat ik de 1e in 1 instructie kan
doen, en de 2e altijd 2 instructies kost (1 test, en een conditionele
MOV) 

Maar... als je zo C programmeerd ben je of met iets heel specifieks
bezig waar het *noodzaak* is, of je bent aan het knoeien. 

>>Pfft, dat is toch overduidelijk. Om je warning nivo van je compiler op
>>maximaal te kunnen zetten,
> 
> Tegenwoordig zeuren sommige compilers te snel IMO. Zeker nu er dankzij
> de .net doctrine opeens een hoop handige dingen "deprecated" zijn.
> 
> Gelukkig heeft met dat bij Borland ook ingezien en kun je compiler
> warnings selectief uitzetten voor een heel project. Wordt zelfs bij
> je projectinstellingen opgeslagen. Ik heb geen zin om mijn code te
> verzieken met pragma's omdat een of andere fundamentalist bedacht
> heeft dat een bepaalde constructie opeens niet meer zou mogen.

Gelukkig geen last van dat soort wilde gedachten :-D.

In Sri Lanka, tijdens het snorkelen dacht ik: Go with the Flow, en dat
is soms een goed ding ;-) 

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Johan Wevers wrote:

> John Bokma <postmaster@castleamber.com> wrote:
> 
>>> Bovendien wil ik m'n code ook graag in
>>> textmode editen. Dus 80x25.
>>
>>Eh, full screen in vi? Brrr, dat zijn koeie letters voor mij.
> 
> Ik heb dan ook nog een 15" scherm hier (maximale resolutie 1024x768).

Aargh, waarom zit je jezelf zo in de weg?

>>> In Delphi (en CBuilder) kun je losse applicaties inpluggen in de
>>> IDE. 
>>Als het daarmee een onderdeel wordt van de IDE, nee.
> 
> Dat niet, je kunt ze vanuit de IDE aanroepen. Met een editor heb ik
> dat nog nooit gedaan, wel met versiebeheer tools (RCS).

Ah, ok. Ik heb nu in mijn editor (Textpad) wat Tools aangemaakt voor 
versiebeheer (subversion). Dat gebruik ik soms. TortoiseSVN (subversion 
interface, hangt zichzelf in de explorer) maakt het meestal overbodig.

>>Dat als ik van venster A een deel wil zien, en venster B (van een
>>andere applicatie alles, dat zodra ik iets in A doe, er een stuk van B
>>afgegeten wordt. Stom vervelend. Als je een tijdje met RISC OS of X 
>>gewerkt hebt, dan snap je wat er fijn is aan niet naar voren springen.
> 
> Is dat zoiets als de focus in het windows waar de muispointer is?

Nee, dat zijn twee verschillende zaken. Voorbeeldje, ik heb een grote 
foto, en wil in mijn editor een stukje tikken wat er op die foto te zien 
is. Ik vind het dan handig dat ik die foto over mijn editor venster heen 
kan gooien, en alleen de onderste, pak m beet, 10 regels kan zien, en 
vervolgens in die editor kan tikken zonder dat het hele venster voor de 
venster met de foto springt. Op Windows ontkom je vzviw niet er aan om 
je editor venster erg klein te maken en *onder* de foto te hangen.

> Ik
> wist niet hoe gauw ik daar vanaf moest komen onder X. Misschien is
> zoiets een kwestie van gewenning.

Inderdaad, ik heb altijd met focus follows mouse gewerkt, maar op 
Windows is dat erg lastig omdat de vensterordening gewijzigt wordt als 
je rond rijdt.

> Maar goed, ik gebruik momenteel fvwm95 als windowmanager onder X, die
> heeft dat gelukkig niet. Iets als Gnome en KDE hoeven van mij niet zo,

Daar is het uit te zetten, erger, KDE volgt vzviw op nogal wat systemen 
Windows gedrag, inclusief het erg storende window met focus on top.

> als ik zoiets wil kan ik ook rebooten naar windows.

Vandaar dat ik nog steeds veel met Windows werk ;-) 

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

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.

Dat van de typechecking is ook niet waar, althans voor ANSII-C.
( signed als default type vooral voor char zal wel het enige verschil 
kunnen zijn, maar ik ken geen C++)

> 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).
> 
> 
>>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.

> 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.

AvK

Stef wrote:


> Of de final draft van de C99 standaard (n897):
> 
> NULL can be defined as any null pointer constant. Thus existing code can
> retain definitions of NULL as 0 or 0L, but an implementation may also
> choose to define it as (void*)0. This latter form of definition is
> convenient on architectures where sizeof(void*) does not equal the size
> of any integer type. It has never been wise to use NULL in place of an
> arbitrary pointer as a function argument, however, since pointers to
> different types need not be the same size.
> 
> 

Maar ik heb het idee dat het hier om een "implementation notes" sectie 
gaat. de gebruiker (programmeur, jij && ik dus) hoeven daar in principe 
niks mee te maken te hebben.
Mbt NULL als functie argument lijkt er mij niets aan de hand, zolang er 
een valide prototype "in scope" is. Lijkt mij.

AvK

Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

>Maar is een 8051 zo exotisch dan?

Ik ken hem niet, maar dat zegt natuurlijk niet zoveel. Waar wordt dat
gebruikt?

>Of de aloude far/near pointers op de x86. Geen idee of daar het
>meegeven van NULL een probleem zou zijn.

Blurk. Ben ik even blij dat ik in de win3.x tijd nog gewoon met DOS
en OS/2 werkte. :-)

>je mainframes te hebben met 36-bit woorden waar 6 6-bit chars in een
>woord gepacked worden, terwijl het geheugen alleen per word
>adresseerbaar is. Zal ook wel interessante pointers geven. Maar daar
>zal je idd wel veel in COBOL op doen. ;-)

Dit voorbeeld wordt geregeld aangehaald als het gaat om verschillende
grootte tussen functiepointers en gewone pointers. Maar ik noem zoiets
inderdaad exotishe hardware.

-- 
ir. J.C.A. Wevers         //  Physics and science fiction site:
johanw@vulcan.xs4all.nl   //  http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

Johan Wevers wrote:
> Sjoerd A. Schreuder <sa_schreuder@wanadoo.nl> wrote:
> 
> 
>>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.
> 
> 
> 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).

Met expliciet casten kun je alles. Met een reinterpret_cast<>
kun je knollen in citroenen omzetten.

Zonder cast kan een void* niet naar een foo* worden omgezet.
Omgekeerd, foo* naar void* kan wel zonder cast.

[hier heb je teveel geknipt waardoor het lijkt alsof de 'dat' uit
  onderstaande zin op bovenstaande slaat.]
>>Dat is handig in de volgende situatie:

[de 'dat' slaat op een eventuele 'nullptr' keyword voor een volgende
C++ versie]

>>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. :-(

Eh? de C++ standaard is vrij duidelijk: het hangt niet van
de compilerversie af. De foo(long) wordt altijd aangeroepen.

Daarnaast: het zou eigenlijk niet moeten uitmaken welke versie
je pakt want ze doen toch hetzelfde. Als de functies verschillende
dingen doen, moet je ze andere namen geven.

>>Bottomline: dit soort details zorgt ervoor dat C en C++ toch als
>>verschillende programmeertalen moeten worden gezien.
> 
> 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.

De C ontwerpers zijn dus ook niet zonder zonde: In gevallen waarin
C++ al voor een oplossing had gekozen voordat de C mensen erover gingen
praten, wisten ze regelmatig een nieuwe oplossing te vinden. Dit alles
lijkt onder het mom "het kan ons geen moer schelen hoe C++ het doet,
dit is voor C het handigst" te gebeuren. Bij C++ geldt in ieder geval
nog: "as close to C as possible, but no closer".

Maar gelukkig zijn de verschillen klein en wordt er wel geprobeerd
om ze klein te houden. Maar helemaal weg zullen de verschillen nooit
gaan.

En zoals gezegd: dit verschil in type van NULL is in de praktijk
nauwelijks te merken.

Sjoerd

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

Johan Wevers wrote:
> Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>>je mainframes te hebben met 36-bit woorden waar 6 6-bit chars in een
>>woord gepacked worden, terwijl het geheugen alleen per word
>>adresseerbaar is. Zal ook wel interessante pointers geven. Maar daar
>>zal je idd wel veel in COBOL op doen. ;-)
> 
> Dit voorbeeld wordt geregeld aangehaald als het gaat om verschillende
> grootte tussen functiepointers en gewone pointers. Maar ik noem zoiets
> inderdaad exotishe hardware.

C++ staat zelfs toe dat een (char*) een andere aantal bits heeft
dan een (int*). Een (void*) moet groot genoeg zijn om elk type pointer
op te kunnen slaan.

Functiepointers vallen hier inderdaad totaal buiten. Die mogen meer bits
gebruiken dan een (void*), omdat C++ niet garandeert dat je een
functiepointer naar een (void*) kan omzetten.

Sjoerd

Johan Wevers wrote:

> Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
> 
>>Maar is een 8051 zo exotisch dan?
> 
> Ik ken hem niet, maar dat zegt natuurlijk niet zoveel. Waar wordt dat
> gebruikt?

Menig elektuurproject uit de goede oude tijd :-D.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

In nl.comp.programmeren,
Johan Wevers <johanw@vulcan.xs4all.nl> wrote:
>Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>
>>Maar is een 8051 zo exotisch dan?
>
>Ik ken hem niet, maar dat zegt natuurlijk niet zoveel. Waar wordt dat
>gebruikt?
>
Al een jaar of 30 een van de meest gebruikte 8-bit microcontrollers.
En die kun je dus overal tegenkomen. Tegenwoordig verkrijgbaar in
honderden derivaten van tientallen fabrikanten.

>>Of de aloude far/near pointers op de x86. Geen idee of daar het
>>meegeven van NULL een probleem zou zijn.
>
>Blurk. Ben ik even blij dat ik in de win3.x tijd nog gewoon met DOS
>en OS/2 werkte. :-)
>
Ook in DOS heb je daar last van. Altijd als je in real-mode meer dan
64K geheugen wilt gebruiken.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

All people are born alike -- except Republicans and Democrats.
		-- Groucho Marx

In nl.comp.programmeren,
Sjoerd A. Schreuder <sa_schreuder@wanadoo.nl> wrote:
>
>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.
>
Ja, de cast is in C niet noodzakelijk en wordt o.h.a. afgeraden.
Belangrijkste argument is dat een vergeten "#include <stdlib.h>" met de
cast geen foutmelding geeft en zonder de cast juist wel. Doorzoek anders
comp.lang.c eens op "never cast the return value of malloc".

>Als mijn aanname over C juist is, dan zit er dus wel degelijk een
>groot verschil tussen C en C++ op dit punt.
>
Klopt en C++ code zit dan ook vol met die ergerlijke casts. En ook C
code die door een C++ compiler gehaald wordt.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

	A farm in the country side had several turkeys, it was known as the
house of seven gobbles.

Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

>Ook in DOS heb je daar last van. Altijd als je in real-mode meer dan
>64K geheugen wilt gebruiken.

In die tijd schreef ik nog programma's die wel binnen die 64kb bleven.
Dat was bij m'n afstuderen, het traagste was nog een stel geneste loops,
maar als ik haast had kon ik die soms draaien op het paradepaardje van de
afdeling: een gloednieuwe supersnelle 486DX2-50. Dat was in 1993.

-- 
ir. J.C.A. Wevers         //  Physics and science fiction site:
johanw@vulcan.xs4all.nl   //  http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

Sjoerd A. Schreuder <sa_schreuder@wanadoo.nl> wrote:

>Daarnaast: het zou eigenlijk niet moeten uitmaken welke versie
>je pakt want ze doen toch hetzelfde. Als de functies verschillende
>dingen doen, moet je ze andere namen geven.

Maar dat is niet iets wat een compiler kan beoordelen en dus warnings op kan
geven (tenzij dat door e.o.a. ook weer als "deprecated" wordt aangemerkt).

>De C ontwerpers zijn dus ook niet zonder zonde: In gevallen waarin
>C++ al voor een oplossing had gekozen voordat de C mensen erover gingen
>praten, wisten ze regelmatig een nieuwe oplossing te vinden.

Misschien bij C99, maar ik weet niet of dat nu zoveel gebruikt wordt. De C
uit K&R2, die bij mijn weten nog het meest gebruikt wordt, bestond in elk
geval al voordat C++ enigzins uitgekristaliseerd was (was Stroustrup in
1988 eigenlijk uberhaupt al met C++ begonnen?).

>Maar gelukkig zijn de verschillen klein en wordt er wel geprobeerd
>om ze klein te houden.

Dat zou je niet zeggen nadat die onzin met include files aangepast was, en
dat het opeens deprecated is om stdio.h te gebruiken die nu cstdio moet
heten. Gelukkig is dat niet dwingend opgelegd.

>En zoals gezegd: dit verschil in type van NULL is in de praktijk
>nauwelijks te merken.

Nou, als NULL als long geinterpreteerd wordt in overloaded functies toch
echt wel. Jouw voorbeeld ziet er bepaald niet ingewikkeld of kunstmatig
uit.

-- 
ir. J.C.A. Wevers         //  Physics and science fiction site:
johanw@vulcan.xs4all.nl   //  http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

In nl.comp.programmeren, Johan Wevers wrote:
>>> en optimalisatie (de assignment binnen de if).
>>Optimalisatie van wat?
>
> Van de executietijd/aantal instructies als de assignment anders toch zou
> moeten worden uitgevoerd.

Pas heel erg op dat je geen micro-optimalisaties doet die de
leesbaarheid in het geding brengen.

Optimalisaties die enkele instructies schelen moet je alleen doen in
inner loops die heel erg vaak worden uitgevoerd.  Anders maak je de
verkeerde afweging.


Jan

Toen ik Jan de Vos kietelde, kwam er dit uit:

> Optimalisaties die enkele instructies schelen moet je alleen
> doen in inner loops die heel erg vaak worden uitgevoerd.

Leuk voorbeeld:
http://www.gamedev.net/reference/articles/article209.asp


> Anders maak je de verkeerde afweging.

Wat voegde die tekst toe? ;)

-- 
Affijn, Ruud   `  -  ?
               + ` ? *
                 ? `     Jvr qvg yrrfg,
               ?  =  `   fgresg wbatre.

Jan de Vos <jdv@zeewier.blub.net> writes:

> In nl.comp.programmeren, Johan Wevers wrote:
> >>> en optimalisatie (de assignment binnen de if).
> >>Optimalisatie van wat?
> >
> > Van de executietijd/aantal instructies als de assignment anders toch zou
> > moeten worden uitgevoerd.
> 
> Pas heel erg op dat je geen micro-optimalisaties doet die de
> leesbaarheid in het geding brengen.
> 
> Optimalisaties die enkele instructies schelen moet je alleen doen in
> inner loops die heel erg vaak worden uitgevoerd.  Anders maak je de
> verkeerde afweging.

En dan nog alleen als je zeker wat dat het optimaliseren van die loop
effectief is en daadwerkelijk de snelheid van je applicatie zal
beinvloeden.

Vaak is optimalisatie prematuur; programmeurs denken slim te zijn en
springen door hoepels voor niet-bestaande performance problemen met als
resultaat raar onleesbaar prutswerk.

 S.

Stefan Arentz wrote:

> Vaak is optimalisatie prematuur; programmeurs denken slim te zijn en
> springen door hoepels voor niet-bestaande performance problemen met
> als resultaat raar onleesbaar prutswerk.

Vaak inderdaad het geval, zeker met bij mensen die nog niet zo lang 
programmeren. Soms ook veroorzaakt doordat men een datastructuur niet 
snapt. 

Optimalisatie is vaak duurder dan gewoon nog een computer er bij kopen, of 
een snellere.

Ik heb ooit handmatig ARM code zitten optimaliseren. Dat had effect, maar 
was (relatief) duur, en ik rekende toen nog een studententarief. Maar er 
was geen snellere machine op dat moment :-D.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

In nl.comp.programmeren,
Johan Wevers <johanw@vulcan.xs4all.nl> wrote:
>Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>
>>Ook in DOS heb je daar last van. Altijd als je in real-mode meer dan
>>64K geheugen wilt gebruiken.
>
>In die tijd schreef ik nog programma's die wel binnen die 64kb bleven.

Ik helaas niet altijd. Zo had ik eens een programma'tje dat een signaal
op het scherm moest zetten. Ik had het signaal in een array gezet:

float signaal[100000]; /* En als index een int gebruiken */

Toch best een tijd aan het zoeken geweest waar om het signaal zich
steeds na ca. 16000 waarden herhaalde. ;-)

Met iets van farmalloc (of was het nu huge?) en far/huge pointers ging
het toch een stuk beter.

>Dat was bij m'n afstuderen, het traagste was nog een stel geneste loops,
>maar als ik haast had kon ik die soms draaien op het paradepaardje van de
>afdeling: een gloednieuwe supersnelle 486DX2-50. Dat was in 1993.
>
He, in dat jaar studeerde ik ook af! Als ik het mij goed herinner moesten
wij het (in ca. het 2e jaar, '91) vooral met 286/386 en oude Apollo's doen.
Vooral leuk als je een p-spice simulatie (elektrische schakelingen
simuleren) moest doen. Als je dat toevallig op die ene 386 met 387 kon doen
was je toch 10x sneller klaar als zonder die 387.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Today, THREE WINOS from DETROIT sold me a framed photo of TAB HUNTER
before his MAKEOVER!

Johan Wevers wrote:

> Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
> 
>>Ook in DOS heb je daar last van. Altijd als je in real-mode meer dan
>>64K geheugen wilt gebruiken.
> 
> In die tijd schreef ik nog programma's die wel binnen die 64kb bleven.
> Dat was bij m'n afstuderen, het traagste was nog een stel geneste loops,
> maar als ik haast had kon ik die soms draaien op het paradepaardje van de
> afdeling: een gloednieuwe supersnelle 486DX2-50. Dat was in 1993.

Ha, mijn software, ontwikkelt op een Archimedes (in C) mocht draaien op een 
Indigo 2 :-D (maar dat was in 1994).

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html

Stef wrote:
> In nl.comp.programmeren,
> Sjoerd A. Schreuder <sa_schreuder@wanadoo.nl> wrote:
> 
>>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.
> 
> Ja, de cast is in C niet noodzakelijk en wordt o.h.a. afgeraden.
> Belangrijkste argument is dat een vergeten "#include <stdlib.h>" met de
> cast geen foutmelding geeft en zonder de cast juist wel. Doorzoek anders
> comp.lang.c eens op "never cast the return value of malloc".

Zinnig argument. Ik zal het onthouden als ik ooit in C moet programmeren.

Mocht ik ooit in C gaan programmeren, dan gebruik ik wel een compiler
die een warning geeft als ik een functie gebruik zonder voorafgaande
declaratie. Ik weet dat C dat niet vereist(te), maar persoonlijk
beschouw ik het wel als een bug.

>>Als mijn aanname over C juist is, dan zit er dus wel degelijk een
>>groot verschil tussen C en C++ op dit punt.
> 
> Klopt en C++ code zit dan ook vol met die ergerlijke casts.

Ik weet niet wat voor C++ code jij gemiddeld onder ogen krijgt, maar
een goed opgezet C++ programma heeft geen of slechts enkele casts nodig.

In C++ code die ik van C++ experts zie, zitten ook geen casts.
In C++ code die ik schrijf, zitten ook geen casts.

Ik ben benieuwd wat voor casts jij tegenkomt. Het bovenstaande probleem
rond malloc heb je niet in C++, want in C++ gebruik je geen malloc
maar new of std::vector<>/std::list<>/...

 >  En ook C
> code die door een C++ compiler gehaald wordt.

In zulke programma's zullen inderdaad casts moeten zitten, b.v. bij
elke malloc() (hetgeen niet erg is, omdat de "#include <stdlib.h>"
in C++ verplicht is als je malloc() wilt gebruiken).

Sjoerd

Johan Wevers wrote:
> Sjoerd A. Schreuder <sa_schreuder@wanadoo.nl> wrote:
[knip]
>>En zoals gezegd: dit verschil in type van NULL is in de praktijk
>>nauwelijks te merken.
> 
> Nou, als NULL als long geinterpreteerd wordt in overloaded functies toch
> echt wel. Jouw voorbeeld ziet er bepaald niet ingewikkeld of kunstmatig
> uit.

Het voorbeeld is simpel, maar komt in de praktijk zelden voor. Als
foo(long) hetzelfde doet als foo(void*), dan merkt 99% van de
programmeurs niet eens welke versie wordt aangeroepen. Je krijgt
pas problemen als foo(long) iets anders doet dan foo(void*). Maar
waarom heb je ze dan dezelfde naam gegeven?

Voor de goede orde, het besproken voorbeeld is:
void foo(long);
void foo(void*);

int main()
{
   foo(NULL); // roept foo(long) aan
}

Sjoerd

In nl.comp.programmeren,
Sjoerd A. Schreuder <sa_schreuder@wanadoo.nl> wrote:
>Stef wrote:
>> In nl.comp.programmeren,
>> Sjoerd A. Schreuder <sa_schreuder@wanadoo.nl> wrote:
>> 
>>>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.
>> 
>> Ja, de cast is in C niet noodzakelijk en wordt o.h.a. afgeraden.
>> Belangrijkste argument is dat een vergeten "#include <stdlib.h>" met de
>> cast geen foutmelding geeft en zonder de cast juist wel. Doorzoek anders
>> comp.lang.c eens op "never cast the return value of malloc".
>
>Zinnig argument. Ik zal het onthouden als ik ooit in C moet programmeren.
>
>Mocht ik ooit in C gaan programmeren, dan gebruik ik wel een compiler
>die een warning geeft als ik een functie gebruik zonder voorafgaande
>declaratie. Ik weet dat C dat niet vereist(te), maar persoonlijk
>beschouw ik het wel als een bug.
>
De zinnigheid van het argument kun je idd in twijfel trekken. Algemene
strekking is dat een onnodige cast fouten kan verbergen. Veelal kun
je die alsnog zichtbaar maken door het warning level hoog genoeg te
zetten. Ander zinning argument (TM) is natuurlijk dat ik het niet mooi
vind. ;-)

>>>Als mijn aanname over C juist is, dan zit er dus wel degelijk een
>>>groot verschil tussen C en C++ op dit punt.
>> 
>> Klopt en C++ code zit dan ook vol met die ergerlijke casts.
>
>Ik weet niet wat voor C++ code jij gemiddeld onder ogen krijgt, maar
>een goed opgezet C++ programma heeft geen of slechts enkele casts nodig.
>
Goed, het statement was wat dik aangezet.

>In C++ code die ik van C++ experts zie, zitten ook geen casts.
>In C++ code die ik schrijf, zitten ook geen casts.
>
De C++ code die ik zie (= niet veel) is vaak geschreven door (ex) C
programmeurs. En dat geeft idd. een vervormd beeld van C++.

>Ik ben benieuwd wat voor casts jij tegenkomt. Het bovenstaande probleem
>rond malloc heb je niet in C++, want in C++ gebruik je geen malloc
>maar new of std::vector<>/std::list<>/...
>
Ja, zo zou het moeten, maar dat gebeurt niet overal.

> >  En ook C
>> code die door een C++ compiler gehaald wordt.
>
>In zulke programma's zullen inderdaad casts moeten zitten, b.v. bij
>elke malloc() (hetgeen niet erg is, omdat de "#include <stdlib.h>"
>in C++ verplicht is als je malloc() wilt gebruiken).
>
In de C code die ik van C experts zie zitten geen casts voor malloc.
In de C code die ik schrijf...

De aanwezigheid van casts voor malloc in een C programma duid er op
dat een C++ programmeur in C bezig is geweest en/of dat er een C++
compiler gebruikt is. ;-)

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Fay: The British police force used to be run by men of integrity.
Truscott: That is a mistake which has been rectified.
		-- Joe Orton, "Loot"

Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

>float signaal[100000]; /* En als index een int gebruiken */

Ik werkte toen in Turbo Pascal. Die slikte zoiets niet.

>He, in dat jaar studeerde ik ook af! Als ik het mij goed herinner moesten
>wij het (in ca. het 2e jaar, '91) vooral met 286/386 en oude Apollo's doen.

De standaardmachines waren toen inderdaad nog 286's. Maar wel met 287
coprocessor, anders waren die berekeningen helemala niet vooruit te
trappen (er zaten nogal wat exp() functies in die de 287 in hardware
doet). En anders thuis maar draaien toen ik eindelijk die 486-33 had.
Onder OS/2 in 4 DOS boxen tegelijk 's nachts laten stampen, dat ging
op de TUE niet.

-- 
ir. J.C.A. Wevers         //  Physics and science fiction site:
johanw@vulcan.xs4all.nl   //  http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html