[c++] Probleem met char waarde

[Verwijderd]

Op maandag 04 maart 2002 15:09 schreef DolleDries het volgende:
..Euh....kan aan mij liggen maar MOET het c++ zijn ?
Met stdio kan het namelijk ook...
int iMaand, iDag, iYear;

sscanf(datum,"%d/%d/%d",&iMaand,&iDag,&iYear);

..untzoweiter...

Ja het moet c++ worden.

[DolleDries]

Zie laatste reply mod

[Verwijderd]

Op maandag 04 maart 2002 15:12 schreef Sjonny het volgende:
ook best wel logisch dat je crap op je scherm krijgt, want je alloced helemaal geen memory voor je char*. nu heb je twee char* vars waarmee je lekker over je andere data gaat schrijven.

Hmmm ja, klopt... Ook wel logisch dan. Maar enig idee hoe het dan op te lossen is?

[Verwijderd]

Op maandag 04 maart 2002 15:13 schreef DolleDries het volgende:
Zie laatste reply mod

Ja, je hebt gelijk. Nu loopt ie em 8 keer door en krijg ik nog meer onzin op het scherm. 't Gaat nog niet helemaal zoals ik wil

[Goodielover]

volgens mij is de toekenning in while loop verkeerd.
Niet datum[i]= tijdelijk[i], maar precies anders om:
tijdelijk[i] = datum[i]

[code]
char *datum,*tijdelijk;
unsigned long datum2;
int i=1;

//datum = printf("%s",tmpbuf);
datum = "12/12/81";
//tijdelijk = "";

do {
if (datum[i] !='/')
datum[i] = tijdelijk[i];
else
i++;
i++;
}while (i==8);

datum2 = atoi(tijdelijk);
cout << datum;
cout << tijdelijk;
cout << datum2;

[igmar]

char *datum,*tijdelijk;
unsigned long datum2;
int i=1;

//datum = printf("%s",tmpbuf);
datum = "12/12/81";
//tijdelijk = "";

do {
if (datum[i] !='/')
datum[i] = tijdelijk[i];
else
i++;
i++;
}while (i==8);

datum2 = atoi(tijdelijk);
cout << datum;
cout << tijdelijk;
cout << datum2;

a) Arrays tellen beginnen in C / C++ bij 0, niet bij 1.
b) while (datum[i] != '\0') is beter.
c) char[] tijdelijk word niet gealloceerd
d) De i++ in de else is niet correct
e) Je moet voor tijdelijk een aparte index bijhouden, aangezien je op verschillende plaatsen in de string kan wezen. Indien er een / instaan moet je het niet copieren, maar ook de index van tijdelijk NIET ophogen.
f) Je sluit de string niet af met een 0
g) atoi() is lelijk, je kan niet zien of de conversie goed is gegaan.

beter is :

code:

char * endptr;

datum2 = (int) strtol(tijdelijk, &endptr, 10);
if (*endptr != '\0')
     printf("Omzetting niet goed vanaf %s", endptr);

[Sjonny]

ipv alleen een pointer te maken, alloc je ook wat ruimte:

code:

char datum[9]; // "12/12/12" is 8+'\0' chars lang
char tijdelijk[7]; // 2x '/' minder is 7 chars :)

quite easy toch?

[curry684]

Op maandag 04 maart 2002 15:09 schreef DolleDries het volgende:
..Euh....kan aan mij liggen maar MOET het c++ zijn ?
Met stdio kan het namelijk ook...

GRRRRRRRRRRRRR!!!!!!!!!!

C++ is een UITBREIDING van C en het is dus ALLESBEHALVE verboden om C-libraries in C++ te gebruiken!!!

* curry684 wordt zo achterlijk getikt van die mensen die denken dat C++ een andere taal is dan C maar toevallig dezelfde grammatica, achtergrond en structuur volgt, en dan ook nog dezelfde standaardlibs meelevert.

[Verwijderd]

Op maandag 04 maart 2002 15:17 schreef Sjonny het volgende:
ipv alleen een pointer te maken, alloc je ook wat ruimte:

code:

char datum[9]; // "12/12/12" is 8+'\0' chars lang
char tijdelijk[7]; // 2x '/' minder is 7 chars :)

quite easy toch?

Dan krijg ik een foutmelding waar ik absoluut niks mee kan:

(77) : error C2106: '=' : left operand must be l-value

Hier dus: datum = "12/12/81";

[DolleDries]

Op maandag 04 maart 2002 15:17 schreef curry684 het volgende:

[..]

GRRRRRRRRRRRRR!!!!!!!!!!

C++ is een UITBREIDING van C en het is dus ALLESBEHALVE verboden om C-libraries in C++ te gebruiken!!!

* curry684 wordt zo achterlijk getikt van die mensen die denken dat C++ een andere taal is dan C maar toevallig dezelfde grammatica, achtergrond en structuur volgt, en dan ook nog dezelfde standaardlibs meelevert.

Euh....U go tell me (ik programmeer al 8 jaar in C & ++ ...)
Vraag was meer bedoeld om te achterhalen of de persoon in kwestie dit op moet/wil oplossen middels een C++ routine en niet doorgebruik maken van een standaard C routine.
..dus..

[Verwijderd]

Op maandag 04 maart 2002 15:16 schreef igmar het volgende:

[..]

a) Arrays tellen beginnen in C / C++ bij 0, niet bij 1.
b) while (datum[i] != '\0') is beter.
c) char[] tijdelijk word niet gealloceerd
d) De i++ in de else is niet correct
e) Je moet voor tijdelijk een aparte index bijhouden, aangezien je op verschillende plaatsen in de string kan wezen. Indien er een / instaan moet je het niet copieren, maar ook de index van tijdelijk NIET ophogen.
f) Je sluit de string niet af met een 0
g) atoi() is lelijk, je kan niet zien of de conversie goed is gegaan.

a) ff vergeten...
b) Hmmm kan ja, ik verander 't wel ff
c) Wat bedoel je daarmee?
d) klopt, hij gaat nu domweg een nummer ophogen
e)Zou je dat ff uit willen leggen, nu kan ik je niet volgen
f)euh...
g) klopt, ik verander het.

[TiG]

Op maandag 04 maart 2002 15:17 schreef Sjonny het volgende:
ipv alleen een pointer te maken, alloc je ook wat ruimte:

code:

char datum[9]; // "12/12/12" is 8+'\0' chars lang
char tijdelijk[7]; // 2x '/' minder is 7 chars :)

quite easy toch?

Ik ben in c++ echt een n00b. Maar dit klopt volgens mij niet: waarom doe je datum[9] ipv 8? Als je 8 doet bevat de array toch 9 items? Das toch genoeg om ook nog de null byte op te slaan of heb ik nou iets gemist?

[Verwijderd]

Op maandag 04 maart 2002 15:39 schreef TiG het volgende:

[..]

Ik ben in c++ echt een n00b. Maar dit klopt volgens mij niet: waarom doe je datum[9] ipv 8? Als je 8 doet bevat de array toch 9 items? Das toch genoeg om ook nog de null byte op te slaan of heb ik nou iets gemist?

Das niet echt m'n grootste probleem....

[Verwijderd]

Op maandag 04 maart 2002 15:17 schreef curry684 het volgende:
GRRRRRRRRRRRRR!!!!!!!!!!

C++ is een UITBREIDING van C en het is dus ALLESBEHALVE verboden om C-libraries in C++ te gebruiken!!!

* curry684 wordt zo achterlijk getikt van die mensen die denken dat C++ een andere taal is dan C maar toevallig dezelfde grammatica, achtergrond en structuur volgt, en dan ook nog dezelfde standaardlibs meelevert.

Dat neemt niet weg dat je een 0 van mij krijgt als je C libraries gebruikt terwijl er ook C++ libraries beschikbaar zijn. C++ levert de C standaard libs voor backward-compatability en niet als main resource, maw. de C libs zijn depricated. Hoe handig printf en consorten ook zijn, ze zijn gevaarlijk (typesafety, buffer overflows); daarom heeft C++ iostreams die deze problemen oplossen. Men schrijft dit soort libraries niet voor niets!

[Verwijderd]

Op maandag 04 maart 2002 15:43 schreef mietje het volgende:

[..]

Dat neemt niet weg dat je een 0 van mij krijgt als je C libraries gebruikt terwijl er ook C++ libraries beschikbaar zijn. C++ levert de C standaard libs voor backward-compatability en niet als main resource, maw. de C libs zijn depricated. Hoe handig printf en consorten ook zijn, ze zijn gevaarlijk (typesafety, buffer overflows); daarom heeft C++ iostreams die deze problemen oplossen. Men schrijft dit soort libraries niet voor niets!

Ja precies, dat geloof ik allemaal wel. Maar ik zou graag nu met één van die geschreven libraries mijn probleem oplossen...

