[c++] if (T a = b) ... <= deze feature te beperkt?

[Verwijderd]

Dit kan in C++:

code:

if (T a = b) ;

Dit kan echter niet:

code:

if (T a (b)) ;

1) Waarom kan dit niet (Ik had namelijk begrepen dat initializatie met = ouderwets C was..)

Verder zijn uitgebreidere constructies als deze ook niet mogelijk:

code:

if ((T a = b) == c) ;

Het is (voor zover ik weet) dus alleen mogelijk om op één variabele een simpele conversie naar bool los te laten, en verder niks.

2) Zijn jullie het met me eens dat deze declaratie/definitie-in-een-conditie feature eigenlijk te beperkt is om echt algemeen nuttig te kunnen zijn ?

_{3) Of vergeet ik hier essentiële punten die deze feature alsnog nuttig maken ?}

Ps: Excuus voor de vage topictitel, ik kon deze kwestie helaas echt niet in één regel text zonder voorbeeld verwoorden..

[RickN]

Ik denk (maar die discussie is hier laatst ook al eens geweest) dat een assignment geen waarde hoort te hebben, en dus niet als een expressie gebruikt zou moeten kunnen worden. Wat dat betreft denk ik dus dat de feature niet te beperkt, maar te aanwezig is. Aan de andere kant is het wel frapant dat ALS de constructie wordt toegelaten hij niet wordt toegelaten in uitgebreidere expressies. Over de constructie T a (b) kan ik niet veel zeggen ik ben er niet erg bekend mee. Het lijkt me alleen sterk dat de goeie ouwe assigment ouderwets is geworden. Volgens mij is zo'n constructie alleen zinvol bij classes en niet bij de basis typen.

[Verwijderd]

Op dinsdag 04 juni 2002 10:21 schreef RickN het volgende:
Ik denk (maar die discussie is hier laatst ook al eens geweest) dat een assignment geen waarde hoort te hebben

Bij de

code:

T a = b;

syntax is er geen sprake van assignment in de zin van een assignment operator. In het voorbeeld wordt simpelweg T::T(b) aangeroepen om a te constructen.

[RickN]

Op dinsdag 04 juni 2002 10:27 schreef Sneechy het volgende:

[..]

Bij de

code:

T a = b;

syntax is er geen sprake van assignment in de zin van een assignment operator. In het voorbeeld wordt simpelweg T::T(b) aangeroepen om a te constructen.

Het blijft een assignment, je kent een waarde toe een aan (nieuw) object. Je zegt in feite niets anders dan:

T a;
a = b;

Ik heb het ook over het begrip assignment, niet de operator.

[Korben]

Op dinsdag 04 juni 2002 02:48 schreef Sneechy het volgende:
Verder zijn uitgebreidere constructies als deze ook niet mogelijk:

code:

if ((T a = b)) == c) ;

Dat lijkt me nogal logisch, T is out of scope als je hem met c probeert te vergelijken. En dan zie ik de gruwelijke syntaxfout nog door de vingers.

[Verwijderd]

Op dinsdag 04 juni 2002 11:38 schreef Xenophage het volgende:
Dat lijkt me nogal logisch, T is out of scope als je hem met c probeert te vergelijken.

Dat is niet zozeer het probleem; het punt is dat de variabele-declaratie/definitie-in-conditie syntax alleen gebruikt mag worden als:

code:

if (T a = b) ...

Overigens is de scope van a in dit voorbeeld niet beperkt tot de conditie; ook de 'body' van de if valt onder a's scope (dat is juist het hele idee van deze feature).

En dan zie ik de gruwelijke syntaxfout nog door de vingers.

Oeps

[.oisyn]

Op dinsdag 04 juni 2002 11:38 schreef Xenophage het volgende:

[..]

Dat lijkt me nogal logisch, T is out of scope als je hem met c probeert te vergelijken. En dan zie ik de gruwelijke syntaxfout nog door de vingers.

is ie wel out of scope dan? Volgens mij hebben haakjes geen eigen scope; a is nu gewoon te zien in het hele if-block

[MSalters]

Op dinsdag 04 juni 2002 10:34 schreef RickN het volgende:
Het blijft een assignment, je kent een waarde toe een aan (nieuw) object. Je zegt in feite niets anders dan:

T a;
a = b;

Ik heb het ook over het begrip assignment, niet de operator.

Sorry, maar onzin. Assignment [het begrip] overschrijft de waarde van een bestaand object; construction niet. T a=b overschrijft geen T, jouw voorbeeld wel.

Volgens mij is de reden backwards compatibility met C, die wel int a=b kende maar geen int a(b) in een if-statement

[Verwijderd]

Op dinsdag 04 juni 2002 14:59 schreef MSalters het volgende:
Volgens mij is de reden backwards compatibility met C, die wel int a=b kende maar geen int a(b) in een if-statement

