[C] Beginnersfout IF... ELSE IF ... ELSE

[YellowOnline]

Dag mensen,

Ik ben op eigen houtje C beginnen leren aan de hand van webpagina's hier en daar (vind geen enkele webpagina echt goed tot dusver). Laatste keer dat ik programmeerde was Turbo Pascal een jaar of 14 geleden, dus mijn voorkennis is vrijwel nihil.
Mijns inziens is oefening de beste kunst, maar helaas heb ik dus niemand die mij kan helpen als ik fouten maak. Vandaar deze post. Ik probeer zelf altijd fouten op te lossen maar hier zit ik nu al een half uur op te kijken en ik zie het probleem écht niet. Voor geoefende programmeurs is dit piece of cake natuurlijk: het is op "Hello World" na het simpelste programmaatje dat er is.

C:

#include <stdio.h>

int main()
{
    int x;
    float a,b,c,d;
    printf ("US naar EU converteertool\n");
    printf ("\n");
    printf ("1) Afstand omzetten\n");
    printf ("2) Gewicht omzetten\n");
    printf ("3) Inhoud omzetten\n");
    printf ("4) Temperatuur omzetten\n");
    printf ("\n");
    printf ("Druk op een andere toets om het programma te beeindigen\n");
    printf ("\n");
    scanf ("%d", &x);
    if (x = 1)
        {
            printf ("Geef een afstand in inches in:");
            scanf ("%f",&a);
            printf ("%3.2f inches komt overeen met %3.2f milimeter", a, a*25.4);
        }
    else if (x = 2)
        {
            printf ("Geef een gewicht in ounce in:");
            scanf ("%f",&b);
            printf ("%3.2f ounce komt overeen met %3.2f gram", b, b*28.349523125);
        }

    else if (x = 3)
        {
            printf ("Geef een inhoud in US gallons in:"); // Bij gebrek aan eenvormige inhoudsmaat werd het maar de gallon...
            scanf ("%f",&c);
            printf ("%3.2f US gallon komt overeen met %3.2f liter", c, c*23.785412);
        }

    else if (x = 4)
        {
            printf ("Geef een temperatuur in Farenheit in:");
            scanf ("%f",&d);
            printf ("%3.2f °F komt overeen met %3.2f °C", d, (d - 32) * (5/9));

        }
    else printf ("Tot ziens!");
    return 0;
}

Ik ben er intussen al achter dat ik hier veel beter het commando switch kan gebruiken, maar desalniettemin zou dit moeten werken. Waarschijnlijk ligt het aan mij, hoewel mijn compiler al enkele keren gekke dingen gedaan heeft waardoor ik soms vrees dat het aan hem ligt (LCC want die van Borland krijg ik maar niet geïnstalleerd op Vista x64 - blijft zeuren om .net Framework 1.1 terwijl er 3.5 op staat).

[Zoijar]

De comparison operator is ==, niet =. Je asigned nu een integer aan x, en dan kijk je of het resultaat al dan niet 0 (false) is. Dus: if (x == 1) {}

[Creepy]

Tip: een toekenning is niet hetzelfde als een vergelijking

offtopic:
Nee, ik geef expres niet direct de oplossing

Damn, verpest Zoijar het net voor me

Yellowonline: zou je voor een eventueel volgend topic Programming Beleid - De Quickstart eens door willen lezen? Je vergeet nu namelijk te vermelden wat er niet lukt en wat je nu zelf al hebt geprobeerd. Nu is het in dit geval vrij makkelijk te zien voor het geoefende oog maar toch..

[ Voor 63% gewijzigd door Creepy op 03-09-2008 09:29 ]

[YellowOnline]

Zoijar schreef op woensdag 03 september 2008 @ 09:25:
De comparison operator is ==, niet =. Je asigned nu een integer aan x, en dan kijk je of het resultaat al dan niet 0 (false) is. Dus: if (x == 1) {}

Euhm, OK, dat was het. Wat op de meeste pagina's als beginnersfout N°1 staat...

Bedankt!

Nu kruip ik ergens beschaamd in een hoekje...

[Enfer]

Je hebt overal staan: if( x = <getal> ), zou dat niet == moeten zijn?

edit:

Spuit 23

[ Voor 19% gewijzigd door Enfer op 03-09-2008 09:28 ]

[Puc van S.]

ben geen expert in C maar moet het niet (x == 1) zijn?

En over framework 1.1, die moet apart geïnstalleerd worden, die zit niet standaard in framework 3.5 meen ik.

Whoops beetje laat, iig meer info over .net framework

[ Voor 15% gewijzigd door Puc van S. op 03-09-2008 09:29 ]

[danslo]

Overigens kan je hier beter een switch gebruiken

[YellowOnline]

Bedankt allemaal voor de snelle reacties

Creepy schreef op woensdag 03 september 2008 @ 09:27:
Yellowonline: zou je voor een eventueel volgend topic Programming Beleid - De Quickstart eens door willen lezen? Je vergeet nu namelijk te vermelden wat er niet lukt en wat je nu zelf al hebt geprobeerd. Nu is het in dit geval vrij makkelijk te zien voor het geoefende oog maar toch..