[Verwijderd]

Ik nu dit staan:

code:

char *datum,tijdelijk[7];
unsigned long datum2;
int i=0;

*datum = printf("%s",tmpbuf);
//datum = "12/12/81";
//tijdelijk = "";

do {
    if (datum[i] !='/')
        tijdelijk[i] = datum[i];
    else 
        i++;
    i++;
}while (i<8);


//datum2 = atoi(datum);

//cout << datum2 << endl;
cout << datum << endl;
cout << tijdelijk;

Maar dit klopt niet...

[Olaf van der Spek]

Dit dan?

code:

#include <iostream>

using namespace std;

int main()
{
    const char* datum = datum = "12/12/81";
    char tijdelijk[7];

    const char* r = datum;
    char* w = tijdelijk;
    char v;
    while (v = *r++)
    {
        if (v != '/')
            *w++ = v;
    }
    *w = 0;
    
    int datum2 = atoi(tijdelijk);
    
    cout << datum2 << endl;
    cout << datum << endl;
    cout << tijdelijk;

    return 0;
}

[MSalters]

Op maandag 04 maart 2002 15:17 schreef curry684 het volgende:

[..]

GRRRRRRRRRRRRR!!!!!!!!!!

C++ is een UITBREIDING van C en het is dus ALLESBEHALVE verboden om C-libraries in C++ te gebruiken!!!

* curry684 wordt zo achterlijk getikt van die mensen die denken dat C++ een andere taal is dan C maar toevallig dezelfde grammatica, achtergrond en structuur volgt, en dan ook nog dezelfde standaardlibs meelevert.

GRRRRRRRRRRRRR!!!!!!!!!!
In tegenstelling tot C, zijn de C++ libraries wel typesafe en het is dus ALLESBEHALVE verstandig om C-libraries in C++ te gebruiken!!!

* MSalters wordt zo achterlijk getikt van die mensen die denken dat omdat C programma's compileren in C++, dat de ideeen uit C nog steeds de beste zijn.

[MSalters]

Op maandag 04 maart 2002 14:55 schreef jeroenbeekman het volgende:
Ik heb een char waarde "12/12/81", daar wil ik de / uithalen

code:

std::remove_copy( src_begin, src_end, dest_begin, '/' )

Simpel.

[Sjonny]

Op maandag 04 maart 2002 15:39 schreef TiG het volgende:

[..]

Ik ben in c++ echt een n00b. Maar dit klopt volgens mij niet: waarom doe je datum[9] ipv 8? Als je 8 doet bevat de array toch 9 items? Das toch genoeg om ook nog de null byte op te slaan of heb ik nou iets gemist?

en tellen is ook een kunst. [8] heeft dus 8 plaatsen van 0..7. "12/12/12" zijn 8 chars, en met een '\0' erbij zijn dat er 9, dus vandaar [9].

[MSalters]

Op maandag 04 maart 2002 17:27 schreef Sjonny het volgende:

[..]

en tellen is ook een kunst. [8] heeft dus 8 plaatsen van 0..7. "12/12/12" zijn 8 chars, en met een '\0' erbij zijn dat er 9, dus vandaar [9].

Niet tellen is een nog grotere kunst.

char datum[]="12/12/13"; maakt datum precies groot genoeg,
en char destination[sizeof(datum)]; geeft je een buffer die
ook groot genoeg is. Dat werkt natuurlijk niet in "echte" programma's, maar echte C++ programma's werken ook niet met char[]s als buffers.

[Soultaker]

Om te beginnen: Plaats je code tussen [ code ] tags!

Verder snap ik niet eens wat 't idee achter het algoritme is.

1. Je initialiseert i op 1. Vervolgens begin je een whilelus waarin i met 1 of 2 kan worden verhoogd, zodat de while-expressie i==8 ALTIJD false is en de loop dus altijd eens doorlopen wordt.

2. Je stopt een constante string in datum. Die mag je NIET wijzigen! Dit doe je toch (datum[i]=...). Hier hoort je compiler voor te waarschuwen.

3. 'tijdelijk' wordt nooit geinitialiseerd, maar wel gebruikt. Dat kan dus onmogelijk goed gaan.

4. Wat je met die i++jes doet is me een compleet raadsel.

Hoe KOM je op dit algoritme??? Heb je pre/post-condities opgesteld? Waarom staan die dan niet in de code? En 't meest belangrijke: als je C kan coden, waarom heb je dan zelf niet gezien dat deze code van geen kant klopt?

[.oisyn]

Op maandag 04 maart 2002 17:17 schreef MSalters het volgende:

[..]

GRRRRRRRRRRRRR!!!!!!!!!!
In tegenstelling tot C, zijn de C++ libraries wel typesafe en het is dus ALLESBEHALVE verstandig om C-libraries in C++ te gebruiken!!!

* MSalters wordt zo achterlijk getikt van die mensen die denken dat omdat C programma's compileren in C++, dat de ideeen uit C nog steeds de beste zijn.

GRRRRRRRRRRRRR!!!!!!!!!!
ook al zijn ze niet type-safe, ze zijn verrekte handig, en werken een stuk intuitiever dan iostreams. En ze zijn aanwezig, dus waarom niet gebruiken?

* .oisyn wordt zo achterlijk getikt van die mensen die persee of het een of het ander willen, en die niet begrijpen dat je het ook gewoon prima kunt combineren



* .oisyn vindt pure C-code sowieso al eleganter dan C++-code, omdat er gewoon wordt gedaan wat er staat, en er gebeuren dus geen onverwachte dingen omdat er bijvoorbeeld een operator is geoverload of er een exception wordt gethrowed (wat overigens niet zegt dat OiSyN exceptions en operator overloading niet handig vindt )

[igmar]

a) ff vergeten...
b) Hmmm kan ja, ik verander 't wel ff
c) Wat bedoel je daarmee?

Je begint gewoon grofweg te copieeren naar een lokatie ergens in je geheugen. *tijdelijk is gewoon een random geheugenadres.

Geheugen moet je eerst allocateren voordat je er wat mee doet (levert anders core files / ongeldige bewerkingen en meer op)

d) klopt, hij gaat nu domweg een nummer ophogen
e)Zou je dat ff uit willen leggen, nu kan ik je niet volgen

De nieuwe array is per definitie niet de oude array :

12/12/81

word

121281

In jouw geval krijg je :

12*12*81 (* is random niet gedefinieerd iets).

Daarom moet je dus twee indexes bijhouden.

f)euh...

Strings zijn een array van karakters waarbij het einde aangegeven word door een 0 (binary dus).

g) klopt, ik verander het.

[curry684]

Op maandag 04 maart 2002 schreven een hoop mensen het volgende:
GRRRRRRRRRRRRR!!!!!!!!!!

Kunnen we dit even kort afkappen met de conclusie dat (s)printf heilig is en we niet moeten kankeren als mensen C-libs in C++ code gebruiken?

Als je hier niet mee eens bent mag je vanaf vandaag de hele Win32 en Linux API's niet meer in C++ gebruiken daar deze allemaal voor 100% in C zijn geschreven. Evenzo mag je dan ook geen C++ frameworks gebruiken die deze C-functies encapsuleren want dat is ook stout! Enjoy

[curry684]

Op maandag 04 maart 2002 15:45 schreef jeroenbeekman het volgende:
Ja precies, dat geloof ik allemaal wel. Maar ik zou graag nu met één van die geschreven libraries mijn probleem oplossen...

code:

extern "C" {

int StripInt(char* p_InputString)
{
char*    l_Buffer  = (char*)calloc(strlen(p_InputString) + sizeof(char));
char*    l_Pointer = l_Buffer;
int l_Result;

// Loop over the local string copying anything numerical
do
  {
  if(*p_InputString >= '0' || *p_InputString <= '9')
    *(l_Pointer++) = *p_InputString;
  }
while(*(++p_InputString));

// Convert to numerical and release buffer
l_Result = atoi(l_Buffer);
free(l_Buffer);
return l_Result;
}

}

Geen garanties, ik heb het niet gecompileerd of niets, dit is pure C-inspiratie in de forum text-editor

[Soultaker]

Ik zou het liever zo doen (in C):

code:

char *p;
int result=0;
for(*p=string;*p;++p)
  if((*p>='0')&&(*p<='9'))
    result=(10*result)+(*p-'0');

Dat is een stuk efficiënter.

PS. Curry bedoelt waarschijnlijk malloc ipv calloc en && ipv ||.

edit:
* In de code toegevoegd =)

[.oisyn]

code:

for(*p=string;*p;++p)

hmmm je bedoelt zeker dit:

code:

for (p = string; *p; ++p)

(eerste * moet weg )

code:

result=(10*result)+(*p-'0');

over efficientie gesproken:

code:

result = (result << 3) + (result << 1) + (*p - '0');