Zit wat in..

Wat vind je trouwens van m'n tweede vraag ? ("Zijn jullie het met me eens dat deze declaratie/definitie-in-een-conditie feature eigenlijk te beperkt is om echt algemeen nuttig te kunnen zijn ?")

[RickN]

Op dinsdag 04 juni 2002 14:59 schreef MSalters het volgende:

[..]

Sorry, maar onzin. Assignment [het begrip] overschrijft de waarde van een bestaand object; construction niet. T a=b overschrijft geen T, jouw voorbeeld wel.

Volgens mij is de reden backwards compatibility met C, die wel int a=b kende maar geen int a(b) in een if-statement

Sorry, maar onzin. Assignment [het begrip] kent een waarde toe aan een object. Of de waarde van dat object voor de toekenning gedefineerd was is irrelevant. Construction, zoals jij het noemt, is uiteindelijk niks anders dan het reserveren van wat ruimte voor het object en (eventueel) data aan die ruimte toekennen. Dat de taal met wat syntactic sugar een constructie heeft waarmee dat je dat in één expressie kunt uitdrukken maakt het nog niet iets significant anders dan het eerst (met een default construtor) aanmaken van een object en er vervolgens handmatig een waarde aan toekennen.

Er is geen semantisch verschil, alleen een syntactisch.

[MSalters]

Op dinsdag 04 juni 2002 15:54 schreef RickN het volgende:

[..]

Sorry, maar onzin. Assignment [het begrip] kent een waarde toe aan een object. Of de waarde van dat object voor de toekenning gedefineerd was is irrelevant. Construction, zoals jij het noemt, is uiteindelijk niks anders dan het reserveren van wat ruimte voor het object en (eventueel) data aan die ruimte toekennen. Dat de taal met wat syntactic sugar een constructie heeft waarmee dat je dat in één expressie kunt uitdrukken maakt het nog niet iets significant anders dan het eerst (met een default construtor) aanmaken van een object en er vervolgens handmatig een waarde aan toekennen.

Er is geen semantisch verschil, alleen een syntactisch.

Ok - als je mij niet geloofd, dit is wat de rest van de C++ commissie d'r van maakt:

[dcl.init] 8.5 Initializers
1 A declarator can specify an initial value for the identifier being declared. The identifier designates an object or reference being initialized. The process of initialization described in the remainder of 8.5 applies
also to initializations specified by other syntactic contexts, such as the initialization of function parameters
with argument expressions (5.2.2) or the initialization of return values (6.6.3).
initializer:
= initializer-clause
( expression-list )
...
11 The form of initialization (using parentheses or =) is generally insignificant, but does matter when the entity being initialized has a class type; see below.
...
The initialization that occurs in argument passing, function return, throwing an exception (15.1), handling an exception (15.3), and brace-enclosed initializer lists (8.5.1) is called copy-initialization and is equivalent to the form
T x = a;
...
[Note: overloading of the assignment operator (13.5.3) has no effect on initialization.]
...
For example, in 8.5, another syntax for initializer is
= initializer-clause but again the resulting construct might be a function call upon a constructor function with one assignment-expression as an argument;
...
[Note: For class objects, assignment is not in general the same as initialization (8.5, 12.1, 12.6, 12.8). ]

Verder heb je nog subtiliteiten als T==const int, dus
const int x=7; zou gelijk zijn (volgens jou) aan
const int x; x=7;

Hetzelfde geldt voor references:
const int& y = x; versus const int& y; y=x;

Kortom, je kunt het oneens zijn met hoe C++ omgaat met =, maar wat blijft staan is dat in C++ het statement T a = b; geen assignment-statement is.

Overigens is het een stuk makkelijker om aan te tonen dat een C++ constructie wel een valide statement van een bepaald type is; je hoeft alleen de relevante grammatica productie te laten zien. Dus als je nog steeds denkt dat het een assignment is, wat is dan de productie?
Hint: de eerste productie regel is

assignment-expression:
conditional-expression
logical-or-expression assignment-operator assignment-expression
throw-expression

[mbravenboer]

Eerlijk gezegd vind ik het wel een beetje enorm mieregeneuk wat ik hier zie .

Het gaat erom wat je een assignment noemt. Als je een assignment opvat als het toekennen van een waarde aan een variabele, kan je zowel 'x = 5' als 'int x = 5' als een assignment beschrijven.

Dat 'int x = 5' echter een declaratie is met een intitializer is een grammaticale kwestie. Beide statements (expressies ) hebben tot gevolg dat er in de environment een mapping is van de variabele x naar de waarde 5. Als je het opnemen van zo'n mapping als een assignment wilt zien, is de declaratie met een intializer dus ook een assignment...

Uiteraard is het wel zo dat als je puur naar non-terminals in de grammatica kijkt, 'int x = 5' inderdaad geen assignment is.