Oh, ik ga er geen gewoonte van maken om topics te openen hoor, zeker niet na zo'n domme fout. Maar ik ben inderdaad een en ander vergeten vermelden omdat ik nog niet wakker genoeg was
Probleem was dat ongeachte de input hij enkel de eerste IF uitvoerde.
Reeds geprobeerd was: overtypen, opnieuw schrijven, compiler heropstarten (voor ik dat deed gaf ie onbestaande {} errors ) en vooral naar het scherm staren En switch ontdekt. Maar voor ik daar mee aan de slag wou wou ik dit probleem eerst oplossen.

M1lamb3r schreef op woensdag 03 september 2008 @ 09:28:
En over framework 1.1, die moet apart geïnstalleerd worden, die zit niet standaard in framework 3.5 meen ik.

Oh, het leek me nochtans voor de hand liggend dat 1.1 in 3.5 zat Ik zal het straks dan nog 'ns proberen nadat ik arrays geleerd heb

offtopic:
Te weten dat het op verschillende pagina's vermeld staat als typische beginnersfout. Dan heb je zo wat van "jaja, nu weet ik het wel". En dan toch...

[ Voor 63% gewijzigd door YellowOnline op 03-09-2008 10:35 ]

[Heidistein]

Mischien ten overvloede, maar het helpt vaak dingen te begrijpen als je weet wat er eigenlijk gebeurd in de compiler/machinecode.

Als jij het statement 'if (x = 1)' invoerd dan maar je in de eerste plaats (tussen de haakjes) de variable 'x' gelijk aan '1'. Je 'if' test of de opdracht dcie tussen zijn haken staat lukt. In dit geval lukt het heel best van van 'x' '1' te maken. En dus wordt x==1 en loopt het ding door zijn if heen, naar de volgende.

[Zoijar]

Nog twee dingen: het switch commando maakt niet zo heel veel uit; dit kan ook prima, en zou je toch niet beginnen met C++ misschien? Ik vind dit soort dingen eigenlijk moeilijker in C.

[Haan]

Zoijar schreef op woensdag 03 september 2008 @ 10:02:
Nog twee dingen: het switch commando maakt niet zo heel veel uit; dit kan ook prima, en zou je toch niet beginnen met C++ misschien? Ik vind dit soort dingen eigenlijk moeilijker in C.

Aangezien de TS het heeft over .Net, neem ik aan dat hij niet C, maar Visual C++ gebruikt?

[Dricus]

Zoijar schreef op woensdag 03 september 2008 @ 10:02:
[...] en zou je toch niet beginnen met C++ misschien? Ik vind dit soort dingen eigenlijk moeilijker in C.

Ik neem aan dat je het hier over printf/scanf hebt? If/then/else of switch constructies zijn in C++ niet makkelijker of moeilijker dan in C (en daar gaat het topic ten slotte over ).

[ Voor 10% gewijzigd door Dricus op 03-09-2008 10:15 ]

[YellowOnline]

Zoijar schreef op woensdag 03 september 2008 @ 10:02:
Nog twee dingen: het switch commando maakt niet zo heel veel uit; dit kan ook prima, en zou je toch niet beginnen met C++ misschien? Ik vind dit soort dingen eigenlijk moeilijker in C.

Haan schreef op woensdag 03 september 2008 @ 10:04:
[...]

Aangezien de TS het heeft over .Net, neem ik aan dat hij niet C, maar Visual C++ gebruikt?

Nee hoor, ik heb het wel degelijk over C. De Borland C++ compiler leent zich ook uitstekend voor gewone C naar het schijnt (ben er niet zo thuis in tenslotte).
Waarom C? Omdat de stap van C naar C++ niet zo groot is. C is een betere basis programmeren dan C++ - zo las ik

[Dricus]

YellowOnline schreef op woensdag 03 september 2008 @ 10:28:
Waarom C? Omdat de stap van C naar C++ niet zo groot is.

Voor veel ontwikkelaars blijkt de stap van gestructureerd programmeren naar object-georienteerd programmeren toch redelijk groot te zijn. Ik denk dat je dat niet moet onderschatten.

YellowOnline schreef op woensdag 03 september 2008 @ 10:28:
C is een betere basis programmeren dan C++ - zo las ik

Veel moderne programmeertalen zijn object-georienteerd. Ook is het zo, dat je zodra je bijvoorbeeld Windows applicaties wilt maken, je al heel snel in aanraking komt met OO frameworks (MFC voor C++, .NET framework voor .NET talen). Naar mijn bescheiden mening moet je als programmeur zowel goede vaardigheden in het gestructureerd- als in het object-georienteerd programmeren hebben. Van een 'betere' of 'minder goede' basis kun je volgens mij niet echt spreken.

[SeatRider]