[Verwijderd]

Op maandag 04 maart 2002 15:43 schreef mietje het volgende:

[..]

Dat neemt niet weg dat je een 0 van mij krijgt als je C libraries gebruikt terwijl er ook C++ libraries beschikbaar zijn. C++ levert de C standaard libs voor backward-compatability en niet als main resource, maw. de C libs zijn depricated. Hoe handig printf en consorten ook zijn, ze zijn gevaarlijk (typesafety, buffer overflows); daarom heeft C++ iostreams die deze problemen oplossen. Men schrijft dit soort libraries niet voor niets!

Slechte leraar ben je dan. Het feit dat win32's slappe mongool C libraries toevallig onstabiel zijn zegt niks over C als taal. Onder linux is C enorm stabiel, inclusief NULL checks et all. iostream is een DOS-only iets. Men schrijft die libraries dus wel voor niets

En C-libs deprecated? Onder windows ja. Gnome is 90% C. FYI

[Verwijderd]

Op maandag 04 maart 2002 23:30 schreef beelzebubu het volgende:
iostream is een DOS-only iets.

Onzin. Iostreams heeft vooral met buffering en interpretatie van bytestreams te maken, zaken die vandaag de dag nog 100% relevant zijn.

[Verwijderd]

Op maandag 04 maart 2002 23:10 schreef OiSyN het volgende:

code:

result=(10*result)+(*p-'0');

over efficientie gesproken:

code:

result = (result << 3) + (result << 1) + (*p - '0');

Dat soort optimalisaties kun je imho beter aan de compiler overlaten, aangezien ze je sourcecode er niet duidelijker op maken.

[Orphix]

Op maandag 04 maart 2002 23:30 schreef beelzebubu het volgende:
Slechte leraar ben je dan. Het feit dat win32's slappe mongool C libraries toevallig onstabiel zijn zegt niks over C als taal. Onder linux is C enorm stabiel, inclusief NULL checks et all. iostream is een DOS-only iets. Men schrijft die libraries dus wel voor niets

En C-libs deprecated? Onder windows ja. Gnome is 90% C. FYI

Tuurlijk is de taal C niet 'instabiel' ... het nodigt alleen uit tot verkeerd gebruik. En C is daar erg goed in. Tuurlijk als je perfect om kan gaan met sprintf, je checkt overal en altijd op return-values, buffer overflows, etc dan is het super stabiel. Helaas doet niet iedereen dat (including me) omdat we toch luie wezens zijn.

De libraries van C++ zijn t.o.v. de C libraries een enorme vooruitgang op het gebied van fout afhandeling. Door de structuur kan bij compile-tijd al heel veel typische programmeurs foutjes voorkomen worden.
Ik vind het logisch dat een leraar het fout rekent wanneer statische buffers worden gebruikt wanneer er ook de (in veel gevallen) superieure vector of list gebruikt kan worden.

De voorbeelden die je noemt slaan kant noch wal, ik ken ook hele stabiele C++ programma's. Dat Gnome voor 90% uit C bestaat betekent enkel dat men in C is begonnen en nu niet meer 'zomaar' naar C++ kan overstappen (plus daarbij de unix programmeurs tegen de haren in te strijken).

[Soultaker]

Op maandag 04 maart 2002 23:10 schreef OiSyN het volgende:

code:

for(*p=string;*p;++p)

hmmm je bedoelt zeker dit:

code:

for (p = string; *p; ++p)

(eerste * moet weg )

Nee, die spaties bedoel ik echt niet. Die * stond daar wel onterecht. Thanks =)

code:

result=(10*result)+(*p-'0');

over efficientie gesproken:

code:

result = (result << 3) + (result << 1) + (*p - '0');

Ik gebruikte de term efficiëntie omdat ik de geheugencomplexiteit van het algoritme van O(N) tot O(1) had teruggebracht en een signficant deel van de constante factor in de tijdcomplexiteit had afgehaald.

Ik ben niet echt een voorstander van optimalisaties die de betekenis van de code onzichtbaar maken om een marginale snelheidswinst te verkrijgen zonder dat de feitelijke complexiteit van het algoritme verandert.

Verder heb ik de vrijheid genomen om de volgende code even door gcc (-O2) te halen:

code:

int main()
{
  int x;
  char y[20];
  scanf("%i %s",&x,y);
//  x=(10*x)+(*y-'0');
//  x=(x<<3)+(x<<1)+(*y-'0');
  return x;
}

Waarbij ik dus de ene keer de ene regel gebruik en de andere keer de andere. De compiler alloceert beide variabelen op de stack; x op -24(%ebp) en y op -20(%ebp).

Mijn regel resulteert in:

code:

      movl -24(%ebp),%eax
      leal (%eax,%eax,4),%eax
      movsbl -20(%ebp),%edx
      leal -48(%edx,%eax,2),%eax
      movl %eax,-24(%ebp)

Jouw regel resulteert in:

code:

      movl -24(%ebp),%eax
      leal (%eax,%eax),%edx
      leal -48(%edx,%eax,8),%eax
      movsbl -20(%ebp),%edx
      addl %edx,%eax
      movl %eax,-24(%ebp)

Doordat jou code wat ingewikkelder is raakt de compiler de draad kwijt en voegt 'ie een extra leal instructie in, die in mijn code achterwege blijft. MIJN code is dus efficiënter. =)

[.oisyn]

Op maandag 04 maart 2002 23:38 schreef Sneechy het volgende:

[..]

Dat soort optimalisaties kun je imho beter aan de compiler overlaten, aangezien ze je sourcecode er niet duidelijker op maken.

en heeft de ook nog enige betekenis voor jou?

Bovendien vind ik de reden dat "je compiler het wel optimaliseert" geen reden om het zelf niet te doen. Want wie zegt dat je compiler wel goed optimaliseert?

[dit is geen argument]
En dat het niet leesbaar is geld alleen voor de relatief nieuwere programmeurs... programmeurs van de oude garde die veel tijd-kritieke code hebben geschreven weten precies wat er staat en wat de bedoeling is (en je kunt er altijd nog een comment bij zetten)
[/dit is geen argument]

[Verwijderd]

Op maandag 04 maart 2002 23:50 schreef OiSyN het volgende:
Bovendien vind ik de reden dat "je compiler het wel optimaliseert" geen reden om het zelf niet te doen. Want wie zegt dat je compiler wel goed optimaliseert?

Jij bent zeker ook zo'n persoon die niet:

code:

x += 2;

schrijft, maar:

code:

x++;x++;

?

[.oisyn]

Op maandag 04 maart 2002 23:41 schreef Soultaker het volgende:

[..]

Nee, die spaties bedoel ik echt niet.

welles

[.. serieuze reactie op iets dat als grapje bedoeld was ..]

zie mijn vorige post (en dan met name dat gedeelte over de )

Mijn regel resulteert in:

code:

      movl -24(%ebp),%eax
      leal (%eax,%eax,4),%eax
      movsbl -20(%ebp),%edx
      leal -48(%edx,%eax,2),%eax
      movl %eax,-24(%ebp)

Jouw regel resulteert in:

code:

      movl -24(%ebp),%eax
      leal (%eax,%eax),%edx
      leal -48(%edx,%eax,8),%eax
      movsbl -20(%ebp),%edx
      addl %edx,%eax
      movl %eax,-24(%ebp)

wat een lousy compiler

Doordat jou code wat ingewikkelder is raakt de compiler de draad kwijt en voegt 'ie een extra leal instructie in, die in mijn code achterwege blijft. MIJN code is dus efficiënter. =)

nou er staat een extra add in die bij jou niet staat, die lea is 1 instructies naar boven verhuist
overigens kun je nog niet echt zeggen welke ook daadwerkelijk sneller is, dan zul je even moeten benchmarken (hmmmz nostalgie... en curry en beelzebubu hebben ook al in dit topicje gereageerd )

hoewel ik wel denk dat jouw code idd sneller is

[Verwijderd]

Op maandag 04 maart 2002 23:40 schreef Orphix het volgende:
De libraries van C++ zijn t.o.v. de C libraries een enorme vooruitgang op het gebied van fout afhandeling. Door de structuur kan bij compile-tijd al heel veel typische programmeurs foutjes voorkomen worden.

als ik elke exception catch en er vervolgens niks mee doe, hoeveel zinniger ben ik dan bezig dan dat ik nooit op return values check?

En toch doet bijna elke gemiddelde C++ programmeur dat, net zoals elke gemiddelde C programmeur geen return values checkt....

Ik vind het logisch dat een leraar het fout rekent wanneer statische buffers worden gebruikt wanneer er ook de (in veel gevallen) superieure vector of list gebruikt kan worden.