[mbravenboer]

Vandaar dus trouwens ook de opmerking:

"Assignment [het begrip] kent een waarde toe aan een object."

Let op [het begrip] .

[RickN]

Wat je hier aantoont, is dat de "=" in T a = b geen assignment operator is, maar dat heb ik ook nooit tegengesproken. Dat de parser een initialisatie ook anders parst dan een assignment geloof ik ook best, en die productie regels kan ik dan ook niet geven.

De subtiliteiten die je laat zien tonen iig aan dat de initialisatie constructie niet zomaar syntactic sugar is zoals ik beweerde, het geeft je idd mogelijkheden die je voorheen niet had.

Het was erg gevaarlijk van mij om iemand die al zo vaak heeft laten zien de C standaard van binnen en van buiten te kennen tegen te spreken waar het specifieke taal constructies betreft

Maahaar , dat is eigenlijk ook niet waar het hier om gaat. Wat ik stelde was dat initialisatie een voorbeeld is van het breedde begrip assignment, in de zin van het toekennen van een waarde aan een variable. Ik praatte dus in taal concepten en semantieken, en die kun je niet onderuit schoffelen door met definities in specifieke talen aan te komen...
Als taal concept hoort een assignment m.i. geen waarde te hebben, en dan dus een initialisatie ook niet.

Anyway, ben je het niet met me eens dat initialisatie een vorm van assignment is? Even afgezien van de implementatie in welke specifieke programmeertaal dan ook?

edit:
Jah, wat mbravenboer zei...dat bedoelde ik

[MSalters]

Op dinsdag 04 juni 2002 17:37 schreef RickN het volgende:
Maahaar , dat is eigenlijk ook niet waar het hier om gaat. Wat ik stelde was dat initialisatie een voorbeeld is van het breedde begrip assignment, in de zin van het toekennen van een waarde aan een variable. Ik praatte dus in taal concepten en semantieken, en die kun je niet onderuit schoffelen door met definities in specifieke talen aan te komen...
Als taal concept hoort een assignment m.i. geen waarde te hebben, en dan dus een initialisatie ook niet.

Anyway, ben je het niet met me eens dat initialisatie een vorm van assignment is? Even afgezien van de implementatie in welke specifieke programmeertaal dan ook?

Als ik denk aan functionele talen( die wel initialisation maar geen [andere] assignment hebben ) dan wordt het duidelijk dat het concept van assignment in stricte zin alleen bruikbaar is voor variabelen ( assignment is waardoor ze varieren )terwijl initialisatie relevant is voor alle soorten waarden (dus ook constanten etc.).

Sterker nog, assignment [in stricte zin] is precies datgene waarin constanten en variabelen verschillen. Juist daarom is het essentieel om het onderscheid te maken; zouden we assignment en initialisatie op een hoop gooien dan verdwijnt daarmee het verschil tussen constanten en variabelen

Dit staat overigens los van het feit dat in C en C++ assignments geen expressies hadden hoeven wezen. a=b=0 werkt dan niet maar tsja, iedereen maakt altijd keuzes - alleen maakt niet iedereen dezelfde keuzes.

MSalters denkt dat'ie toch maar moet gaan promoveren bij informatica - weet iemand een goede Uni?

[MSalters]

Op dinsdag 04 juni 2002 02:48 schreef Sneechy het volgende:
Dit kan in C++:

code:

if (T a = b) ;

Dit kan echter niet:

code:

if (T a (b)) ;

1) Waarom kan dit niet (Ik had namelijk begrepen dat initializatie met = ouderwets C was..)

Heb het effe uitgezocht - de productie voor 'if ( T a = expr ) ' is een special case, los van normale variable declaraties en daar staat geen special case bij voor 'T a(expr)'. [6.4][stmt.select]

Verder zijn uitgebreidere constructies als deze ook niet mogelijk:

code:

if ((T a = b) == c) ;

Het is (voor zover ik weet) dus alleen mogelijk om op één variabele een simpele conversie naar bool los te laten, en verder niks.

Nee - de productie werkt ook voor switch dus alle integral types zijn bruikbaar, niet alleen bool.

[mbravenboer]

MSalters: Als ik denk aan functionele talen( die wel initialisation maar geen [andere] assignment hebben ) dan wordt het duidelijk dat het concept van assignment in stricte zin alleen bruikbaar is voor variabelen ( assignment is waardoor ze varieren )terwijl initialisatie relevant is voor alle soorten waarden (dus ook constanten etc.).

Ten eerste is het wel raar om in functionele talen de term 'initialiseren' te gebruiken. Initialiseren zou je namelijk opvatten als het geven van een initiele waarde, waarmee je eigenlijk suggereert dat de identifier ooit nog gebonden kan worden aan een andere waarde. Dat kan uiteraard niet in functionele talen, zoals je zelf al aangeeft.