YellowOnline schreef op woensdag 03 september 2008 @ 09:23:
(LCC want die van Borland krijg ik maar niet geïnstalleerd op Vista x64 - blijft zeuren om .net Framework 1.1 terwijl er 3.5 op staat).

Framework 3.5 is dan ook niet hetzelfde als 1.1. AFAK bestaan .net 1.1, 2.0, 3.x gewoon naast elkaar gelijktijdig. Je zult hem dan ook los moeten installeren.

[Sebazzz]

.NET 1.1 is obsolete. Deze werd vervangen door .NET 2 en opvolgers, maar door gedeeltelijke rewrites van het framework is .NET 2 en hoger niet compatible met .NET 1.1 en bestaan ze dus naast elkaar hoewel .NET 1.1 niet meer supported is. Alleen de documentatie is er nog. .NET 2 en 3.0 en 3.5 bestaan niet naast elkaar maar zijn gewoon elkaars opvolgers. .NET 1.1 programma's kan je alleen in .NET 1.1 draaien, .NET 2.0 programma's in 2.0, 3.0, en 3.5 en binnenkort ook 4.0.

[Verwijderd]

.NET 3.0 en 3.5 zijn uitbreidingen op .NET 2.0
Als je .NET 3.5 geïnstalleerd hebt kun je er vanuit gaan dat je .NET 2.0 hebt.

.NET 1.1 moet je wel los installeren. dat draait los van .NET 2.0 en .NET 3.x

edit: spuit 33

[ Voor 5% gewijzigd door Verwijderd op 03-09-2008 11:10 ]

[user109731]

Heidistein schreef op woensdag 03 september 2008 @ 09:32:
Als jij het statement 'if (x = 1)' invoerd dan maar je in de eerste plaats (tussen de haakjes) de variable 'x' gelijk aan '1'. Je 'if' test of de opdracht dcie tussen zijn haken staat lukt. In dit geval lukt het heel best van van 'x' '1' te maken. En dus wordt x==1 en loopt het ding door zijn if heen, naar de volgende.

Beetje muggenziften, maar wat er gebeurt is dat (x = 1) de waarde 1 oplevert, en daar word naar gekeken. if(x = 0) 'lukt' prima, x krijgt netjes de waarde 0, maar evalueert toch naar false

[.oisyn]

Heidistein schreef op woensdag 03 september 2008 @ 09:32:
Je 'if' test of de opdracht dcie tussen zijn haken staat lukt.

Onzin. Je test helemaal niet of de assignment lukt. Waar het om gaat is dat een assignment óók een expressie is, en het resultaat van die expressie is de variabele waar je een waarde aan hebt toegekend. Uit de expressie 'x = 1' komt dus 1, en uit de expressie 'x = 0' komt 0. Daarom zal de then-clause van een 'if(x = 0)' nooit worden uitgevoerd (terwijl het volgens jouw definitie wel zou moeten gebeuren, "omdat de assignment gelukt is").

Deze constructie kom je weleens tegen in code:

C++:

if ((x = eenFunctie()) > 5)
{
    doeIets(x);
}

Die feitelijk het resultaat van eenFunctie() opslaat in x, en tegelijkertijd test of dat resultaat groter is dan 5.

YellowOnline schreef op woensdag 03 september 2008 @ 10:28:
Waarom C? Omdat de stap van C naar C++ niet zo groot is. C is een betere basis programmeren dan C++ - zo las ik