Waarom? Het gaat er toch om dat er een werkend resultaat zit? Als het lelijk is, okee. Maar je kan een leerling niet op stijl pakken!!! Lelijkheid, akkoord, maar stijl is persoonlijk. Laat een leerling daarin vrij!

De voorbeelden die je noemt slaan kant noch wal, ik ken ook hele stabiele C++ programma's. Dat Gnome voor 90% uit C bestaat betekent enkel dat men in C is begonnen en nu niet meer 'zomaar' naar C++ kan overstappen (plus daarbij de unix programmeurs tegen de haren in te strijken).

Wederom onzin, want gnome is enkele maanden geleden van de grond af opnieuw geschreven (gnome-2, momenteel in beta). Dat had ik C++ gedaan kunnen worden maar is in C gedaan omdat C minder overhead en nutteloze features heeft dan C++ en gewoon lekkerder werkt.

Als je eens met GObject gewerkt hebt wil je geen C++ meer

[.oisyn]

Op maandag 04 maart 2002 23:55 schreef Sneechy het volgende:

[..]

Jij bent zeker ook zo'n persoon die niet:

code:

x += 2;

schrijft, maar:

code:

x++;x++;

?

nee, ik schrijf x += 2, want een add is efficienter dan 2 inc's

[Bananeman]

Op maandag 04 maart 2002 19:22 schreef OiSyN het volgende:

[..]
OiSyNwordt zo achterlijk getikt van die mensen die persee of het een of het ander willen, en die niet begrijpen dat je het ook gewoon prima kunt combineren[/me]

Gewoon kwestie van consequent een bepaalde lijn of methodiek volgen, wat is daar nou weer mis mee

OiSyNvindt pure C-code sowieso al eleganter dan C++-code, omdat er gewoon wordt gedaan wat er staat, en er gebeuren dus geen onverwachte dingen omdat er bijvoorbeeld een operator is geoverload of er een exception wordt gethrowed (wat overigens niet zegt dat OiSyN exceptions en operator overloading niet handig vindt )[/me]

Dit is echt klets IMHO. Als jij niet op de hoogte bent van een bepaalde operator die is ge-overload, dan betekent dat dat je jouw eigen code niet kent of dat je gewoon de docs van andermans code eens moet lezen. Zijn die docs er niet dan moet je die hele code niet gebruiken.

Verder word je een heel stuk wijzer door gewoon eens door code heen te stappen.

In C++ wordt ook gewoon gedaan wat er staat, alleen zie jij misschien niet altijd wat er nou eigenlijk allemaal staat. De compiler wel. Is ook een heel slimme jongen.

[Orphix]

Op dinsdag 05 maart 2002 00:00 schreef beelzebubu het volgende:

[..]

als ik elke exception catch en er vervolgens niks mee doe, hoeveel zinniger ben ik dan bezig dan dat ik nooit op return values check?

En toch doet bijna elke gemiddelde C++ programmeur dat, net zoals elke gemiddelde C programmeur geen return values checkt....

Maar excepties worden doorgegooid totdat ze opgevangen worden. Ok, je kan ze negeren, maar de kans is veel groter dat in een hogere abstractie laag de fout wel opgevangen wordt. Bij C gebeurt dit niet waardoor je opeens 100 regels verder voor een rare bug komt te staan.

Waarom? Het gaat er toch om dat er een werkend resultaat zit? Als het lelijk is, okee. Maar je kan een leerling niet op stijl pakken!!! Lelijkheid, akkoord, maar stijl is persoonlijk. Laat een leerling daarin vrij!

Je leert ze C++ en geen C. Stel een bedrijf vraagt een C++ programmeur, dan komt de leerling daar aan. De baas vraagt 'hoe ga jij met de STL om?' .. leerling: 'uuhm, ik kan wel met pointers werken'...

Wederom onzin, want gnome is enkele maanden geleden van de grond af opnieuw geschreven (gnome-2, momenteel in beta). Dat had ik C++ gedaan kunnen worden maar is in C gedaan omdat C minder overhead en nutteloze features heeft dan C++ en gewoon lekkerder werkt.

Als je eens met GObject gewerkt hebt wil je geen C++ meer

Ok, dat wist ik niet. Ik vind het zowiezo raar dat ze vanaf de grond af opnieuw beginnen (maar dat heb je al snel met een non-OO taal ). Maar goed dat is hun keuze als ze een GUI, wat perfect in OO termen te vertalen is, in een non-OO taal willen maken mogen ze van mij. Op mijn hulp hoeven ze niet te rekenen

[.oisyn]

Op dinsdag 05 maart 2002 00:02 schreef Bananeman2002 het volgende:

[..]

Gewoon kwestie van consequent een bepaalde lijn of methodiek volgen, wat is daar nou weer mis mee

op zich helemaal niets, maar vaak wordt er met wat non-argumenten gegooid die helemaal nergens op slaan (zo van: "ja maar dat is niet puur C++". Ja, dus?)

Dit is echt klets IMHO. Als jij niet op de hoogte bent van een bepaalde operator die is ge-overload, dan betekent dat dat je jouw eigen code niet kent of dat je gewoon de docs van andermans code eens moet lezen. Zijn die docs er niet dan moet je die hele code niet gebruiken.

Er zijn wel meer dingen hoor dan alleen het overloaden van operatoren. Je zou versteld staan als je bijvoorbeeld eens gaat kijken hoeveel met temporary objects heen en weer wordt gegooid, die alleen maar even dienen om weer een ander object te creeeren. De uiteindelijke uitvoer is hetzelfde ja, maar daar doel ik helemaal niet op. Ik doel op de letterlijke code die wordt uitgevoerd, niet op het resultaat

[Soultaker]

Op maandag 04 maart 2002 23:50 schreef OiSyN het volgende:
en heeft de ook nog enige betekenis voor jou?

Wat wil dat zeggen dan?

En dat het niet leesbaar is geld alleen voor de relatief nieuwere programmeurs... programmeurs van de oude garde die veel tijd-kritieke code hebben geschreven weten precies wat er staat en wat de bedoeling is (en je kunt er altijd nog een comment bij zetten)

Hier zal ik dan ook wel niet serieus op mogen reageren, aangezien je zelf zegt dat 't geen geldig argument is, maar ik kan 't toch niet laten. Het is inderdaad wel zo dat een goede programmeur je code kan lezen, maar aangezien je nu niet meer de '10' in de code hebt staan, is het een stuk moeilijker om de link te leggen tussen de vermenigvuldiging en het feit dat we een nieuwe decimaal toevoegen. Als je veel code moet doorlezen is het dus zeker wel erg prettig als je at first glance kan zien wat code doet.

Leuk trouwens, dat we in deze thread twee discussies door elkaar aan 't voeren zijn =)

[Verwijderd]

Op dinsdag 05 maart 2002 00:07 schreef Orphix het volgende:
Maar excepties worden doorgegooid totdat ze opgevangen worden. Ok, je kan ze negeren, maar de kans is veel groter dat in een hogere abstractie laag de fout wel opgevangen wordt. Bij C gebeurt dit niet waardoor je opeens 100 regels verder voor een rare bug komt te staan.

In beide gevallen wordt een niet-opgevangen exception al vrij snel een bug...

k vind directe return codes daarnaast gewoon overzichtelijker maar da's weer meer persoonlijk en style-issue...

Ok, dat wist ik niet. Ik vind het zowiezo raar dat ze vanaf de grond af opnieuw beginnen (maar dat heb je al snel met een non-OO taal ). Maar goed dat is hun keuze als ze een GUI, wat perfect in OO termen te vertalen is, in een non-OO taal willen maken mogen ze van mij. Op mijn hulp hoeven ze niet te rekenen

KDE (C++ concurrent van Gnome) is al twee keer herschreven

[Verwijderd]

Op dinsdag 05 maart 2002 00:09 schreef OiSyN het volgende:
op zich helemaal niets, maar vaak wordt er met wat non-argumenten gegooid die helemaal nergens op slaan (zo van: "ja maar dat is niet puur C++". Ja, dus?)

wat een wijsheid

[Verwijderd]

Op dinsdag 05 maart 2002 00:07 schreef Orphix het volgende:
Op mijn hulp hoeven ze niet te rekenen

Dat gevoel heb ik dus ook als ik van die C projectjes op Sourceforge zie. Ik heb gewoon geen zin om:
a.) In pseudo-OO te programmeren als er een prima variant met built-in OO functionaliteit verkrijgbaar is;
b.) In een project te werken met mensen die de voordelen van C++ en built-in OO niet begrijpen / kunnen waarderen.

Sja, je kan zeggen dat ik mezelf teveel beperk door C te boycotten, maar ik heb gewoon geen zin om nodeloos te lijden door een inferieure taal te gebruiken .

[.oisyn]

Op dinsdag 05 maart 2002 00:10 schreef Soultaker het volgende:

[..]

Wat wil dat zeggen dan?

grrr