In een functionele taal is een '= expressie' (ik noem het bewust geen assigment ) daarom ook meer de definitie van alias voor een bepaalde expressie. Deze identifier kan je gebruiken als je in feite de expressie (wat een functie met of zonder argumenten kan zijn) bedoelt.

Zie bijvoorbeeld:
http://www.haskell.org/tutorial/patterns.html

Zoals iedereen wel begrijpt gaat het dus in feite om het concept dat er in een environment een binding wordt opgenomen van een identifier naar een waarde.

Dit kan gebeuren door een declaratie met een intializer in een imperatieve taal. De binding kan veranderd worden door een assignment. Het opnemen van de binding in de environment is het begrip waar we het over hebben. Ik kan me goed voorstellen dat je dit omschrijft als een assignment (assignment betekent immers toewijzing), alhoewel het uiteraard incorrect is als je het heel strict gaat bekijken.

Dat neemt niet weg dat we elkaar wel begrijpen .

MSalters denkt dat'ie toch maar moet gaan promoveren bij informatica - weet iemand een goede Uni?

De UU komt samen met de VU elk jaar uit de bus als de beste informatica opleiding (beoordeeld door docenten/onderzoekers). Als je echter op dit gekissebis wilt promoveren, wil ik je liever ergens anders naar verwijzen .

[MSalters]

Op dinsdag 04 juni 2002 18:20 schreef mbravenboer het volgende:
De UU komt samen met de VU elk jaar uit de bus als de beste informatica opleiding (beoordeeld door docenten/onderzoekers). Als je echter op dit gekissebis wilt promoveren, wil ik je liever ergens anders naar verwijzen .

Tsja - 't is in real-world minder belangrijk, daar heb je helemaal gelijk in. Maar hoe vaak heeft dat universiteiten tegengehouden? Serieus, dat is IMO waar universiteiten voor zijn; voor onderzoek wat het bedrijfsleven laat liggen omdat er geen acute relevantie is.

Overigens zat ik zelf eerder te twijfelen tussen een TU en een buitenlandse universiteit; heb je een url'letje [sp?] voor je beoordelingsquote?

[Verwijderd]

Op dinsdag 04 juni 2002 18:04 schreef MSalters het volgende:

[..]

Heb het effe uitgezocht - de productie voor 'if ( T a = expr ) ' is een special case, los van normale variable declaraties en daar staat geen special case bij voor 'T a(expr)'. [6.4][stmt.select]

Dank voor 't opzoeken, maar dat is niet echt het type reden waar ik naar op zoek ben. Ik ben vooral benieuwd waarom hiervoor gekozen is. Die compatibiliteit met C die je eerder noemde zou hierbij inderdaad goed een rol kunnen spelen.

Verder zou ik je nog een keer willen vragen hoe je denkt over mijn tweede vraag/stelling.

[mbravenboer]

MSalters: Tsja - 't is in real-world minder belangrijk, daar heb je helemaal gelijk in. Maar hoe vaak heeft dat universiteiten tegengehouden? Serieus, dat is IMO waar universiteiten voor zijn; voor onderzoek wat het bedrijfsleven laat liggen omdat er geen acute relevantie is.

Met dat laatste ben ik het eens, maar omdat nu een discussie over het de terminologie assignment versus environment binding versus intializer als voorbeeld te nemen gaat me wel wat ver . Gelukkig zijn de meeste promotie-onderzoeken toch wat zinvoller dan een discussie over termininologie .

Overigens zat ik zelf eerder te twijfelen tussen een TU en een buitenlandse universiteit; heb je een url'letje [sp?] voor je beoordelingsquote?

Ik doelde op het onderzoek wat elk jaar door de Elsevier wordt uitgevoerd. Ik kon dit onderzoek echter niet online vinden. Overigens is dit jaar ook de visitatie-commissie langs geweest, maar daarvan heb ik nog niet meer gezien dan een monderlinge reportage.

Ik weet trouwens niet waarom je voor een TU zou willen kiezen, maar als je dat doet omdat een TU 'beter' of 'technischer' is, zou ik dat graag willen bestrijden .

In welke richting denk je uberhaupt? Dat lijkt mij namelijk nogal relevant voor je keuze. Op de verschillende onderzoeks-instellingen is men bezig met compleet andere zaken en is men dus ook gespecialiseerd in andere richtingen.

Op de UU gaat dit sterk richting functionele talen, generieke uitbreidingen hierop, programma-transformaties, compilerbouw en optimalisaties daarbij.

[.oisyn]

Op dinsdag 04 juni 2002 19:33 schreef mbravenboer het volgende:
Op de UU gaat dit sterk richting functionele talen, generieke uitbreidingen hierop, programma-transformaties, compilerbouw en optimalisaties daarbij.