Ik denk dat de overstap van C naar C++ behoorlijk groot is (ongeveer net zo groot als de overstap van bijv. C naar C#), en daarnaast zit je het je in C alleen maar moeilijker te maken dan nodig. Ik weet niet waar je dat gelezen hebt, maar als dat een boek was dan stel ik voor het in de prullenbak te deponeren

[ Voor 24% gewijzigd door .oisyn op 03-09-2008 11:51 ]

[MSalters]

Overigens, iets gebruikelijker is een test van de vorm:

C++:

if (int* x = foo())
{
  x->bar = 42;
}

De logica hierachter is dat je in dit geval niet zomaar kunt schrijven foo()->bar=42, maar je moet er nog een NULL test tussenwringen. Dat betekent weer dat je een assignment nodig hebt om het resultaat op te slaan, en die kan mooi in de if( ).

[farlane]

MSalters schreef op woensdag 03 september 2008 @ 15:23:
Overigens, iets gebruikelijker is een test van de vorm:

C++:

if (int* x = foo())
{
  x->bar = 42;
}

Dat lijkt me C++ only of is dit tegenwoordig ook toegestaan in C? Verder natuurlijk geweldig mbt de scope van variabelen.

[TheBorg]

Je kan jezelf ook aanleren om het zo te doen:

C:

if (6 == x)

Is wat ongebruikelijk maar als je dan per ongeluk een = vergeet begint de compiler wel te piepen.

[drm]

.oisyn:
(...) en daarnaast zit je het je in C alleen maar moeilijker te maken dan nodig. Ik weet niet waar je dat gelezen hebt, maar als dat een boek was dan stel ik voor het in de prullenbak te deponeren

Hangt er wel een beetje vanaf wat je precies wilt leren imo. Er zitten wel kanten aan C die je om de oren slaan als je niet heel precies weet waar je mee bezig bent, en dan bedoel ik vooral memory management. Best leerzaam vind ik. Dat is in C++ toch een beetje meer verstopt en in C# merk je er helemaal weinig van.

[.oisyn]

C is zeker een goede taal als je wilt leren hoe het systeem werkt, maar ik zou memory management niet willen scharen onder de noemer "programmeerbasis", en zeker niet iets waar je beginnende programmeurs mee om de oren wilt slaan . Zeker niet gezien het feit dat er tegenwoordig zoveel talen zijn waarbij het vrijwel niet van belang is.

[ Voor 18% gewijzigd door .oisyn op 04-09-2008 00:53 ]

[CyBeR]

TheBorg schreef op donderdag 04 september 2008 @ 00:24:
Je kan jezelf ook aanleren om het zo te doen:

C:

if (6 == x)

Is wat ongebruikelijk maar als je dan per ongeluk een = vergeet begint de compiler wel te piepen.

Ahh, is dat waarom zoveel mensen hun vergelijkingen 'verkeerd om' doen. Zat 't me altijd al af te vragen.

[drm]

.oisyn:
(...) en daarnaast zit je het je in C alleen maar moeilijker te maken dan nodig. Ik weet niet waar je dat gelezen hebt, maar als dat een boek was dan stel ik voor het in de prullenbak te deponeren

Hangt er wel een beetje vanaf wat je precies wilt leren imo. Er zitten wel kanten aan C die je om de oren slaan als je niet heel precies weet waar je mee bezig bent, en dan bedoel ik vooral memory management. Best leerzaam vind ik. Dat is in C++ toch een beetje meer verstopt en in C# merk je er helemaal weinig van.

[.oisyn]

Euh ja dat postte je net ook al

drm, je weet toch dat je een discussie niet kunt winnen door je argumenten simpelweg te herhalen!

[ Voor 58% gewijzigd door .oisyn op 04-09-2008 01:03 ]

[Zoijar]

mwa, vaak genoeg overtuigend herhalen is vaak wel winnend... (ookal weet je dat je geen gelijk hebt)

CyBeR schreef op donderdag 04 september 2008 @ 00:54:
Ahh, is dat waarom zoveel mensen hun vergelijkingen 'verkeerd om' doen. Zat 't me altijd al af te vragen.

Ja, een idioots iets idd. Helaas nog best logisch ook... eigenlijk zelfs beter, al durf ik dat niet te zeggen

[ Voor 87% gewijzigd door Zoijar op 04-09-2008 01:20 ]

[YellowOnline]

drm schreef op donderdag 04 september 2008 @ 00:48:
[...]
Hangt er wel een beetje vanaf wat je precies wilt leren imo. Er zitten wel kanten aan C die je om de oren slaan als je niet heel precies weet waar je mee bezig bent, en dan bedoel ik vooral memory management. Best leerzaam vind ik. Dat is in C++ toch een beetje meer verstopt en in C# merk je er helemaal weinig van.

Dat is eigenlijk de reden waarom ik voor C koos ipv C++ (of C#). Als ik iets leer wil ik het goed leren. Het gaat me minder om er meteen snel iets mooi mee aan te vangen dan om écht te leren hoe alles in elkaar zit. Wat jij zegt ligt in de lijn van wat ik las, nl. dat C++ en C# sneller resultaat geven omdat de talen een hoop dingen in jouw plaats doen. Dat vind ik niet leuk: ik ken graag de processen erachter. Wat ik nu steeds doe als ik iets compile is een output opvragen in assembly om zo te zien wat er precies gebeurd.

Niet dat ik daar momenteel al veel van snap... maar assembly kennen was mijn natte droom als 16-jarige (nou ja, as a matter of speech) en nu ik met C begonnen ben droom ik daar toch stiekem weer van

.oisyn schreef op donderdag 04 september 2008 @ 00:52:
C is zeker een goede taal als je wilt leren hoe het systeem werkt, maar ik zou memory management niet willen scharen onder de noemer "programmeerbasis", en zeker niet iets waar je beginnende programmeurs mee om de oren wilt slaan . Zeker niet gezien het feit dat er tegenwoordig zoveel talen zijn waarbij het vrijwel niet van belang is.

Het gaat me dus om meer dan enkel programmeren, ik wil het gewoon allemaal leren

[ Voor 18% gewijzigd door YellowOnline op 04-09-2008 16:45 ]

[.oisyn]

In dat geval is C je ding

[Hydra]

YellowOnline schreef op donderdag 04 september 2008 @ 14:59:
Dat is eigenlijk de reden waarom ik voor C koos ipv C++ (of C#). Als ik iets leer wil ik het goed leren. Het gaat me minder om er meteen snel iets mooi mee aan te vangen dan om écht te leren hoe alles in elkaar zit. Wat jij zegt ligt in de lijn van wat ik las, nl. dat C++ en C# sneller resultaat geven omdat de talen een hoop dingen in jouw plaats doen. Dat vind ik niet leuk: ik ken graag de processen erachter. Wat ik nu steeds doe als ik iets compile is een output opvragen in assembly om zo te zien wat er precies gebeurd.

Euh, ga dan alsjeblieft zelf dingen in assembly bouwen in plaats van compileroutput te bekijken, die is niet echt leesbaar als je geen basis van assembly kent. Daarnaast leer je volgens mij meer uit een goed boek over hoe een CPU werkt dan door assembly te bestuderen. Just my 0.02E.

[Verwijderd]

Hydra schreef op donderdag 04 september 2008 @ 17:51:
[...]


Euh, ga dan alsjeblieft zelf dingen in assembly bouwen in plaats van compileroutput te bekijken, die is niet echt leesbaar als je geen basis van assembly kent. Daarnaast leer je volgens mij meer uit een goed boek over hoe een CPU werkt dan door assembly te bestuderen. Just my 0.02E.

Ben ik het niet mee eens, het is echt mega omslachtig om in assembly wat basis zaken voor elkaar te krijgen. Bijvoorbeeld wat simpele debug output op het scherm.

Veel beter is het dan om een taal + compiler te kiezen waarin je de basis vrij eenvoudig kunt doen en je ook gebruik kunt maken van inline assembly. Het maakt dan niet specifiek uit welke taal je precies kiest als het maar kan.

Op die manier kun je kleine stukjes assembly uitproberen en precies bekijken wat het resultaat is, zonder eerst al een heel werkend programma te moeten hebben.

De stap daarna is eigenlijk toch wel om te kijken wat een compiler er allemaal van maakt, zeker icm verschillende optimalisatievlaggen. Via een debugger kun je dan ook in real-time (noujah liever wat trager ) zien wat er allemaal gedaan wordt.

[Hydra]

Verwijderd schreef op donderdag 04 september 2008 @ 17:59:
Ben ik het niet mee eens, het is echt mega omslachtig om in assembly wat basis zaken voor elkaar te krijgen. Bijvoorbeeld wat simpele debug output op het scherm.

Ja, wat denk je dat een compiler dan allemaal voor je gaat genereren? Daarnaast is het helemaal niet moeilijk om gewoon een functie te schrijven in assembly welke een string, getal of stel registers voor je output.

[Zoijar]

Voor assembly zou je kunnen beginnen bij de geweldig populaire assembly tutorial van ene ferdi smit, geschreven op 15 jarige leeftijd (13 jaar geleden...)

[ Voor 7% gewijzigd door Zoijar op 04-09-2008 19:00 ]

[YellowOnline]

Zoijar schreef op donderdag 04 september 2008 @ 18:59:
Voor assembly zou je kunnen beginnen bij de geweldig populaire assembly tutorial van ene ferdi smit, geschreven op 15 jarige leeftijd (13 jaar geleden...)

Oh, een wiskundig genie! Ik zal je tutorial eens opzoeken

[Haan]

Zoijar schreef op donderdag 04 september 2008 @ 18:59:
Voor assembly zou je kunnen beginnen bij de geweldig populaire assembly tutorial van ene ferdi smit, geschreven op 15 jarige leeftijd (13 jaar geleden...)

Niet zo bescheiden doen hè

offtopic:
Aardige lijst publicaties trouwens die al op je naam hebt staan

[dusty]

Voor programmeerbasis zou ik zelfs zeggen dat je memory management praktisch volledig moet negeren. In mijn mening is een stap van C++ naar C makkelijker dan van C naar C++. Dit juist omdat je nog steeds wel goede programma's kan maken zonder objecten als je nog steeds zelf in een object georienteerd kan denken. Dan dat je eerst een stijl aanleert, en daarna opeens op een andere manier moet gaan leren denken om te programmeren.

[Zoijar]

Haan schreef op donderdag 04 september 2008 @ 19:15:

offtopic:
Aardige lijst publicaties trouwens die al op je naam hebt staan

Die ja. Ik schaam me tegenwoordig wel voor m'n oude schrijfstijl hehe...

offtopic:
Yep, gaat goed. Er zijn er nog 2 "in review" die er redelijkerwijs wel doorkomen (1 journal versie van de laatste, en een soort van book chapter), en eentje die over 3 weken af moet die alle kanten op kan. Dan nog 2 user-studies oid volgend jaar, en dan klaar

[Verwijderd]

dusty schreef op donderdag 04 september 2008 @ 21:46:
Voor programmeerbasis zou ik zelfs zeggen dat je memory management praktisch volledig moet negeren. In mijn mening is een stap van C++ naar C makkelijker dan van C naar C++. Dit juist omdat je nog steeds wel goede programma's kan maken zonder objecten als je nog steeds zelf in een object georienteerd kan denken. Dan dat je eerst een stijl aanleert, en daarna opeens op een andere manier moet gaan leren denken om te programmeren.

Inderdaad. Je zal van een Java- of C++-programmeur gauw C-code zien in de vorm van:

C:

/* MyClass.h */

struct MyClass
{
    /* variabelen */
};

/* init de struct met variabelen en check of alles gelukt is */
MyClass* MyClass_construct();

/* ruim de boel op */
void MyClass_destruct(MyClass* object);

/* allerlei member functies van je class */
void MyClass_function1(MyClass* object);
int MyClass_function2(MyClass* object);

(Ik heb weinig ervaring met C, dus als in deze bare-bones code al fouten zitten, dan verbaast het me niets. )

edit:
Ik denk dat je aan de functies wel een pointer naar je struct mee moet geven, want het zijn natuurlijk geen echte members.

[ Voor 6% gewijzigd door Verwijderd op 04-09-2008 23:27 ]

[Hydra]

Haan schreef op donderdag 04 september 2008 @ 19:15:
[...]

Niet zo bescheiden doen hè

offtopic:
Aardige lijst publicaties trouwens die al op je naam hebt staan

Nice Dat is echt zo'n veel betere basis dan gewoon naar compileroutput te kijken!

[Guldan]

@Dot Ik hoop dat die persoon dan C++ gaat gebruiken dan oo simuleren in C. Maar dat is mijn persoonlijke mening.

[farlane]

Verwijderd schreef op donderdag 04 september 2008 @ 23:21:
Inderdaad. Je zal van een Java- of C++-programmeur gauw C-code zien in de vorm van ... etc ...

Moach, afgezien van de vreselijke naamgeving is die manier ook voor een C programmeur niet vreemd.

Zie de struct pointer als de context ( vb een linked list ) en de functies als de bewerkingen op die context ( add, remove etc )

[Verwijderd]

Guldan schreef op vrijdag 05 september 2008 @ 10:19:
@Dot Ik hoop dat die persoon dan C++ gaat gebruiken dan oo simuleren in C. Maar dat is mijn persoonlijke mening.

Ja, ik zou ook denken: "de enige reden om C te gebruiken in plaats van C++, is omdat C++ zoveel ingewikkelder is". Maar dat is niet echt een goede reden: alles wat in C werkt, werkt ook in C++, en je hoeft alleen maar de dingen van C++ te gebruiken die je handig vindt natuurlijk.

Mijn voorbeeld zou in C++ gewoon zijn:

C++:

/* MyClass.h */

struct MyClass
{
    /* variabelen */

    /* init de struct met variabelen en check of alles gelukt is */
    MyClass();

    /* ruim de boel op */
    ~MyClass();

    /* allerlei member functies van je class */
    void function1();
    int function2();
};

Je hebt dan nog niets gedaan met public/private, inheritance, of andere ingewikkelde dingen. Gewoon C, maar dan veilig. Maargoed, om de een of andere reden zijn sommige projecten in C, en dan wil je toch graag gestructureerd werken.

En als we dan toch zeggen: "gebruik C++ in plaats van C", waarom dan niet meteen Java gebruiken in plaats van C++? Dan heb je tenminste een garbage collector die je geheugen voor je opruimt. Maar dat valt ook in C++ (of zelfs in C ) te simuleren door zelf een garbage collector te schrijven.

farlane schreef op vrijdag 05 september 2008 @ 13:00:
[...]


Moach, afgezien van de vreselijke naamgeving is die manier ook voor een C programmeur niet vreemd.

Hoezo is de naamgeving niet goed? Ik gebruik camelcase als naamgeving, waarbij de classes met een hoofdletter beginnen en variabelen met een kleine letter (en constanten VOLLEDIG_UPPERCASE). Aangezien je in C handmatig moet aangeven dat een functie een member is van een class, geef ik gewoon de classnaam er als prefix bij. Anders krijg je problemen met functies uit verschillende classes die bijvoorbeeld "next" heten.

[ Voor 18% gewijzigd door Verwijderd op 05-09-2008 13:09 ]

[drm]

.oisyn:
Euh ja dat postte je net ook al

drm, je weet toch dat je een discussie niet kunt winnen door je argumenten simpelweg te herhalen!

Hm, ik hoopte dat je er in zou trappen . Raar caching dingetje , ik dacht ook al gepost te hebben, maar toen ik het topic weer bekeek stond mijn post er niet in. Ik was al blij dat het textveld nog gevuld was na een paar keer back klikken.
Maar ben het verder wel met je eens, dus dat scheelt weer

DOT:
Je hebt dan nog niets gedaan met public/private, inheritance, of andere ingewikkelde dingen. Gewoon C, maar dan veilig. Maargoed, om de een of andere reden zijn sommige projecten in C, en dan wil je toch graag gestructureerd werken.

Ik vind inheritance en (daarmee) polymorphisme toch wel essentieel voor een object-georienteerde architectuur, ik ben wel benieuwd hoe je dat zou simuleren ....

En als we dan toch zeggen: "gebruik C++ in plaats van C", waarom dan niet meteen Java gebruiken in plaats van C++? Dan heb je tenminste een garbage collector die je geheugen voor je opruimt. Maar dat valt ook in C++ (of zelfs in C ) te simuleren door zelf een garbage collector te schrijven.

Java is een hele goede taal om OO te leren programmeren, imo, omdat je niet anders kunt en div. design patterns worden je regelmatig onder de neus gesmeerd, vanuit de standaard api's. Dat is wel leuk, maar tegelijkertijd niet erg pragmatisch, wat dat betreft leer je met C++ volgens mij wel dat OO niet de heilige graal is.

Hoezo is de naamgeving niet goed? Ik gebruik camelcase als naamgeving, waarbij de classes met een hoofdletter beginnen en variabelen met een kleine letter (en constanten VOLLEDIG_UPPERCASE). Aangezien je in C handmatig moet aangeven dat een functie een member is van een class, geef ik gewoon de classnaam er als prefix bij. Anders krijg je problemen met functies uit verschillende classes die bijvoorbeeld "next" heten.

Ik denk dat bedoeld wordt dat je aan de naamgeving al kunt zien dat de taal iets heel basics in de trant van namespaces / packages mist *. Maar misschien praat ik voor mijn beurt.


*) Iets wat in PHP overigens ook schromelijk de mist in gaat, getuige de naamgevingsconventies (die door de halve wereld overgenomen worden) binnen Zend framework.... aiaiai. Laat ze maar gauw opschieten met die namespaces

[whoami]

Sebazzz schreef op woensdag 03 september 2008 @ 11:05:
.NET 1.1 is obsolete. Deze werd vervangen door .NET 2 en opvolgers, maar door gedeeltelijke rewrites van het framework is .NET 2 en hoger niet compatible met .NET 1.1 en bestaan ze dus naast elkaar hoewel .NET 1.1 niet meer supported is. Alleen de documentatie is er nog. .NET 2 en 3.0 en 3.5 bestaan niet naast elkaar maar zijn gewoon elkaars opvolgers. .NET 1.1 programma's kan je alleen in .NET 1.1 draaien, .NET 2.0 programma's in 2.0, 3.0, en 3.5 en binnenkort ook 4.0.

Een .NET 2.0 app kan je perfect in 3.0 draaien imho.
En een .NET 1.1 app kan je ook perfect in 2.0 draaien.

[whoami]

drm schreef op zaterdag 06 september 2008 @ 18:16:

[...]
Ik vind inheritance en (daarmee) polymorphisme toch wel essentieel voor een object-georienteerde architectuur, ik ben wel benieuwd hoe je dat zou simuleren ....

Pas op! straks komt .oisyn hier weer mompelen over vtables en dat het wel mogelijk is.

[Verwijderd]

Inderdaad, vtables. Maar dat is inderdaad een essentieel aspect van OO dat nogal irritant is met C. Je zou daarvoor nog GObject kunnen gebruiken.

Maar een belangrijk onderdeel van OO is ook simpelweg het logisch groeperen van data en functionaliteit. Dat zou ik niet eens echt encapsulation willen noemen, aangezien je overal bij kan. Inheritance en polymorphisme is toch iets wat je niet zo vaak echt nodig hebt.

[Zoijar]

drm schreef op zaterdag 06 september 2008 @ 18:16:
Ik vind inheritance en (daarmee) polymorphisme toch wel essentieel voor een object-georienteerde architectuur, ik ben wel benieuwd hoe je dat zou simuleren ....

Net zoals unix dat doet, een extra level of indirection, met structs van functie pointers.

C:

typedef struct {
   void (*foo)(void*);
} A_vtbl;

typdef struct {
   void (*foo)(void*);
} B_vtbl;

typedef struct {
   A_vtbl* vtbl;
   int x;
} A_class;

typedef struct {
   B_vtbl* vtbl;
   int x;
   int y;
} B_class;

void f_a_foo(void* self) {
   A_class* this = (A_class*)self;
   this->x = 1;
}

void f_b_foo(void* self) {
   B_class* this = (B_class*)self;
   this->x = 2;
}

static A_vtbl iA_vtbl = {f_a_a};
static B_vtbl iB_vtbl = {f_b_a};

// ctors
A_class* ctor_A() {
   A_class* a = new A_class;
   a->vtbl = &iA_vtbl;
  return a;
}

B_class* ctor_B() {
   B_class* b = new B_class;
   b->vtbl = &iB_vtbl;
  return b;
}

// app

void dostuff(A* a) {
   a->x = 0;
   // virtual call
   a->vtbl->foo(a);
}

// construct
A_class* A = ctor_A();
B_class* B = ctor_B();

dostuff(A);
dostuff((A*)B);

Even uit het hoofd zonder te testen, kunnen wat foutjes inzitten.

Encapsulatie kan je verkijgen dmv statics zonder external linkage. Wederom iets dat vollop in de unix kernel wordt gebruikt. Ook kan je het verkrijgen door dingen wel of niet in de header files te plaatsen. Op die manier kan je nog een soort van "friend" simuleren; een class die gewoon opgeeft dat iets WEL bestaat met external linkage, ookal komt het niet in de headers voor.

[ Voor 12% gewijzigd door Zoijar op 06-09-2008 19:17 ]

[Sebazzz]

whoami schreef op zaterdag 06 september 2008 @ 18:43:
[...]

Een .NET 2.0 app kan je perfect in 3.0 draaien imho.

Ik zeg toch niet dat 3.0 niet backwards compatible is? Ik zeg dat dat juist wel zo is.

En een .NET 1.1 app kan je ook perfect in 2.0 draaien.

Nee hoor. Ik moet nog steeds framework 1.1 hebben anders draaien die toepassingen hier niet. .NET 2 is niet backwards compatible.

[YellowOnline]

Sebazzz schreef op zaterdag 06 september 2008 @ 20:45:
[...]

Ik zeg toch niet dat 3.0 niet backwards compatible is? Ik zeg dat dat juist wel zo is.

[...]
Nee hoor. Ik moet nog steeds framework 1.1 hebben anders draaien die toepassingen hier niet. .NET 2 is niet backwards compatible.

Inderdaad. Ik heb door de 1.1 naast de 3.5 te installeren de Borland compiler aan de praat gekregen. Blijkbaar staat die 1.1 inderdaad los van de rest en is alles vanaf 2.0 niet-backward compatibel.

[whoami]

Hmm, idd je hebt gelijk ...

[paulh]

CyBeR schreef op donderdag 04 september 2008 @ 00:54:
[...]


Ahh, is dat waarom zoveel mensen hun vergelijkingen 'verkeerd om' doen. Zat 't me altijd al af te vragen.

Bijvoorbeeld in java heeft het bij Strings ook nog een extra voordeel dat je geen check hoeft te doen of het te testen object misschien ook nog null is. Zo is

Java:

if ("text".equals(x)) { 
// doSomething
}

gelijk aan:

Java:

if (x != null && x.equals("text") {
// doSomething)
}

Ik heb al aardig wat nullpointer exceptions voorbij zien komen omdat mensen vergeten te checken op null.

[Hydra]

whoami schreef op zaterdag 06 september 2008 @ 18:43:
Een .NET 2.0 app kan je perfect in 3.0 draaien imho.
En een .NET 1.1 app kan je ook perfect in 2.0 draaien.

In theorie. Helaas blijkt in de praktijk dat er een paar dingen missen waardoor het soms noodzakelijk is ook 1.1 op een systeem te installeren. Een paar van onze tools werken niet onder 2.0 en daar is het dus noodzakelijk om 1.1 ook te installeren.

[whoami]

TheBorg schreef op donderdag 04 september 2008 @ 00:24:
Je kan jezelf ook aanleren om het zo te doen:

C:

if (6 == x)

Is wat ongebruikelijk maar als je dan per ongeluk een = vergeet begint de compiler wel te piepen.

In C# wordt er een warning (of zelfs een error) gegeven als je

code:

if( x = 6 )

schrijft.

Geven moderne C of C++ compilers hier dan ook geen warning voor ? Indien ja, dan vind ik het onnodig om nog dergelijke code te schrijven, die imho veel minder leesbaar is.

[Woy]

whoami schreef op woensdag 10 september 2008 @ 12:14:
[...]

In C# wordt er een warning (of zelfs een error) gegeven als je

code:

if( x = 6 )

schrijft.

Geven moderne C of C++ compilers hier dan ook geen warning voor ? Indien ja, dan vind ik het onnodig om nog dergelijke code te schrijven, die imho veel minder leesbaar is.

In C# word er denk een error gegeven want het statement x = 6 heeft een int als result en niet een boolean, en dus is het geen valide code. Met x = true zou het wel valide code zijn, en mischien zou een warning daar op zijn plaats zijn.

In C/C++ is het gewoon een correcte constructie ( al is het met een constante wel een beetje vreemd ) waar het vreemd zou zijn als het een warning oplevert, aangezien je die constructie dan niet kan gebruiken zonder warnings te krijgen.

[.oisyn]

C#:

static void Main(string[] args)
{
    bool a, b;
    if (a = args.Length > 0)
    {
    }

    if (b = true)
    {
    }
}

Levert (naast wat ongerelateerde warnings over unused local variables) 1 warning op:

warning CS0665: Assignment in conditional expression is always constant; did you mean to use == instead of = ?

Die van b dus.

[ Voor 9% gewijzigd door .oisyn op 10-09-2008 13:01 ]

[Woy]

Maar dat is meer dat het altijd constant is.

C#:

bool b = true;
void Test()
{
    bool a;
    if( a = b ){ }
}

levert geen warning op. ( Al geeft Resharper er wel een warning voor )

[edit]
O zo te zien bedoelde je dat ook met

C#:

if (a = args.Length > 0) { }

[ Voor 32% gewijzigd door Woy op 10-09-2008 13:21 ]

[.oisyn]

Euh ja, ik was het dan ook helemaal met je eens