Hier zal ik dan ook wel niet serieus op mogen reageren

niet mogen is een beetje een groot woord, ik kan je tenslotte niet verbieden serieus te reageren

aangezien je zelf zegt dat 't geen geldig argument is, maar ik kan 't toch niet laten. Het is inderdaad wel zo dat een goede programmeur je code kan lezen, maar aangezien je nu niet meer de '10' in de code hebt staan, is het een stuk moeilijker om de link te leggen tussen de vermenigvuldiging en het feit dat we een nieuwe decimaal toevoegen. Als je veel code moet doorlezen is het dus zeker wel erg prettig als je at first glance kan zien wat code doet.

geloof het of niet, maar hier ben ik het helemaal mee eens Voor dit soort simpele dingetjes is het ook volslagen onzin om dat soort optimalisaties door te voeren (vandaar ook de erbij), maar ik ben op het moment bezig met een spel voor de Gameboy Advance, en dan zie je dus niet anders dan dat soort optimalisaties

Leuk trouwens, dat we in deze thread twee discussies door elkaar aan 't voeren zijn =)

idd, het oude GoT-gevoel komt weer helemaal terug

[Orphix]

Op dinsdag 05 maart 2002 00:15 schreef Sneechy het volgende:
Dat gevoel heb ik dus ook als ik van die C projectjes op Sourceforge zie. Ik heb gewoon geen zin om:
a.) In pseudo-OO te programmeren als er een prima variant met built-in OO functionaliteit verkrijgbaar is;
b.) In een project te werken met mensen die de voordelen van C++ en built-in OO niet begrijpen / kunnen waarderen.

Sja, je kan zeggen dat ik mezelf teveel beperk door C te boycotten, maar ik heb gewoon geen zin om nodeloos te lijden door een inferieure taal te gebruiken .

wat een wijsheid

[Bananeman]

Op dinsdag 05 maart 2002 00:09 schreef OiSyN het volgende:

[..]

op zich helemaal niets, maar vaak wordt er met wat non-argumenten gegooid die helemaal nergens op slaan (zo van: "ja maar dat is niet puur C++". Ja, dus?)

Maar dat was nu niet het geval.

Er zijn wel meer dingen hoor dan alleen het overloaden van operatoren. Je zou versteld staan als je bijvoorbeeld eens gaat kijken hoeveel met temporary objects heen en weer wordt gegooid, die alleen maar even dienen om weer een ander object te creeeren. De uiteindelijke uitvoer is hetzelfde ja, maar daar doel ik helemaal niet op. Ik doel op de letterlijke code die wordt uitgevoerd, niet op het resultaat

Uiteindelijk draait het om het resultaat, en jij kunt precies volgen hoe dat resultaat tot stand is gekomen. Wordt er een tijdelijk object aangemaakt, dan wordt de (copy-)constructor van die klasse aangeroepen, etc.

Op die manier kan het debuggen wel langdradig en ingewikkeld worden vanwege al die "zijsprongen", maar gewoon een bak koffie d'rbij.

[Verwijderd]

Op dinsdag 05 maart 2002 00:15 schreef Sneechy het volgende:
b.) In een project te werken met mensen die de voordelen van C++ en built-in OO niet begrijpen / kunnen waarderen.

Waarom inferieur

C heeft ook overloadable dynamic abstract bladiebla hoeheetdat functions, alleen hier heet dat gewoon een struct met functionpointer.

Het effect is hetzelfde.

Ik waardeer die extra's van C++ juist heel erg en daarom ben ik zo blij dat ik de onnodige functies in C++ niet hoef te gebruiken en dus kan genieten van die prachtige functies uit C++ in C. Het beste van de twee werelden zal ik het niet noemen, maar zo voelt het wel

[Verwijderd]

Op dinsdag 05 maart 2002 00:17 schreef Orphix het volgende:

[..]

wat een wijsheid

Hey, dat is mijn tekst!

[Verwijderd]

Op dinsdag 05 maart 2002 00:09 schreef OiSyN het volgende:Er zijn wel meer dingen hoor dan alleen het overloaden van operatoren. Je zou versteld staan als je bijvoorbeeld eens gaat kijken hoeveel met temporary objects heen en weer wordt gegooid, die alleen maar even dienen om weer een ander object te creeeren.

Naarmate je meer ervaring met C++ krijgt, leer je met behulp van goed gebruik van (const) references en dergelijke code te schrijven waarin zo weinig mogelijk van dat soort temporaries nodig zijn. Is gewoon een kwestie van goed nadenken bij het schrijven van code.

[Verwijderd]

Op dinsdag 05 maart 2002 00:19 schreef beelzebubu het volgende:
Waarom inferieur

Sorry, daar moest een "imho"tje bij.

Maar als ik mijn hele programmastructuur object georienteerd opzet, vind ik het wel fijn als de benodigde functionaliteit in de taal verwerkt zit, en ik me niet bezig hoef te houden met de onderliggende mechanismen.

Je zou het vanuit een C perspectief kunnen zien als een lib die ZO basic is, dat er een nieuwe taal voor gemaakt is waar die lib helemaal ingemetseld zit.

[Orphix]

Op dinsdag 05 maart 2002 00:19 schreef beelzebubu het volgende:

[..]

Waarom inferieur

C heeft ook overloadable dynamic abstract bladiebla hoeheetdat functions, alleen hier heet dat gewoon een struct met functionpointer.

Het effect is hetzelfde.

Dat is het dus, dat heeft C juist niet. dynamic binding, abstract classes ... dat zijn typische OO en C++ eigenschappen. Je ziet nu dat ze dat proberen te 'emuleren' in C, want het is toch wel handig.
Nadeel is dat het (omdat het niet in de taal ingebakken zit) enorm omslachtig en moeilijk gaat.

[.oisyn]

Op dinsdag 05 maart 2002 00:18 schreef Bananeman2002 het volgende:

[..]

Maar dat was nu niet het geval.

nee maar dat zei ik ook niet

Uiteindelijk draait het om het resultaat, en jij kunt precies volgen hoe dat resultaat tot stand is gekomen. Wordt er een tijdelijk object aangemaakt, dan wordt de (copy-)constructor van die klasse aangeroepen, etc.

niet helemaal, het draait (bij mij) om resultaat en snelheid. Zoals je in mijn vorige post hebt kunnen lezen ben ik met een GBA spel bezig. De code draait op een ARM7TDMI RISC processor op een snelheid van 16.83 MHz. Bovendien heeft ie maar 256k extern geheugen en 32k intern, dus ja, dan heb ik liever niet dat er met temporary objects wordt gegooid
Voor dat soort dingen kies ik dan voor een combinatie van C en C++, waarbij ik de voordelen van het makkelijke OO in C++ gebruik, maar de dingen die overhead hebben vermijd ik zoveel mogelijk. Dus geen virtual functies/classes, geen exceptions, enz.

Kijk, ik wil hier geen pro-C of anti-C++ verhaal oid ophangen, maar ik vind pure C code gewoon eleganter, omdat er gedaan wordt wat er staat, en je hoeft dus niet tussen de regeltjes door te lezen of rekening te houden met allerlei classes, wat in C++ al gauw wel het geval is. En bovendien code ik nog dagelijks in C++ met al z'n poespas (behalve de STL dan ), maar puur C vind ik gewoon elegant

Op die manier kan het debuggen wel langdradig en ingewikkeld worden vanwege al die "zijsprongen", maar gewoon een bak koffie d'rbij.

en debuggen op de gba gaat sowieso al niet op de gebruikelijke manier, dus maak daar maar 4 bakken koffie en een lunch van

[.oisyn]

Op dinsdag 05 maart 2002 00:22 schreef Sneechy het volgende:

[..]

Naarmate je meer ervaring met C++ krijgt, leer je met behulp van goed gebruik van (const) references en dergelijke code te schrijven waarin zo weinig mogelijk van dat soort temporaries nodig zijn. Is gewoon een kwestie van goed nadenken bij het schrijven van code.

juist, in mijn code gebeuren dat soort dingen dus ook niet, maar ik ben nou eenmaal niet de enige C++ coder op deze aardbol

[Verwijderd]

Op dinsdag 05 maart 2002 00:25 schreef Sneechy het volgende:
Je zou het vanuit een C perspectief kunnen zien als een lib die ZO basic is, dat er een nieuwe taal voor gemaakt is waar die lib helemaal ingemetseld zit.

is dat niet juist wat glib doet dan?

[.oisyn]

zal de topicstarter al geholpen zijn?

[Verwijderd]

Op dinsdag 05 maart 2002 00:29 schreef OiSyN het volgende:
Voor dat soort dingen kies ik dan voor een combinatie van C en C++, waarbij ik de voordelen van het makkelijke OO in C++ gebruik, maar de dingen die overhead hebben vermijd ik zoveel mogelijk. Dus geen virtual functies/classes, geen exceptions, enz.