.ot:
hoe zit het met de grafische kant van de UU? Want ik wil hierna (HvU, nog 1 jaar) nog een VDO doen, en liefst op de UU want das het dichtst bij , maar ik wil me wel specializeren in computer graphics

[mbravenboer]

.oisyn: hoe zit het met de grafische kant van de UU? Want ik wil hierna (HvU, nog 1 jaar) nog een VDO doen

Dan zou je wellicht ook alleen een master kunnen doen (volgend jaar stapt men immers over op bachelor-master), maar in de voorwaarden daarvan ben ik verder niet zo in thuis.

en liefst op de UU want das het dichtst bij , maar ik wil me wel specializeren in computer graphics

Ik ben nooit die richting opgegaan, maar kan je wel wat bronnen geven:

Dit is de website van de groep die jij dan interessant vindt: http://www.cs.uu.nl/centers/give/

De vakken die op dit moment worden gegeven kan je hier nakijken: http://www.cs.uu.nl/education/informatica/index.htm

In het bijzonder is er nu een nieuw vak Game Design:
http://www.cs.uu.nl/docs/vakken/gds/

Ik heb echter geen idee van het niveau van deze zaak.

Binnen de opleiding Medisch Technische Informatica wordt er overigens ook veel met computer graphics gedaan (beeldverwerking en simulatie).

[.oisyn]

thanx, heb net even een kijkje genomen op de site over GIVE, en dat zag er wel interessant uit...

als je master doet, stroom je dan gewoon in in het 4e jaar?

[RickN]

Ik wil nog even terugkomen op onze discussie over assignment/initalisatie terminologie. Het is voor de topic starter niet meer echt van belang (is de hele discussie eigenlijk nooit geweest), maar ik heb de even moeite gedaan om de preciese details uit m'n geheugen op te vissen (waarbij ik overigens gebruik heb gemaakt van het boek waar ze oorspronkelijk uit kwamen). Voor wie het nog interesseert:

Zoals mbravenboer al opmerkte draait het bij zowel een assignment als een initialisatie om het binden van een waarde aan een variable. Sterker nog assignment en initialisatie zijn exact hetzelfde behoudens het moment waarop deze binding plaatsvindt. De binding bij initialisatie vindt plaats op het moment dat de variable aan het geheugen wordt gebonden (het moment waarop de variable wordt gecreerd). De binding is daardoor statisch of dynamisch, afhankelijk van of de binding van de variable aan het geheugen statisch of dynamisch is. Een assignment daarentegen is altijd runtime, en de binding die erbij tot stand wordt gebracht is dus altijd dynamisch.

Of een variable al dan niet een named constant (dus niet constante, een constante is b.v. 7) is, wordt in principe niet bepaald door of deze wordt geïnitialiseerd, of geassigned. De binding van een waarde aan een named constant kan namelijk ook zowel statisch als dynamisch zijn (namelijk dynamisch als de toegekende waarde niet compile time bekend is; er zijn talen die dit niet toelaten). Het enige verschil met gewone variablen is dat de binding met een waarde die gemaakt wordt permanent is. Deze definitie van named constant sluit in principe een constructie als deze niet uit:

code:

const int i;
i := 10;

Dit zou gewoon een dynamisch binding van 10 aan i opleveren die niet meer mag veranderen, op zich niets bijzonders. Een reden die ik kan bedenken waarom dit niet wordt gedaan, is dat dat het niks toevoegd naast de gebruikelijke manier om named constants te initialiseren terwijl het moeilijker (onmogelijk?) wordt voor de compiler om compile time te bepalen of het const zijn van een variable niet wordt overschreden. De link tussen initialisatie als toekennings methode en het constant zijn van een variable is dus vrij kunstmatig.

Tot zover de mierenneuk oefening.

Een openbaring die ik onderging tijdens het lezen wil ik jullie niet onthouden:

Ik wist niet dat C++ de volgende constructie kende:

code:

condition?a:b = c;

wat equivalent is met:

if (condition) then a=c else b=c;

Da's natuurlijk prachtig voor de orthogonaliteit van de taal, om dat toe te staan naast de

code:

a = condition?b:c

constructie. Jammer alleen dat ze hiervoor überhaupt nieuwe constructies hebben geïntroduceerd, echt mooi orthogonaal zou het zijn geweest als ze dit hadden toegestaan:

code:

(if (condition) then a else b) = c

en 

a = if (condition) then b else c