Kijk, ik wil hier geen pro-C of anti-C++ verhaal oid ophangen, maar ik vind pure C code gewoon eleganter, omdat er gedaan wordt wat er staat, en je hoeft dus niet tussen de regeltjes door te lezen of rekening te houden met allerlei classes, wat in C++ al gauw wel het geval is.

Idd ik vindt dan ook dat iedereen die wil gaan beweren dat OOP beter is een keer OO moet gaan programmeren in een taal die dat niet direct ondersteund. zodat je weet wat er allemaal op de achtergrond gebeurt bij een OO taal. Ik denk dat de meeste ervan zullen schrikken.

[Verwijderd]

Op dinsdag 05 maart 2002 00:39 schreef borganism het volgende:
Idd ik vindt dan ook dat iedereen die wil gaan beweren dat OOP beter is een keer OO moet gaan programmeren in een taal die dat niet direct ondersteund. zodat je weet wat er allemaal op de achtergrond gebeurt bij een OO taal. Ik denk dat de meeste ervan zullen schrikken.

Ik vind de ondersteunende runtime mechanismen voor OO zaken in C++ (van simpele inheritance tot polymorphisme) eigenlijk helemaal niet zo shockerend..

En ik vind die cycles en bytes al helemaal goed besteed als ik zie wat ik ervoor terugkrijg .

[curry684]

Op dinsdag 05 maart 2002 00:16 schreef OiSyN het volgende:
idd, het oude GoT-gevoel komt weer helemaal terug

Ik zit na al dit geschreeuw en moddergesmijt eigenlijk alleen nog te wachten op een benchmark

[hufkes]

wat dacht je van een poll dan

[MSalters]

Op dinsdag 05 maart 2002 00:09 schreef OiSyN het volgende:
Er zijn wel meer dingen hoor dan alleen het overloaden van operatoren. Je zou versteld staan als je bijvoorbeeld eens gaat kijken hoeveel met temporary objects heen en weer wordt gegooid, die alleen maar even dienen om weer een ander object te creeeren. De uiteindelijke uitvoer is hetzelfde ja, maar daar doel ik helemaal niet op. Ik doel op de letterlijke code die wordt uitgevoerd, niet op het resultaat

Je staat er echt verbaasd van hoeveel temporary objects een echte (!=MS) C++ compiler elimineert als er niet in DEBUG mode wordt gecompileerd. 90% is niet ongebruikelijk. 't Is een FAQ waarom de dtor in release mode minder vaak wordt aangeroepen dan in debug mode.
Afgezien daarvan, die temporary objects zitten typisch in je L1 cache. Dus zo langzaam zijn die ook weer niet.

[Bananeman]

Op dinsdag 05 maart 2002 00:39 schreef borganism het volgende:

[..]

Idd ik vindt dan ook dat iedereen die wil gaan beweren dat OOP beter is een keer OO moet gaan programmeren in een taal die dat niet direct ondersteund. zodat je weet wat er allemaal op de achtergrond gebeurt bij een OO taal. Ik denk dat de meeste ervan zullen schrikken.

Nogmaals, 90% van wat er "op de achtergrond gebeurt" bij een OO taal heb je zelf veroorzaakt c.q. in werking gezet. Als je niet voldoende duidelijk in de gaten hebt wat er allemaal gebeurt, dan heb je te weinig kennis van de code of van OO programmeren. Zo moeilijk is het toch allemaal niet?

[Bananeman]

Op dinsdag 05 maart 2002 00:29 schreef OiSyN het volgende:

[..]
Kijk, ik wil hier geen pro-C of anti-C++ verhaal oid ophangen, maar ik vind pure C code gewoon eleganter, omdat er gedaan wordt wat er staat, en je hoeft dus niet tussen de regeltjes door te lezen of rekening te houden met allerlei classes, wat in C++ al gauw wel het geval is. En bovendien code ik nog dagelijks in C++ met al z'n poespas (behalve de STL dan ), maar puur C vind ik gewoon elegant

Elegant? Persoonlijke smaak, maar ik vind het een vreemd standpunt. Ik vind C++ veel eleganter.

Efficiënter? Kan. In C++ ontwikkel je dingen echter op een manier dat je zaken niet twee keer hoeft te doen, in C kan je dit wel overkomen. En dat is weer niet efficiënt.

en debuggen op de gba gaat sowieso al niet op de gebruikelijke manier, dus maak daar maar 4 bakken koffie en een lunch van

Ik heb meegewerkt aan twee games op de Playstation, daar werd koffie in hectoliters in het projectbudget opgenomen.

[Verwijderd]

Op dinsdag 05 maart 2002 04:03 schreef curry684 het volgende:

[..]

Ik zit na al dit geschreeuw en moddergesmijt eigenlijk alleen nog te wachten op een benchmark

Ja, laten we een zinnige C++ vs. C benchmark maken

Nu komt het moeilijke gedeelte: hoe maak ik een zinnige C vs. C++ vergelijking?

[Bananeman]

Op dinsdag 05 maart 2002 10:23 schreef beelzebubu het volgende:

[..]

Ja, laten we een zinnige C++ vs. C benchmark maken

Nu komt het moeilijke gedeelte: hoe maak ik een zinnige C vs. C++ vergelijking?

Ja! En als je dan toch bezig bent, houd dan ook meteen een enquête om te bepalen hoeveel vuil de tweaker gemiddeld in zijn navel heeft zitten, en wat de exacte samenstelling daarvan is. Da's net zo nuttig, zinvol en: onsmakelijk.

Ohja, smiley:

[Verwijderd]

Op dinsdag 05 maart 2002 10:35 schreef Bananeman2002 het volgende:

[..]

Ja! En als je dan toch bezig bent, houd dan ook meteen een enquête om te bepalen hoeveel vuil de tweaker gemiddeld in zijn navel heeft zitten, en wat de exacte samenstelling daarvan is. Da's net zo nuttig, zinvol en: onsmakelijk.

Ohja, smiley:

[dom blond mode]
mijn navel is echt schoon hoor Wil je hem zien?
[/dom blond mode]

MAar ff serieus, er is toch wel een simpele benchmarktoepassing te bedenken waarbij je bepaalde C++ elementen zoals functie overlading in een class, classes etc. gebruikt en die vergelijkt met de C object structs en function pointers en kijkt of C++ echt zoveel toegevoegde waarde heeft

[Bananeman]

Op dinsdag 05 maart 2002 11:11 schreef beelzebubu het volgende:

[..]

[dom blond mode]
mijn navel is echt schoon hoor Wil je hem zien?
[/dom blond mode]

Thanks, but no thanks

MAar ff serieus, er is toch wel een simpele benchmarktoepassing te bedenken waarbij je bepaalde C++ elementen zoals functie overlading in een class, classes etc. gebruikt en die vergelijkt met de C object structs en function pointers en kijkt of C++ echt zoveel toegevoegde waarde heeft

Probleem is dat je dan voorbijschiet aan je doel, namelijk het efficiënt implementeren van een bepaald algorithme. Als je heel geforceerd bepaalde OO technieken toe gaat passen, krijg je wellicht kunstmatige inefficiëntie.

Een C/C++ benchmark wordt uiteindelijk meer zaak van de compiler dan van de programmeur: hoe slim optimaliseert je compiler bottlenecks e.d. eruit?

Natuurlijk kun je wel een flauw programmaatje in zowel C als C++ bouwen, maar wat zegt dat over een compleet project met (honderd)duizenden regels code? En hoe defineer je "efficiënt"? Codesize, execution speed, onderhoudbaarheid, ...

Maar doe eens een voorstel!

[Verwijderd]

Op dinsdag 05 maart 2002 00:00 schreef beelzebubu het volgende:
Wederom onzin, want gnome is enkele maanden geleden van de grond af opnieuw geschreven (gnome-2, momenteel in beta). Dat had ik C++ gedaan kunnen worden maar is in C gedaan omdat C minder overhead en nutteloze features heeft dan C++ en gewoon lekkerder werkt.

Dit is dus ook onzin. Gnome is in C geschreven omdat er
• linking problemen zijn ivm. name-mangling van C++ compilers
• C++ binaries iets trager laden dan C binaries (in linux iig.)

Als je eens met GObject gewerkt hebt wil je geen C++ meer

GUI's zijn uitermate geschikt om in een OO-taal te implementeren. Als de taal niet OO is, moet je OO simuleren, zoals gnome dat doet. Dat simuleren is lastig, je moet voor elke class twee structs aanmaken en beheren. Bij een OO-taal neemt de compiler het class-beheer van je over...

[Verwijderd]

Op maandag 04 maart 2002 14:55 schreef jeroenbeekman een naar mho foute code en een goede vraag

Ben geen C(++)-er maar misschien helpt onderstaande je meer:

code:

char *datum, *tijdelijk;
unsigned long datum2;
datum = "12/12/81";
tijdelijk = "000000"; // Ik wist niet hoe je deze anders moest initialiseren

int i, j;

j = 0;

for(i=0;datum[i]!='\0';i++)
{
  if(datum[i] != '/')
    tijdelijk[i-j] = datum[i];
  else
    j++;
};

datum2 = atoi(tijdelijk);
cout << datum;
cout << tijdelijk;
cout << datum2;

Mag ik trouwens opmerken dat als je dit in een database gaat opslaan (als unsigned long) dat je foute waardes kunt krijgen met bijv: 31202, immers is dit nou: 03/12/02 of 31/02/02? Wat je beter kan doen is: 20021203. Deze laat niet aan duidelijkheid te wensen over lijkt me.

[.oisyn]

Op dinsdag 05 maart 2002 09:44 schreef MSalters het volgende:

[..]

Je staat er echt verbaasd van hoeveel temporary objects een echte (!=MS) C++ compiler elimineert als er niet in DEBUG mode wordt gecompileerd. 90% is niet ongebruikelijk. 't Is een FAQ waarom de dtor in release mode minder vaak wordt aangeroepen dan in debug mode.
Afgezien daarvan, die temporary objects zitten typisch in je L1 cache. Dus zo langzaam zijn die ook weer niet.

een gameboy heeft geen L1 cache

Bovendien is iets kopieren terwijl het niet hoeft sowieso loos, ook al staat het in je cache

[Soultaker]

Op dinsdag 05 maart 2002 09:44 schreef MSalters het volgende:
Je staat er echt verbaasd van hoeveel temporary objects een echte (!=MS) C++ compiler elimineert als er niet in DEBUG mode wordt gecompileerd.

Waarop baseer je de uitspraak dat de Microsoft C++ compiler geen 'echte' C++ compiler zou zijn, of tenminste geen code van met andere compilers vergelijkbare kwaliteit zou leveren?

[.oisyn]

Op dinsdag 05 maart 2002 14:27 schreef Soultaker het volgende:

[..]

Waarop baseer je de uitspraak dat de Microsoft C++ compiler geen 'echte' C++ compiler zou zijn, of tenminste geen code van met andere compilers vergelijkbare kwaliteit zou leveren?

ik vond het idd ook een beetje loos, maar ik wilde er maar verder niet op in gaan

mijn ervaring is trouwens wel dat die van MS vrijwel de snelste code produceert (zelfs sneller dan die van intel zelf in veel gevallen). Afgezien van die MS extensiesis en wat vage internal compiler errors in een aantal gevallen het een prima compiler

[Verwijderd]

Bedankt voor alle reacties, maar ik heb het idee dat er nu twee discussies door elkaar heen lopen...

Maar goed, ik heb de onderstaande code nu. Het werkt prima als je de char ZELF invult. Hoe kan ik nou de echte systeemdatum gebruiken?

code:

char tmpbuf[128], ampm[] = "AM";
    time_t ltime;
    struct _timeb tstruct;
    struct tm *today, *gmt, xmas = { 0, 0, 12, 25, 11, 93 };

    _tzset();

    _strtime( tmpbuf );
    printf( "\n\nOS time: %s\n", tmpbuf );
   
char test;
test = printf("%s",tmpbuf);

    const char* datum = datum = "12/02/02";
    char tijdelijk[7];

    const char* r = datum;
    char* w = tijdelijk;
    char v;
    while (v = *r++)
    {
        if (v != '/')
            *w++ = v;
    }
    *w = 0;
    
    int datum2 = atoi(tijdelijk);
    
    cout << datum2 << endl;
    cout << datum << endl;
    cout << tijdelijk << endl;
      cout << test;
        

getch();

[Soultaker]

Op dinsdag 05 maart 2002 14:34 schreef jeroenbeekman het volgende:
Bedankt voor alle reacties, maar ik heb het idee dat er nu twee discussies door elkaar heen lopen...

Het waren twee discussies die NIET over jou probleem gaan, PLUS jou probleem, om precies te zijn. =)

Maar goed, ik heb de onderstaande code nu. Het werkt prima als je de char ZELF invult. Hoe kan ik nou de echte systeemdatum gebruiken?

Wat wil je daar dan precies mee doen? Kijk in ieder geval even naar de manual pages van time (die de tijd in time_t formaat oplevert) en functies als ctime/localtime/gmtime, die een tijd in time_t formaat kunnen converteren naar een struct tm, waarin de tijd (inclusief datum) staat opgeslits in velden als dag, maand, jaar, uur, etc.

Als het, zoals ik vermoed, de bedoeling is dat je de huidige datum in jou formaat weergeeft (050302 voor vandaag ofzo?), kun je volstaan met sprintf in combinatie met bovengenoemde struct of gebruik maken van de functie strftime.

edit:
Het lijkt er op dat je de datum in 'n integer wilt stoppen, in welk geval je helemaal geen strings nodig hebt natuurlijk. Dat is slechts een kwestie van creatief vermenigvuldigen.

code:

...

Beetje jammer dat je toch weer voor deze implementatie hebt gekozen, maar ok, dat is jou keuze.

[Verwijderd]

Wat ik dus wil is dat de systeemdatum en later de tijd in een integer wordt gezet.

[MSalters]

Op dinsdag 05 maart 2002 14:27 schreef Soultaker het volgende:

Waarop baseer je de uitspraak dat de Microsoft C++ compiler geen 'echte' C++ compiler zou zijn, of tenminste geen code van met andere compilers vergelijkbare kwaliteit zou leveren?

Ervaring met MSVC vanaf versie 1. In elk geval hadden ze hun prioriteiten anders liggen. Voorbeeld: op m'n nieuwe laptop VS6 geinstalleerd, eerste 50 regels code die ik schreef liepen tegen een triviale compiler bug op (name mangling moet alle parameters mee nemen, dus ook template parameters ). Heeft me een hele dag gekost. De bugfix aan MS kant zou me ook een dag gekost hebben, gok ik. Zij vonden het belangrijker om COM te supporten. Tsja.

Goed, MS heeft in VS7 op z'n minst weer een recente STL, en VC7.1 aangekondigd. Het voordeel van concurrentie.

Maar wat de originele opmerking: RVO/NRVO is in andere compilers typisch beter; afgaand op het aantal gekopieerde objecten. En aangezien dat de overgrote meerderheid van temporaries zijn. ( vergelijk Metroworks )

[Soultaker]

Op dinsdag 05 maart 2002 15:51 schreef jeroenbeekman het volgende:
Wat ik dus wil is dat de systeemdatum en later de tijd in een integer wordt gezet.

code:

  time_t clock=time(NULL); // Haal de huidige tijd op 
  struct tm *info=gmtime(&clock); // Splits de tijd op in componenten
  int result=(info->tm_year+1900)*10000+(info->tm_mon+1)*100+info->tm_mday);

Dit levert voor vandaag 20020305 op als een integer. Een ander formaat is eenvoudig samen te stellen, hoewel dit formaat waarschijnlijk het meest praktisch is.

Wat was nou precies de relatie met het vorige probleem? Of heb ik je bedoeling verkeerd geinterpreteerd?

[Olaf van der Spek]

Op dinsdag 05 maart 2002 15:28 schreef Soultaker het volgende:
Beetje jammer dat je toch weer voor deze implementatie hebt gekozen, maar ok, dat is jou keuze.

Wat was er mis met deze implementatie?

[Olaf van der Spek]

Op dinsdag 05 maart 2002 15:58 schreef MSalters het volgende:

[..]

Ervaring met MSVC vanaf versie 1. In elk geval hadden ze hun prioriteiten anders liggen. Voorbeeld: op m'n nieuwe laptop VS6 geinstalleerd, eerste 50 regels code die ik schreef liepen tegen een triviale compiler bug op (name mangling moet alle parameters mee nemen, dus ook template parameters ). Heeft me een hele dag gekost. De bugfix aan MS kant zou me ook een dag gekost hebben, gok ik. Zij vonden het belangrijker om COM te supporten. Tsja.

Goed, MS heeft in VS7 op z'n minst weer een recente STL, en VC7.1 aangekondigd. Het voordeel van concurrentie.

Had je wel de SPs geinstalleerd?

[Soultaker]

Op dinsdag 05 maart 2002 17:11 schreef OlafvdSpek het volgende:
Wat was er mis met deze implementatie?

Hij is nodeloos ingewikkeld, onelegant en inefficiënt.

[Olaf van der Spek]

Als je de datum alleen als string hebt lijkt hij me best redelijk. Maar als je de datum al als getal hebt heb je gelijk.

[Verwijderd]