[over promoveren]
Ik neem aan dat je zelf ook liever onderzoek wilt doen naar iets wat interesanter is dan dit
Ik heb trouwens het idee dat jij momenteel niet meer studeert (en ik neem ook aan dat je een universitaire informatica opleiding hebt afgerond) en dus al een tijdje aan het werk bent. Het zou van bijzonder veel motivatie getuigen als jij daadwerkelijk je huidige salaris opgeeft om voor een AIO salaris bij een of andere uni te gaan promoveren. Kijk, ik ga ook promoveren, maar ik ben nog nooit een fatsoenlijk salaris verdient, dus alles wat ik straks ga krijgen is beter dan nu. Daarnaast bestaat er nog de mogelijkheid dat ik als werknemer bij Philips in dienst treed en dan om mijn werkzaamheden daar promoveer. Dat zou een typisch geval zijn van: "Have my cake and eat it too!"
[/over promoveren]

[mbravenboer]

.oisyn: als je master doet, stroom je dan gewoon in in het 4e jaar?

Als je het vergelijkt met de huidige indeling stroom je inderdaad in in het 4e jaar. Ik zie een master opleiding na een HBO opleiding eigenlijk vooral als een beter opgezet verkort doctoraal, wat altijd al mogelijk was.

[mbravenboer]

RickN: De binding bij initialisatie vindt plaats op het moment dat de variable aan het geheugen wordt gebonden (het moment waarop de variable wordt gecreerd). De binding is daardoor statisch of dynamisch, afhankelijk van of de binding van de variable aan het geheugen statisch of dynamisch is. Een assignment daarentegen is altijd runtime, en de binding die erbij tot stand wordt gebracht is dus altijd dynamisch.

Op zich begrijp ik wel waar je op doelt, maar dat bedoelde ik eigenlijk niet met 'binding'. In de beschrijving van de semantiek van een taal wordt vaak gesproken over environments en bindingen in deze environment. Het gaat dan niet over een concrete executie op een machine, maar het is simpelweg een formele visie op een imperatief programma. Zowel een declaratie met een initializer als een assignment brengen zo'n binding aan in de environment, waarbij een assigment eventueel een bestaande binding kan vervangen.

Ik wist niet dat C++ de volgende constructie kende

Eingelijk vind ik alle code (ook de betere die je voorstelt) ranzig .

Wat zal bijvoorbeeld het type zijn van 'if (condition) then a else b'. Normaal gesproken zou je verwachten dat dit een expressie is die afhankelijk van de conditie de waarde van a of b oplevert en dus als type het type van a en b heeft. In deze situatie is het resultaat van deze toestand echter geen waarde, maar een 'variabele' ... Yukkie .

Het zou van bijzonder veel motivatie getuigen als jij daadwerkelijk je huidige salaris opgeeft om voor een AIO salaris bij een of andere uni te gaan promoveren.

Je kan in principe ook promoveren op werk wat je al verricht hebt in een bedrijf. Niet met voorbedachten rade promoveren dus als het ware . Uiteraard weet ik niet wat MSalters in dit geval bedoelt en nog minder kan ik beoordelen of hij promoveerbaar werk heeft gedaan .

Daarnaast bestaat er nog de mogelijkheid dat ik als werknemer bij Philips in dienst treed en dan om mijn werkzaamheden daar promoveer.

Philips is populair als promotie-plaats geloof ik .

[MSalters]

Op dinsdag 04 juni 2002 23:36 schreef RickN het volgende:
[..heleboel interessants..]
[over promoveren]
Ik neem aan dat je zelf ook liever onderzoek wilt doen naar iets wat interesanter is dan dit
Ik heb trouwens het idee dat jij momenteel niet meer studeert (en ik neem ook aan dat je een universitaire informatica opleiding hebt afgerond) en dus al een tijdje aan het werk bent. Het zou van bijzonder veel motivatie getuigen als jij daadwerkelijk je huidige salaris opgeeft om voor een AIO salaris bij een of andere uni te gaan promoveren. Kijk, ik ga ook promoveren, maar ik ben nog nooit een fatsoenlijk salaris verdient, dus alles wat ik straks ga krijgen is beter dan nu. Daarnaast bestaat er nog de mogelijkheid dat ik als werknemer bij Philips in dienst treed en dan om mijn werkzaamheden daar promoveer. Dat zou een typisch geval zijn van: "Have my cake and eat it too!"
[/over promoveren]

Bijna goed - ik ben sinds 3 jaar ir, maar geen "echte" informatica. (Technische Natuurkunde, afstudeerrichting fysische informatica) Het is dus duidelijk dat m'n salaris achteruit zou gaan als ik AIO wordt, maar aan de andere kant zie ik m'n baas niet betalen. Het blijft dus een kosten-baten analyse; ik ga het niet doen om zonodig prof te worden. College geven is leuk voor een ochtend, niet voor een carriere.

En om nou bij Philips te gaan werken, daar zit de rest van de familie al

[MSalters]

Ik heb het issue overigens geforward naar comp.std.c++
(csc++ op Google News) om te kijken of er belangstelling is om dit in C++0x te "fixen"

edit:
URL copy&paste-o

[RickN]

Op woensdag 05 juni 2002 01:02 schreef mbravenboer het volgende:

[..]

Op zich begrijp ik wel waar je op doelt, maar dat bedoelde ik eigenlijk niet met 'binding'. In de beschrijving van de semantiek van een taal wordt vaak gesproken over environments en bindingen in deze environment. Het gaat dan niet over een concrete executie op een machine, maar het is simpelweg een formele visie op een imperatief programma. Zowel een declaratie met een initializer als een assignment brengen zo'n binding aan in de environment, waarbij een assigment eventueel een bestaande binding kan vervangen.
[..]

De bindingen die jij bedoelt bedoel ik ook. Ik heb het ook niet over concrete executie. Mijn boek maakte echter onderscheid tussen statisch en dynamisch bindingen, waarbij statische binding vóór runtime gelegd zijn, zoals b.v. de binding tussen de plus operator en een integer, die language designtime al gelegd is. De mogelijk waarden van een integer is een statisch binding die language implementation time gelegt wordt.

Eingelijk vind ik alle code (ook de betere die je voorstelt) ranzig .

Wat zal bijvoorbeeld het type zijn van 'if (condition) then a else b'. Normaal gesproken zou je verwachten dat dit een expressie is die afhankelijk van de conditie de waarde van a of b oplevert en dus als type het type van a en b heeft. In deze situatie is het resultaat van deze toestand echter geen waarde, maar een 'variabele' ... Yukkie .
[..]

Ja, dat was precies wat ik zei toen een collega me laatst vroeg waarom die constructie niet bestond. Op zich is het best ranzig ja, maar ik zie er best wel wat voordelen van in. Orthogonaliteit in een taal is een vrij goede eigenschap. Ik denk dat ik wel met dergelijk constructies om zou kunnen gaan, maar misschien is het voor bepaalde programmeurs erg gevaarlijk B.t.w. Algol 68, het boegbeeld van orthogonaliteit, heeft deze feature.

Philips is populair als promotie-plaats geloof ik .

Tja, veel goede docenten en proffesoren op de TU/e werken parttime bij Philips, waarbij het accent vaak meer op Philips dan op de TU/e ligt. Ik moet zeggen dat ik het hier ook erg naar m'n zin heb....

[RickN]

Op woensdag 05 juni 2002 09:55 schreef MSalters het volgende:
Ik heb het issue overigens geforward naar comp.std.c++
(csc++ op Google News) om te kijken of er belangstelling is om dit in C++0x te "fixen"

Was da, C++0x? En ik neem aan dat je het issue bedoelt wat de TS aandroeg? Die link die je gaf is overigens een beetje kapot: "Het vinden van het bericht is mislukt"

[Verwijderd]

Op woensdag 05 juni 2002 10:05 schreef RickN het volgende:

[..]

Was da, C++0x?

De aankomende nieuwe versie van de C++ standaard, die momenteel in ontwikkeling is.

En ik neem aan dat je het issue bedoelt wat de TS aandroeg?

Daar gaat het inderdaad om.

Die link die je gaf is overigens een beetje kapot: "Het vinden van het bericht is mislukt"

Nog een poging, en anders moet je maar even in comp.std.c++ op 'Salters' zoeken en sorteren op datum.

[mbravenboer]

maar ik zie er best wel wat voordelen van in. Orthogonaliteit in een taal is een vrij goede eigenschap.

Ik vind dit eigenlijk niet echt een eigenschap die bijdraagd aan de ortogonaliteit van C++, wat overigens inderdaad een goede eigenschap is van een taal. Je introduceert namelijk een nieuwe constructie met een merkwaardig type. Dit merkwaardige type kan je echter op vrijwel geen enkele andere plek op deze manier gebruiken. Je creeert dus in feite een nieuwe feature die juist weer opgevuld zal moeten worden met andere features om de zaak weer orthogonaal te krijgen. Qua gebruik zou je het inderdaad wel kunnen zien als een tegenhanger van de andere assignment naar 1 variabele, maar ik bekijk het liever toch ook even op het punt van typering en dergelijek...

[Verwijderd]

Lichtelijk offtopic, maar is het jullie wel eens opgevallen dat de trenaire operator (a ? b : c) een andere semantiek heeft in C en C++? De expressie a ? b : c = d; heeft een andere precedence in C dan in C++.

In C++ is de expressie equivalent aan a ? b : (c = d);
In C is hij equivalent met a ? (b = d) : (c = d);

Leuke caveat bij het porten

[MSalters]

Op woensdag 05 juni 2002 14:48 schreef mietje het volgende:
Lichtelijk offtopic, maar is het jullie wel eens opgevallen dat de trenaire operator (a ? b : c) een andere semantiek heeft in C en C++? De expressie a ? b : c = d; heeft een andere precedence in C dan in C++.