Op dinsdag 05 maart 2002 17:30 schreef OlafvdSpek het volgende:
Als je de datum alleen als string hebt lijkt hij me best redelijk. Maar als je de datum al als getal hebt heb je gelijk.

Natuurlijk heb ik de datum niet als getal! Anders ben je toch dubbel bezig.

[Olaf van der Spek]

Als jij de huidige datum wilt opslaan, heb je die dus wel als getal.

[Verwijderd]

Op dinsdag 05 maart 2002 17:54 schreef OlafvdSpek het volgende:
Als jij de huidige datum wilt opslaan, heb je die dus wel als getal.

Ja klopt, maar in een char met / ertussen. Ik kan die / er tussen uit halen, maar gewoon uit een eigen char waarde.

Dus niet de systeemdatum. Hoe krijg ik die in een normale char variabele?

[igmar]

Dat neemt niet weg dat je een 0 van mij krijgt als je C libraries gebruikt terwijl er ook C++ libraries beschikbaar zijn. C++ levert de C standaard libs voor backward-compatability en niet als main resource, maw. de C libs zijn depricated. Hoe handig printf en consorten ook zijn, ze zijn gevaarlijk (typesafety, buffer overflows); daarom heeft C++ iostreams die deze problemen oplossen. Men schrijft dit soort libraries niet voor niets!

printf() is typesafe, en voor de bufferoverflows heeft men snprintf() en familie uitgevonden.

Helaas zijn de C++ libs op elk systeem anders, dus echt veel keus heb je soms niet. (met vooral de nadruk op STD)

[Verwijderd]

Nog steeds bezig over datums converteren naar integers? Wat zou time_t voor type zijn?

<edit>fout type |:(</edit>

[Olaf van der Spek]

Sinds wanneer is printf typesafe?
Als ik printf("%s") doe crasht het behoorlijk volgens mij.

En heb je het over STL?

[igmar]

code:

char tmpbuf[128], ampm[] = "AM";
    time_t ltime;
    struct _timeb tstruct;
    struct tm *today, *gmt, xmas = { 0, 0, 12, 25, 11, 93 };

    _tzset();

    _strtime( tmpbuf );
    printf( "\n\nOS time: %s\n", tmpbuf );
   
char test;
test = printf("%s",tmpbuf);

    const char* datum = datum = "12/02/02";
    char tijdelijk[7];

    const char* r = datum;
    char* w = tijdelijk;
    char v;
    while (v = *r++)
    {
        if (v != '/')
            *w++ = v;
    }
    *w = 0;
    
    int datum2 = atoi(tijdelijk);
    
    cout << datum2 << endl;
    cout << datum << endl;
    cout << tijdelijk << endl;
      cout << test;
        

getch();

Kun je geen time() of gettimeofday() gebruiken ? time() doet namelijk precies wat jij wilt

[Olaf van der Spek]

Op dinsdag 05 maart 2002 18:09 schreef mietje het volgende:
Nogsteeds bezig over datums converteren naar integers?

code:

#include <ctime>

std::clock_t = std::clock();

Voor de oldschoolers:

code:

#include <time.h>

clock_t = clock();

(En ja, clock_t is een numeriek type.)

Moet je niet time() hebben?

[Verwijderd]

Op dinsdag 05 maart 2002 18:12 schreef OlafvdSpek het volgende:
Moet je niet time() hebben?

Ik zat te dromen, maar had het al geedit

[Verwijderd]

Op dinsdag 05 maart 2002 11:36 schreef Bananeman2002 het volgende:
Natuurlijk kun je wel een flauw programmaatje in zowel C als C++ bouwen, maar wat zegt dat over een compleet project met (honderd)duizenden regels code? En hoe defineer je "efficiënt"? Codesize, execution speed, onderhoudbaarheid, ...

Maar doe eens een voorstel!

Juist, ik zit ff na te denken hoe je een zinnige benchmark-achtig iets tussen deze twee zou kunnen doen. Ik kom hier nog op terug!

[Verwijderd]

Op dinsdag 05 maart 2002 18:10 schreef OlafvdSpek het volgende:
Sinds wanneer is printf typesafe?
Als ik printf("%s") doe crasht het behoorlijk volgens mij.

Op maandag 04 maart 2002 23:30 schreef beelzebubu het volgende:

[..]

Het feit dat win32's slappe mongool C libraries toevallig onstabiel zijn zegt niks over C als taal. Onder linux is C enorm stabiel, inclusief NULL checks et all.

code:

[5 Mar - rbultje@tux /tmp]# cat test.c
int main()
{
  printf("%s");
  return 0;
}
[5 Mar - rbultje@tux /tmp]# gcc -o test test.c
[5 Mar - rbultje@tux /tmp]# ./test
[5 Mar - rbultje@tux /tmp]#

[Olaf van der Spek]

Ik zou die optimalisatie toch aan de compiler overlaten, tenzij je aannames doet over het platform waarop je code moet gaan draaien.

[Verwijderd]

Op dinsdag 05 maart 2002 18:29 schreef OlafvdSpek het volgende:
Ik zou die optimalisatie toch aan de compiler overlaten, tenzij je aannames doet over het platform waarop je code moet gaan draaien.

(welke optimalisatie?)

[curry684]

Overigens, we zitten hier toch in een C++ topic... dan schrijf je dat toch zelf?!?!?

code:

// ------------------------------------------------------------------------
// Time type   (8 bytes)
// ------------------------------------------------------------------------

typedef struct
  {
  unsigned    m_Year        : 18;
  unsigned    m_Month      : 4;
  unsigned    m_Day      : 5;
  unsigned    m_Hour        : 5;
  unsigned    m_Minute    : 6;
  unsigned    m_Second    : 6;
  unsigned    m_Millisecond   : 10;
  unsigned    m_Sequence    : 10;
  } t_Time;

// --------------------------------------------------------------------------
// MyOwnTime: Date/Time container
// --------------------------------------------------------------------------

class MyOwnTime : public MyOwnObject
{
public:    // Methods
                        MyOwnTime();
                        MyOwnTime(const MyOwnTime &p_Time);
                        MyOwnTime(t_UInt2 p_Year,
                              t_UInt2 p_Month,
                              t_UInt2 p_Day,
                              t_UInt2 p_Hour,
                              t_UInt2 p_Minute,
                              t_UInt2 p_Seconds,
                              t_UInt2 p_MilliSeconds);

  void                  ConvertFromString(const MyOwnString &p_MyString);

  inline t_UInt2            Year() const      { return m_Time.m_Year; }
  inline t_UInt2            Month() const    { return m_Time.m_Month; }
  inline t_UInt2            Day() const    { return m_Time.m_Day; }
  inline t_UInt2            Hour() const      { return m_Time.m_Hour; }
  inline t_UInt2            Minute() const  { return m_Time.m_Minute; }
  inline t_UInt2            Second() const  { return m_Time.m_Second; }
  inline t_UInt2            Millisecond() const { return m_Time.m_Millisecond; }
  inline t_UInt2            Sequence() const    { return m_Time.m_Sequence; }

protected:  // Methods
  t_UInt2                GenerateSequence();
  
private:      // Properties
  t_Time                  m_Time;
  static volatile t_UInt2      m_Sequence;
};

// --------------------------------------------------------------------------

Zo, nu nog even zelf die 4 functies en die stringclass invullen en je bent klaar

[Verwijderd]

Wow! Gewelding dat je dit ff voor me doet, maar ben niet zo'n C++ freak dat ik dit allemaal begrijp. Is misschien ook niet nodig, maar ik wil wel graag weten hoe ik het gebruik...

[MSalters]

Op dinsdag 05 maart 2002 17:12 schreef OlafvdSpek het volgende:

Had je wel de SPs geinstalleerd?

Zelfs de Dinkumware patches (www.dinkumware.com).

Als je vaker met MSVC werkt, dan weet je dat dit soort bugs niet in SPs gefixed worden. Het heeft nl. een potentiele impact op bestaande code, die strict genomen fout is/niet zou moeten compileren/ander gedrag zou moeten vertonen.

Stel je voor dat je een geoptimaliseerde template specialisatie hebt gemaakt met een bug. MS negeert deze voor SPn, en na SPn compileer je je code opnieuw. Dan komt de bug dus boven water. MS is bang dat de SP dan de schuld krijgt.

[Olaf van der Spek]

Had niet verwacht dat zoiets goed zou gaan. Het volgende gaat wel fout met g++.

code:

printf("%s", 5);

[Orphix]

Op woensdag 06 maart 2002 10:50 schreef OlafvdSpek het volgende:
Had niet verwacht dat zoiets goed zou gaan. Het volgende gaat wel fout met g++.

code:

printf("%s", 5);

Tja ik denk bij de code van beelzebu toevallig een 0 staat op de argumenten stack (shit hoe heet dat nou) waardoor het goed werkt. iig gevaarlijk en undefined.