In C++ is de expressie equivalent aan a ? b : (c = d);
In C is hij equivalent met a ? (b = d) : (c = d);

Leuke caveat bij het porten

Nee, nooit opgevallen. Sterker nog, het is de C++ auteurs ook niet opgevallen; Annex C van C++ ( geen grapje ( van mij ) ) met incompatibilities heeft deze er niet bij staan. De C++ parsing is correct, maar wat is de C productieregel ?

[RickN]

Op woensdag 05 juni 2002 13:16 schreef mbravenboer het volgende:

[..]

Ik vind dit eigenlijk niet echt een eigenschap die bijdraagd aan de ortogonaliteit van C++, wat overigens inderdaad een goede eigenschap is van een taal. Je introduceert namelijk een nieuwe constructie met een merkwaardig type. Dit merkwaardige type kan je echter op vrijwel geen enkele andere plek op deze manier gebruiken. Je creeert dus in feite een nieuwe feature die juist weer opgevuld zal moeten worden met andere features om de zaak weer orthogonaal te krijgen. Qua gebruik zou je het inderdaad wel kunnen zien als een tegenhanger van de andere assignment naar 1 variabele, maar ik bekijk het liever toch ook even op het punt van typering en dergelijek...

Dat je die a?b:c constructie zowel links als rechts van een assignment operator kunt gebruiken vind ik een mooie ortogonale eigenschap (als je er überhaupt al voor kiest om iets als dit in je taal te stoppen, daar heb je gelijk in) Ik kan ook nog wel begrijpen dat ze de if statement niet hebben hergebruikt voor dit soort gedrag, maar het zou m.i. wel ortogonaler zijn geweest. De if statement zou dan een keuze operator zijn waarmee je conditioneel tussen twee zaken kunt kiezen. Het ortogonale eraan is dat het niet hoeft uit te maken waartussen je kiest. Het zou een keuze tussen twee code blokken kunnen zijn zoals nu, maar ook tussen twee l- of r-values. Het HOEFT niet uit te maken, dat het in C(++) wel uitmaakt maakt de zaak minder ortogonaal. Ortogonaliteit komt natuurlijk ook wel met een prijs, namelijk parsen zal wat lastiger worden, al denk ik wel dat static typechecking mogelijk blijft.

[Verwijderd]

Op woensdag 05 juni 2002 15:11 schreef MSalters het volgende:
Nee, nooit opgevallen. Sterker nog, het is de C++ auteurs ook niet opgevallen; Annex C van C++ ( geen grapje ( van mij ) ) met incompatibilities heeft deze er niet bij staan. De C++ parsing is correct, maar wat is de C productieregel ?

Het is de auteurs van gcc (2.95.2) wel opgevallen, zij klagen erover in de bijgeleverde documentatie (met een snerend "thanks to the commission for another C vs. C++ incompatibility").

[MSalters]

Op woensdag 05 juni 2002 15:28 schreef RickN het volgende:

[..]

Dat je die a?b:c constructie zowel links als rechts van een assignment operator kunt gebruiken vind ik een mooie ortogonale eigenschap (als je er überhaupt al voor kiest om iets als dit in je taal te stoppen, daar heb je gelijk in) Ik kan ook nog wel begrijpen dat ze de if statement niet hebben hergebruikt voor dit soort gedrag, maar het zou m.i. wel ortogonaler zijn geweest. De if statement zou dan een keuze operator zijn waarmee je conditioneel tussen twee zaken kunt kiezen. Het ortogonale eraan is dat het niet hoeft uit te maken waartussen je kiest. Het zou een keuze tussen twee code blokken kunnen zijn zoals nu, maar ook tussen twee l- of r-values. Het HOEFT niet uit te maken, dat het in C(++) wel uitmaakt maakt de zaak minder ortogonaal. Ortogonaliteit komt natuurlijk ook wel met een prijs, namelijk parsen zal wat lastiger worden, al denk ik wel dat static typechecking mogelijk blijft.

Eén probleem met jouw voorstel is dat een if-statement scopes introduceert terwijl een expressie nooit scopes introduceert. Een if-expressie is dus inherent niet orthogonaal, met of zonder scopes.

[MSalters]

Op woensdag 05 juni 2002 15:43 schreef mietje het volgende:

[..]

Het is de auteurs van gcc (2.95.2) wel opgevallen, zij klagen erover in de bijgeleverde documentatie (met een snerend "thanks to the commission for another C vs. C++ incompatibility").

Normaal gesproken klagen de GCC auteurs daarover bij de commissie, maar ik heb net even de lijst gecheckt & er is geen uitstaand issue hierover.

PS. 1 van de GCC ontwikkelaars (Jason Merrill, RedHat) is commissie lid dus het is tot op zekere hoogte gewoon eigen schuld van GCC