Studie: Java verslaat C++

[traviandus]

Even mijn bescheiden mening:

Java is een mooiere, cleanere taal dan C++. Veel nuttige functionaliteit direct in de taal (threading, synchronisatie, string manipulatie). Nadeel is dat de programma's niet direct op de proc draaien.

Met C++ heb je veel meer mogelijkheden om jezelf in de vingers te snijden. Dat maakt programmeren lastiger. Maar je hebt ook veel meer vrijheid en je kunt applicaties maken die de mogelijkheden van een machine volledig benutten.

Als er een taal is die zo clean is als Java met de vrijheid van C++ dan teken ik daar gelijk voor.

[marcusk]

Op zondag 02 september 2001 14:29 schreef traviandus het volgende:
Als er een taal is die zo clean is als Java met de vrijheid van C++ dan teken ik daar gelijk voor.

Volgens mij komt D daarbij aardig in de buurt.

[Verwijderd]

Op zondag 02 september 2001 14:29 schreef traviandus het volgende:
Als er een taal is die zo clean is als Java met de vrijheid van C++ dan teken ik daar gelijk voor.

Ik denk dat C# daar dan het dichst bij in de buurt komt (ik ken D niet)

[ACM]

Op zondag 02 september 2001 15:29 schreef Zef het volgende:
Ik denk dat C# daar dan het dichst bij in de buurt komt (ik ken D niet)

D schijnt een soort C++ + Java te zijn/worden.

Maar ik geloof dat de ontwikkeling net gestart is, wat ik ervan gezien heb was erg interessant.

[drm]

Dan kap ik meteen met alle onzin en ga die taal helemaal leren. Lijkt me heel rielekst...

Zijn er ergens beetje representatieve voorbeelden te vinden van D, wat het gaat worden (qua taal, dan)? Kon nix vinden...

[Verwijderd]

Op zondag 02 september 2001 13:30 schreef ACM het volgende:
Maar is dat nou zo'n algemeen doeleind dan?

Dat dacht ik niet.

Het is een doeleinde ja. Of deze nu vaak voor komt ja of nee, het is een doeleinde. Er er nog wel meer te vinden dit was een voorbeeld. En wat vind jij onder 'algemeen doeleind' vallen? Een doeleinde is een doeleinde en wat ik als voorbeeld nam gaat dus gewoon niet met Java.

Killemov:
Java draait in een virtuele machine. Deze virtuele machine moet compleet onafhankelijk zijn van je echte machine. (Voor zover dat mogelijk is, je ben nu eenmaal gebonden aan de grenzen die aan de echte machine zitten.) Een interrupt aanroepen is dus wel gebonden aan je fysieke machine en dus niet mogelijk.

Ja, daarom zeg ik dus ook, voor andere doeleinden ...

Oh, ja ... Wie is er ook alweer geen software engineer? Kun jij hier over meepraten? C++ vraagje

*zucht* ... moet ik hier nou echt serieus op ingaan? Nou vooruit dan, ik zal maar ff replyen...
Nee, als beroep ben ik geen software engineer nee (ik lijdt onder de 2e fase @ school dus ik werk niet bij een software bedrijf nee). Maar 'geen software engineer'... hehe, je moest eens weten. En ja ik kan in die thread meepraten ja, ik ben echt niet 'bang' voor assembler of zo hoor ... Ik vond het echt nogal een trieste vraag hoor ... Nou ja, dan doe ik er ook maar eentje he: Kun jij een eigen Operating System schrijven is dan mijn vraag?

[mbravenboer]

drm: Zijn er ergens beetje representatieve voorbeelden te vinden van D, wat het gaat worden (qua taal, dan)? Kon nix vinden...

Zoeken op D schiet ook niet zo op he? . Het stond een tijdje geleden op Slashdot geloof ik.

[tomato]

http://www.digitalmars.com/d

Waarom schiet zoeken op D niet op?

[mbravenboer]

tomato is ook niet voor niets Google spammer .

Zo fantastisch is D trouwens niet... Heb behoorlijk wat kritiek erop gelezen. Volgens mij wordt het ook niet echt serieus ondersteund door een of andere bedrijf of instelling.

[tomato]

Op zondag 02 september 2001 19:39 schreef mbravenboer het volgende:
tomato is ook niet voor niets Google spammer .

Exactly

Zo fantastisch is D trouwens niet... Heb behoorlijk wat kritiek erop gelezen.

Same here.

[.oisyn]

Op zondag 02 september 2001 19:39 schreef mbravenboer het volgende:
Volgens mij wordt het ook niet echt serieus ondersteund door een of andere bedrijf of instelling.

nee idd, ik denk dat het daarom ook totaal niet echt van de grond zal komen. Het lijkt meer iemand met het idee dat C++ eens een keer gereviseerd moet worden, dan dat er grote namen en standaardenorganisaties er mee bezig zijn.

[drm]

Op zondag 02 september 2001 19:35 schreef tomato het volgende:
http://www.digitalmars.com/d

Waarom schiet zoeken op D niet op?

Misschien niet goed genoeg mijn best gedaan ?

Interessant linkje. ff doorspitten...

OiSyN:
nee idd, ik denk dat het daarom ook totaal niet echt van de grond zal komen. Het lijkt meer iemand met het idee dat C++ eens een keer gereviseerd moet worden, dan dat er grote namen en standaardenorganisaties er mee bezig zijn.

Tja, je zal het toch ff de tijd moeten gunnen. Hoe lang bestaat Java nou al? Toch al wel een jaartje of 7, zo niet langer (exact weet ik het niet, er zijn er vast wel een paar die het wel weten).

Was sun toen al zo bekend? Het duurt gewoon een tijdje voor zoiets echt van de grond komt. En als de programmers-community het een goede uitweg vindt, dan is het binnen no-time een veel-gebruikte taal (om maar ff een open deur in trappen)

iig ga ik er even wat over lezen.

[drm]

Ik kom wel een paar rare dingen tegen, zeg:


• Types:

imaginaryan extended floating point value, but with imaginary type

• Empty Statement
een ; achter een while is gewoon leesbaar


• Statements:
Goto? Goto wilden we toch niet meer? Geeft toch ontraceerbare code


• Arrays
Wat is nou het verschil tussen "Pointers" en "Dynamic arrays"?
oftewel:

code:

int[]    a; // is a nou niet gewoon een pointer?
int     *p; // net als dat je p kan laten wijzen naar het eerste element in een array?

Zie evt. ook "Rectangular Arrays":

(Dynamic arrays are implemented as pointers to the array data.)

• Classes
Waarom zou je de get- en set-methods achterwege laten?

code:

class Abc
    {   int myprop;
        void property(int newproperty) { myprop = newproperty; } // set'er
        int property() { return myprop; }   // get'er
    }
    
/* 
which is used as: 
*/
    Abc a;
    a.property = 3;     // equivalent to a.property(3)
    int x = a.property;     // equivalent to int x = a.property()

Verlies je op deze manier niet behoorlijk wat structuur? Waar trek je nu de lijn tussen methode en eigenschap


• Embedding D in HTML
drm.setFacialExpression ( 6 x )
_{of moest het nou drm.facialExpression = 6 x zijn?}


• D Class Library

No user interface windowing classes
GUI styles, philosophies, etc., are not portable from machine to machine. A GUI Windows app should look like a Windows app when running on a Windows machine. It should not look and feel like a Mac app unless it is running on a Mac. Attempts to create a common GUI class library between Windows, Mac, and other GUI operating systems have all to my knowledge failed.
Java has a successful GUI class library, but does so by creating its own GUI with its own look and feel. This approach is fine for a web language, but not for a systems language like D is.

hmmm...


• Acknowledgements
Hierbij wil ik even zeggen dat ik trots ben op mijn neef, Jan Knepper (afgezien van zijn website)

_{------------------------------------------------------}
Ik geef verder dit project, deze taal erg veel kans. De robuustheid, het accent op X-platform, X-OS en X-systeem implementatie, de zachte compatibiliteit met C en C++ en de eigenschappen van Java die D ondersteunt, stemmen mij gerust dat deze taal absoluut voeten aan de grond gaat krijgen.
<sub>------------------------------------------------------


Vergeef mij mijn off-topic geblaat * drm pleads guilty</sub>

[Verwijderd]

Op zondag 02 september 2001 19:39 schreef mbravenboer het volgende:
tomato is ook niet voor niets Google spammer .

Zo fantastisch is D trouwens niet... Heb behoorlijk wat kritiek erop gelezen. Volgens mij wordt het ook niet echt serieus ondersteund door een of andere bedrijf of instelling.

Omdat alleen de algemene ideeen over de taal nog maar zijn bedacht. Er is nog geen praktische implementatie, protype model of zelfs maar een prototype-API te vinden.

Daar kan je dus als bedrijf nog niks mee.

Als het echt interessant is dan komt D vanzelf wel opzetten. Ik denk echter dat het voorlopig (komende 5 jaar) nog niks wordt. Het is namelijk door een persoon bedacht, niet door een standaard-/ISO-organisatie. Dan maak je niet veel kans vrees ik, in de grote wereld.

Tijdje geleden was er overigens ook een topic over D (geopend door /me * )

[.oisyn]

hah, mijn eigen bedachte taal, C *= 6, is veel beter dan D

[wasigh]

Op maandag 03 september 2001 12:15 schreef OiSyN het volgende:
hah, mijn eigen bedachte taal, C *= 6, is veel beter dan D

O ja op welke punten??

Welke eigenschappen zou een perfecte taal hebben?

[drm]

Alles in templates. Zelfs de syntax

[marcusk]

Op maandag 03 september 2001 10:07 schreef drm het volgende:
Ik kom wel een paar rare dingen tegen, zeg:
• Statements:
Goto? Goto wilden we toch niet meer? Geeft toch ontraceerbare code

Je kunt er zo iig voor kiezen of je het wilt gebruiken of niet.

• Arrays
Wat is nou het verschil tussen "Pointers" en "Dynamic arrays"?
oftewel:

code:

int[]    a; // is a nou niet gewoon een pointer?
int     *p; // net als dat je p kan laten wijzen naar het eerste element in een array?

Zie evt. ook "Rectangular Arrays":

Het verschil lijkt mij dat bij "Dynamic arrays" het geheugenmanagement voor je geregeld wordt.

• Classes
Waarom zou je de get- en set-methods achterwege laten?
Verlies je op deze manier niet behoorlijk wat structuur? Waar trek je nu de lijn tussen methode en eigenschap

properties vind ik ook behoorlijk evil, maar je kunt natuurlijk gewoon nog get/set functies kunt gebruiken als je wilt.

• Embedding D in HTML
drm.setFacialExpression ( 6 x )
_{of moest het nou drm.facialExpression = 6 x zijn?}

inderdaad nogal

Ik vind het verder wel een mooie taal.

[drm]

marcusk:
(over goto)
Je kunt er zo iig voor kiezen of je het wilt gebruiken of niet.

Uiteraard. Maar is het niet verstandig om dat soort dingen gewoon achterwege te laten. Leer jezelf gestructureerd te coden, waarbij (dacht ik) goto het evilste van het evilste was.

over dynamic arrays vs. pointers
Het verschil lijkt mij dat bij "Dynamic arrays" het geheugenmanagement voor je geregeld wordt.

Zit wat in....Sterker nog, je hebt gelijk

over properties
properties vind ik ook behoorlijk evil, maar je kunt natuurlijk gewoon nog get/set functies kunt gebruiken als je wilt.

Uiteraard. Eigenlijk zelfde verhaal als "goto"

over embedded HTML
inderdaad nogal

Als iemand me het uit kan leggen wat ze daar bedoelen, graag

Ik vind het verder wel een mooie taal.

Ik absoluut ook. Wat mij betreft introduceren ze het liever gister dan vandaag

[.oisyn]

ja sorrie hoor, maar totdat er in java of c een uitgebreidere break zit, blijf ik gewoon goto gebruiken. Okee, je kunt wel mooi een extra variabeletje aanmaken waarop wordt getest in de outer loop, maar echt efficient is dit niet.

neem bijvoorbeeld deze constructie:

code:

int i, j;

for (i = 0; i < numElements1; i++)
{
    for (j = 0; j < numElements2; j++)
    {
      if (elements1[i] == elements2[j])
        goto gevonden;
    }
}

// hier code voor geval niet gevonden
...
return;

gevonden:
// doe wat met de info

daar kan ik wel dit van maken:

code:

int i, j;
bool gevonden = false;

for (i = 0; i < numElements1 && gevonden; i++)
{
    for (j = 0; j < numElements2; j++)
    {
      if (elements1[i] == elements2[j])
      {
        gevonden = true;
        break;
      }
    }
}

if (!gevonden)
{
    // code voor geval niet gevonden
    ...
    return;
}

// doe wat met de info

maar dat is dus wel een test per iteratie van i plus nog een test aan het eind meer. Of ze moeten iets maken dat je uit meerdere loops kunt breaken (zoals ook min of meer in D zit ingebouwd)

[curry684]

Op maandag 03 september 2001 23:39 schreef OiSyN het volgende:
Of ze moeten iets maken dat je uit meerdere loops kunt breaken (zoals ook min of meer in D zit ingebouwd)

Je bedoelt return zoals de rest van de wereld die gebruikt? Mensen die het nut van een afzonderlijke functiecall kennen? Dit doe je dus gewoon zo:

code:

Element* MyClass::FindMatchingElement()
{
int  l_Index1;
int  l_Index2;

for(l_Index1 = 0; l_Index1 != ListCount1; l_Index1++)
  for(l_Index2 = 0; l_Index1 != ListCount2; l_Index2++)
    if(Elements1[l_Index1] == Elements2[l_Index2])
    return Elements1[l_Index1];

// If none found...
return NULL;
}

* curry684 vraagt zich af waarom zoveel mensen een excuus blijven zoeken om de grootste fout van C++ te mogen blijven gebruiken...

GOTO is heiligschennis. Punt.

Echte puristen vinden mijn voorbeeld ook fout, want dan mag er maar 1 return statement per functie bestaan: en dan moet je inderdaad aan de bools. Alles beter dan goto daarentegen.

[drm]

Euhhh, ten 1e: (zoals curry684 al zei) je kan op het moment dat er iets is gevonden returnen.

code:

for ( int i = 0; i < numElements1; i++)
{
    for ( int j = 0; j < numElements2; j++)
    {
      if (elements1[i] == elements2[j])
        return true;
    }
}
return false;

En als je dat niet wilt is er na de goto opeens niet meer duidelijk of het nou gevonden was of niet. Dat is dus het probleem met goto:

code:

int i, j, k;
for (i = 0; i < numElements1; i++)
{
    for (j = 0; j < numElements2; j++)
      if (elements1[i] == elements2[j])
        goto gevonden;
    for (k = 0; k < numElements3; k++)
      if (elements1[i] == elements3[j])
        goto gevonden;
    /*
    etcetera (afgezien van code efficientie, maar goed)
    */
}

// hier code voor geval niet gevonden
...
/* Stel nou dat ik hier nog niet wil returnen... */

gevonden:
/* was het hier nou gevonden of niet? En wat was er gevonden? How the h*ll ga je dat traceren? */

Waar blijft nou het hele idee van beslissingen maken op grond van variabelen? Je mag NOOIT je informatie verliezen op basis van assumpties! Grootse fout in programmeren!

curry648:

GOTO is heiligschennis. Punt.

Amen

Echte puristen vinden mijn voorbeeld ook fout, want dan mag er maar 1 return statement per functie bestaan: en dan moet je inderdaad aan de bools. Alles beter dan goto daarentegen.

Zit wel wat in, maar vind ik ietwat overdreven. In grotere functies kan je idd beter aan de bools, maar in kleine overzichtelijke functies kun je net zo goed meerdere returns hebben.

_edit:typo

[Verwijderd]

Op dinsdag 04 september 2001 00:50 schreef curry684 het volgende:
* curry684 vraagt zich af waarom zoveel mensen een excuus blijven zoeken om de grootste fout van C++ te mogen blijven gebruiken...

GOTO is heiligschennis. Punt.

Debatable....
Ik blijf goto een zinnig functie vinden zolang de programmeur weet waar ie mee bezig is.

Als je niet weet waar je mee bezig bent is goto inderdaad niet altijd zinnig maar om het dan meteen algemeen te verdoemen...

Ach, die discussie is al eerder geweest, doe maar niet

Echte puristen vinden mijn voorbeeld ook fout, want dan mag er maar 1 return statement per functie bestaan: en dan moet je inderdaad aan de bools. Alles beter dan goto daarentegen.

Maar daarom zit die functie toch juist in de taal?!? Ik vind het behoorlijk conservatief om vanuit puristisch oogpunt functies in een taal niet te gebruiken. Liever tien returns dan vijftienhonderd zinloze booleans. Dan verlies ik pas het overzicht!

[NiGeLaToR]

Op maandag 03 september 2001 10:30 schreef beelzebubu het volgende:

[..]

Omdat alleen de algemene ideeen over de taal nog maar zijn bedacht. Er is nog geen praktische implementatie, protype model of zelfs maar een prototype-API te vinden.

Daar kan je dus als bedrijf nog niks mee.

Als het echt interessant is dan komt D vanzelf wel opzetten. Ik denk echter dat het voorlopig (komende 5 jaar) nog niks wordt. Het is namelijk door een persoon bedacht, niet door een standaard-/ISO-organisatie. Dan maak je niet veel kans vrees ik, in de grote wereld.

Tijdje geleden was er overigens ook een topic over D (geopend door /me * )

misschien is M$'s C# wat voor je.. eerste lezingen waren veelbelovend. Soort Java voor op de proc. (Jaja, M$ zijn na apers, ik weet het )

[drm]

beelzebubu:

[..]

Debatable....
Ik blijf goto een zinnig functie vinden zolang de programmeur weet waar ie mee bezig is.

Als je niet weet waar je mee bezig bent is goto inderdaad niet altijd zinnig maar om het dan meteen algemeen te verdoemen...

Ach, die discussie is al eerder geweest, doe maar niet
[..]

Maar daarom zit die functie toch juist in de taal?!? Ik vind het behoorlijk conservatief om vanuit puristisch oogpunt functies in een taal niet te gebruiken. Liever tien returns dan vijftienhonderd zinloze booleans. Dan verlies ik pas het overzicht!

Nee, want die booleans hebben namelijk functie, dus zolang jij ze op een slimme c.q. gestructureerde manier gebruikt zijn ze altijd beter dan de goto.

En ik begrijp er helemaal niets van, dat goto nog in C, C++ en dus ook in D zit. Het verleidt je tot ongestructureerd programmeren. Het is gewoon een ongeschreven regel om geen goto te gebruiken. En er is geen enkele programmeur die het nodig heeft. Het is gewoon een lame uitkomst in alle gevallen.

[curry684]

Op dinsdag 04 september 2001 10:11 schreef beelzebubu het volgende:
Liever tien returns dan vijftienhonderd zinloze booleans. Dan verlies ik pas het overzicht!

Je kunt natuurlijk 1 bool declareren die EndLoop heet en deze 1500 keer recyclen...

Just a thought...

[Verwijderd]

Op dinsdag 04 september 2001 10:17 schreef nigelator het volgende:

[..]

misschien is M$'s C# wat voor je.. eerste lezingen waren veelbelovend. Soort Java voor op de proc. (Jaja, M$ zijn na apers, ik weet het )

""""ik heb geen mening over C#""""

ofzo.....

(anders gaat dit topic dicht wegens overmatig geflame)

[Verwijderd]

Op dinsdag 04 september 2001 10:50 schreef curry684 het volgende:

[..]

Je kunt natuurlijk 1 bool declareren die EndLoop heet en deze 1500 keer recyclen...

Just a thought...

Klopt op zich

Maar ook dan, dat sommige mensen "goto" irritant vinden, okee, kan ik inkomen. Maar return, daar kan ik dan ook echt niet iets van snappen.

code:

int search_in_array(int value, int array[], int array_length)
{
  int i;
  for (i=0;i<array_length;i++)
    if (array[i]==value)
    return i;
  return -1; /* not found */
}

of

int search_in_array(int value, int array[], int array_length)
{
  int i, j=-1;
  for (i=0;i<array_length;i++)
    if (array[i]==value)
    {
    j = i;
    break;
    }
  return j;
}

Dat is toch beiden 100% gestructureerd en duidelijk? Ik zie niet in wat er fout is met meerdere returns in een functie. De functie wordt er korter van en verder niet minder zinnig ofzo....

Nogmaals, in goto zie ik ook niets fout mits je het goed gebruikt, iets wat veel programmeurs niet kunnen. Maar ik zie wel in dat je het ongestructureerd zou kunnen vinden. Okee. Maar dat zie ik hier niet... Ik vind dat tweede voorbeeld onoverzichtelijker dan het eerste door de overmaat aan dubbele variabelen.

Of is "break" gebruiken ook onoverzichtelijk? En what about "continue"? Zeflde soort functies.....

[.oisyn]

Op dinsdag 04 september 2001 00:50 schreef curry684 het volgende:

[..]

Je bedoelt return zoals de rest van de wereld die gebruikt? Mensen die het nut van een afzonderlijke functiecall kennen? Dit doe je dus gewoon zo:

code:

Element* MyClass::FindMatchingElement()
{
int  l_Index1;
int  l_Index2;

for(l_Index1 = 0; l_Index1 != ListCount1; l_Index1++)
  for(l_Index2 = 0; l_Index1 != ListCount2; l_Index2++)
    if(Elements1[l_Index1] == Elements2[l_Index2])
    return Elements1[l_Index1];

// If none found...
return NULL;
}

* curry684 vraagt zich af waarom zoveel mensen een excuus blijven zoeken om de grootste fout van C++ te mogen blijven gebruiken...

GOTO is heiligschennis. Punt.

Echte puristen vinden mijn voorbeeld ook fout, want dan mag er maar 1 return statement per functie bestaan: en dan moet je inderdaad aan de bools. Alles beter dan goto daarentegen.

het was maar een simpel voorbeeldje hoor, stel nou dat je in die loops allemaal variabelen hebt die in die andere functies zijn uitgerekend enzo?! Dan gaat een aparte functie dus niet werken, of je moet al die dingen in een class/struct gooien, wat de leesbaarheid ook niet echt ten goede komt. Begrijp me niet verkeerd hoor, ik gebruik goto ook maar eens in de 3 jaar ofzo, maar ik ben nogal efficient ingesteld wat programmeren betreft, dus als ik zoiets als wat ik hierboven beschreven heb tegen kom gebruik ik gewoon goto.

[curry684]

Op dinsdag 04 september 2001 12:00 schreef beelzebubu het volgende:
Ik zie niet in wat er fout is met meerdere returns in een functie. De functie wordt er korter van en verder niet minder zinnig ofzo....

Het argument van de purist in deze is dat de eenduidige structuur verloren gaat: tegenover een single point of entry moet volgens deze leer EEN single point of exit staan. An sich voor sequence- en flowdiagrammen bepaald niet onlogisch overigens. Wel kut om te programmeren, en soms pijnlijk voor je performance.

Of is "break" gebruiken ook onoverzichtelijk? En what about "continue"? Zeflde soort functies.....

Continue is een stuk onduidelijker als break, en voor de puristen ook verboden terrein. Break is legaal bij gratie van switch, waar je niet zonder kunt...

Overigens mag het ook bekend zijn dat puristen enkel en alleen langzame bank- en DB-applicaties schrijven en geen benul van snelheid hebben.

[Verwijderd]

Op dinsdag 04 september 2001 12:23 schreef curry684 het volgende:
Continue is een stuk onduidelijker als break, en voor de puristen ook verboden terrein. Break is legaal bij gratie van switch, waar je niet zonder kunt...

Niet echt een overtuigend argument imho

Overigens mag het ook bekend zijn dat puristen enkel en alleen langzame bank- en DB-applicaties schrijven en geen benul van snelheid hebben.

Dat zal ik lekker als excuss aanvoeren om heerlijk eigenwijs en antipuristisch gewoon lekker continue, break en return door de hele functie heen te gebruiken.


Overigens, ik heb weleens geprobeerd me aan het "een return per functie" te houden maar de functie werd echt een ramp.

code:

functie()
{
  if (...)
  {
    bladieblo();
    if (...)
    {
     nogmeerbla();
     if (...)
     {
        enzovoorts();
        if (...)
        {
        en_hier_doet_de_functie_pas_wattie_moet_doen();
        }
     }
    }
  }
}

al die if()s zijn nodig om het volgen van lege pointers enzo tegen te gaan. if (variable != NULL)... if (variable->bla > waarde).... enzovoorts. Ik kon ze ook niet echt in een if() kwijt....

Heel irri en onoverzichtelijk werd het allemaal. Uiteindelijk dus maar gewoon weer teruggegaan naar het heel-veel-returns-per-functie gebeuren, werd er een stuk overzichtelijker van

code:

functie()
{
  if (!...) return;
  bladieblo();
  if (!...) return;
  nogmeerbla();
  if (!...) return;
  enzovoorts();
  if (!...) return;

  en_hier_doet_de_functie_pas_wattie_moet_doen();
}

[.oisyn]

Op dinsdag 04 september 2001 12:23 schreef curry684 het volgende:
Overigens mag het ook bekend zijn dat puristen enkel en alleen langzame bank- en DB-applicaties schrijven en geen benul van snelheid hebben.

Ik bedoel maar

[Verwijderd]

Op dinsdag 04 september 2001 12:23 schreef curry684 het volgende:
Break is legaal bij gratie van switch, waar je niet zonder kunt...

code:

boolean = FALSE;
switch (value)
{
case 1:
  if (!boolean)
  {
    boolean=TRUE;
    bla1();
  }
case 2:
  if (!boolean)
  {
    boolean=TRUE;
    bla2();
  }
case 3:
  if (!boolean)
  {
    boolean=TRUE;
    bla3();
  }
}

[drm]

Wordt een beetje zinloze discussie op deze manier.

Mijn stelling:
• Voorkom goto ten allen tijde.
Er is altijd een oplossing, en bij die oplossing is altijd te traceren wat het verloop van het programma is (hetzij door variabelen, hetzij door diepere geneste control-structures, etc).

[mbravenboer]

beelzebubu: """"ik heb geen mening over C#""""
(anders gaat dit topic dicht wegens overmatig geflame)

Ik ben eigenlijk wel benieuwd naar de reden van deze afschuw van C# (althans, dat maak ik op uit je woorden ). Er ik al verscheidene mensen horen zeggen dat ze een hekel C# hebben, zonder dat ik er ooit over in discussie ben gegaan. Als je zware argumenten (met taal-details kan je altijd oneens zijn) kunt noemen ben ik daar erg benieuwd naar.

[Reefer]

Op maandag 03 september 2001 14:08 schreef drm het volgende:
over embedded in HTML
Als iemand me het uit kan leggen wat ze daar bedoelen, graag
[..]

Je kunt je D-code in HTML zetten en hiermee "mooi" opmaken, en functies/methodes kun je links van maken naar andere classes (dus andere HMTLfiles) en deze HTML files kun je laten compilen, de compiler haalt dan alle HTML zooi weg.
denk ik

_{interessant draadje btw}


/edit
en toen zag ik de datum van de reply voor mij

[MSalters]

Op dinsdag 04 september 2001 12:00 schreef beelzebubu het volgende:

[..]


Maar ook dan, dat sommige mensen "goto" irritant vinden, okee, kan ik inkomen. Maar return, daar kan ik dan ook echt niet iets van snappen.

code:

int search_in_array(int value, int array[], int array_length)
{
  int i;
  for (i=0;i<array_length;i++)
    if (array[i]==value)
    return i;
  return -1; /* not found */
}

of

int search_in_array(int value, int array[], int array_length)
{
  int i, j=-1;
  for (i=0;i<array_length;i++)
    if (array[i]==value)
    {
    j = i;
    break;
    }
  return j;
}

Dat is toch beiden 100% gestructureerd en duidelijk? Ik zie niet in wat er fout is met meerdere returns in een functie. De functie wordt er korter van en verder niet minder zinnig ofzo....

Beide fout. Moet zijn

code:

std::find( array, array+array_length, value );

En ja, als ik een collega jouw oplossingen zie gebruiken dan laat ik hem dat wijzigen.

[MSalters]

Op zondag 02 september 2001 20:48 schreef OiSyN het volgende:

[..]

nee idd, ik denk dat het daarom ook totaal niet echt van de grond zal komen. Het lijkt meer iemand met het idee dat C++ eens een keer gereviseerd moet worden, dan dat er grote namen en standaardenorganisaties er mee bezig zijn.

Revisie traject (bij benadering):
2002-2004 Voorstellen.
2004/5 Technical report
2005/6 Drafting
2007 Nieuwe C++ standaard.

Overigens, er is maar 1 standaardorganisatie mee bezig, ISO.

Grootste ellende met revisies van C en C++ is overigens dat er veel software in geschreven was. Als er net zo vaak een nieuwe C of C++ revisie zou uitkomen als er Java revisies komen, dan zou je echt heel veel klachten krijgen van mensen die oude code hebben.

[MSalters]

Op dinsdag 04 september 2001 10:28 schreef drm het volgende:

[..]

En ik begrijp er helemaal niets van, dat goto nog in C, C++ en dus ook in D zit. Het verleidt je tot ongestructureerd programmeren. Het is gewoon een ongeschreven regel om geen goto te gebruiken. En er is geen enkele programmeur die het nodig heeft. Het is gewoon een lame uitkomst in alle gevallen.

goto zit in C en C++, omdat het nuttig is voor niet-menselijke programmeurs. De originele Cfront voor C++ genereerde geen assembly, maar C code vol met goto's. Dat soort tijdelijke code hoeft niet leesbaar te zijn, die wordt toch meteen gedeleted als die gecompileerd is.

Waarom zit er in elke assembly een unconditional JUMP ?

[MSalters]

Op vrijdag 31 augustus 2001 16:33 schreef drm het volgende:
Mag ik even?!

Paar puntjes

• Java is een veel nettere taal dan C++. De standaard C++ is verdwenen, er zijn te veel "toevoegingen" in de syntax gekomen in de loop der tijden (denk bijv. aan namespaces) wat de portabiliteit niet ten goede komt.

Fout. De standaard C++ is gekomen in 1998, maar de taal stond al in 1996 vast. Alleen de STL (=library) is daarna toegevoegd. Netter is overigens een beperkt begrip.
Ik heb in omgevingen met 15M regels C gewerkt, waar ze eigen namespace regels hadden bedacht. Die leken verdacht veel op C++ regels, alleen waren ze veel pijnlijker omdat de compiler niet meewerkte.
Werken in een taal zonder namespaces is net zoiets als werken in een OS zonder directories.

• De syntax van C++ is in opzet compacter (vind ik persoonlijk mooier).
• De OO van C++ is verder doorgevoerd. (denk bijv. aan multiple inheritance) Dat soort functionaliteit mis je in Java echter niet als je C++ niet gewend ben.
• De snelheid van Java zal alleen maar toenemen, de toekomst zal het leren of het voor real-time applicaties geschikt gaat worden

En van C++, Pascal, of C# niet? 90% van alle snelheidswinst is Hardware

• Tot nog toe is C++ een taal die in elke laag van een PC-systeem tot zijn recht kan komen,

Sterker nog, het is een taal die bijna elke laag van een systeem tot zn recht komt, ook als een systeem maar 256K geheugen heeft, geen beeldscherm, ...

[MSalters]

Op vrijdag 31 augustus 2001 18:05 schreef Otis het volgende:

[..]

typedefs mogen strict genomen van straustrupp ook niet
Maar waar ik op doelde was: templates genereren code, maar welke is pas duidelijk zodra je de templates doorneemt. Dat kan lastig zijn (idem voor operator overloads). Te pas en te onpas gebruiken kan leesbaarheid verlagend zijn.
[..]

Typedefs mogen best van Stroustrup. Ik heb hem ze zelf zien gebruiken...
En teveel van alles gebruiken is slecht voor de leesbaarheid. Bv. (((((((((1)))))))))

inderdaad. ik zat te slapen. #define is volgens straustrupp wel obsolete overigens, daar het bv macro's in de hand werkt (yuck) en constante definities op z'n 'C'-s.
[..]

Als je typesafe constantes toelaat heb je geen enums nodig, want alle constante's hebben al een type. Enums zijn dan alleen 'handig' voor rijtjes. Meer niet.

Dat is nou net de ellende, dat alle constantes hetzelde type hebben. Waarom zou enum filetype( file, dir ) en enum
accesstype( read, write ) hetzelfde type moeten hebben?
Als dat allebei ints zijn, dan kan ik file+read*2 doen.
Da's onzin. enum's zijn (ook) handig voor bitflags.

[MSalters]

Op zondag 02 september 2001 10:20 schreef jopiek het volgende:

Over 10 jaar vertellen ze iedereen dezelfde verhaaltjes over Java, dat Java verslagen wordt door taal X.

Ik vind dit allemaal maar onzinnige discussies....

Welnee, dan zeggen ze nog steeds dat Java 27.3 makkelijk C++ verslaat, en anders volgend jaar wel, als 28.1 uitkomt.

[emkedouwe]

Ik vind voor GUI altijd Visual basic nog de beste !!!!~

gewoon ff snel een interface maken
database koppelen

dat red je in java en c++ niet in 10 minuten !!!

[Korben]

Op maandag 03 december 2001 18:21 schreef emkedouwe het volgende:
Ik vind voor GUI altijd Visual basic nog de beste !!!!~

gewoon ff snel een interface maken
database koppelen

dat red je in java en c++ niet in 10 minuten !!!

_{heel harde schop}

Dat zal best, maar als jij met dat VB progje een paar miljoen records moet aanpassen (zeg 180 miljoen), dan is dat C++-progje al bezig met een tweede keer, terwijl VB nog ongeveer op driekwart van de eerste keer loopt te rommelen.

[The - DDD]

Altijd mooi om te zien dat de anti java zijde altijd schreeuwt dat java dood is.

Is dus absoluut niet het geval, je ziet Java alleen niet zo veel op je scherm. Het draait meer op de achtergrond op de server.

Als je Java met PHP bijvoorbeeld vergelijkt, dan is Java veel beter te schalen. Waarom is Got regelmatig plat/niet beschikbaar? Omdat dan de server vanwege de load op zijn bek is gegaan. Java heeft in eerste instantie meer overhead bij het starten, maar als het draait dan is het echt super. Er worden geen extra processen aangemaakt. Alles draait in dezelfde VM.

De snelheid van Java voor 1.3 was inderdaad bagger (wat betreft gui's dan). Alhoewel een netjes geprogrammeerde Applet in 1.1 vaak ook een hele goede optie is tegenover alsmaar nieuwe pagina's van de server laden.

[Verwijderd]

Wat een negatieve sfeer hangt er om de postings heen zeg Voor mijn gevoel krijg ik het idee alsof jullie zwaar pissed off jullie replies intikken. Het zal vast aan de toon liggen, maar echt vriendelijk is het allemaal niet.

[Bobco]

Op vrijdag 07 december 2001 10:00 schreef Xenophage het volgende:
[..]
Dat zal best, maar als jij met dat VB progje een paar miljoen records moet aanpassen (zeg 180 miljoen), dan is dat C++-progje al bezig met een tweede keer, terwijl VB nog ongeveer op driekwart van de eerste keer loopt te rommelen.

Wat ik mij altijd afgevraagd heb is waar dit verschil nu echt in zit. Als je kijkt naar taalconstructies zou het niet zoveel uit moeten maken: via een ODBC driver een database aanspreken is via een ODBC driver een database aanspreken, toch?

Ik kan me wel iets voorstellen bij zaken als memory management, support voor grote adress spaces, foutafhandeling en kwaliteit van de code die door de compiler gegenereerd wodt, maar wat is nu de belangrijkste oorzaak van dit verschil?

[roelio]

En oh wat zou het fijn zijn als we een keer ophouden over de platformonafhankelijkheid van Java want die *is* er niet. Waarom niet? Java bytecode draait op een Java processor. Deze processor wordt op andere platformen geemuleerd d.m.v. een JVM.
Dat is dus precies hetzelfde als een Windows emulator op bijvoorbeeld Linux. Kun je dus ook zeggen dat C++ met Win32 code platformonafhankelijk is. Waarom? Het draait immers ook onder Linux (maar wel met een tussenlaag!).

[Korben]

Op vrijdag 07 december 2001 11:40 schreef Bobco het volgende:

[..]

Wat ik mij altijd afgevraagd heb is waar dit verschil nu echt in zit. Als je kijkt naar taalconstructies zou het niet zoveel uit moeten maken: via een ODBC driver een database aanspreken is via een ODBC driver een database aanspreken, toch?

Ik kan me wel iets voorstellen bij zaken als memory management, support voor grote adress spaces, foutafhandeling en kwaliteit van de code die door de compiler gegenereerd wodt, maar wat is nu de belangrijkste oorzaak van dit verschil?

Tja, dingen als dynamic allocation enzo, dat kent VB nou eenmaal niet, maar grote address spaces wel. Je kunt zonder problemen 4GB aan strings aanmaken. Als je tenminste genoeg geheugen hebt. Ik weet niet precies hoe ODBC werkt (met directe function calls of met callbacks oid) maar als het met callbacks zou werken dan zou de bottleneck zitten in het feit dat een VB-engine een stukje tussencode moet gebruiken, terwijl C++ dat niet hoeft (VB hoort volgens M$ geen callbacks te ondersteunen, blijkbaar).

[PolarWolf]

Op vrijdag 07 december 2001 11:40 schreef Bobco het volgende:

[..]

Wat ik mij altijd afgevraagd heb is waar dit verschil nu echt in zit. Als je kijkt naar taalconstructies zou het niet zoveel uit moeten maken: via een ODBC driver een database aanspreken is via een ODBC driver een database aanspreken, toch?

Ik kan me wel iets voorstellen bij zaken als memory management, support voor grote adress spaces, foutafhandeling en kwaliteit van de code die door de compiler gegenereerd wodt, maar wat is nu de belangrijkste oorzaak van dit verschil?

ODBC?
Als je wat traag wilt laten uitvoeren moet je het vooral via nog meer lagen doen.
Direct op de database gaan zitten met de bijgeleverde libraries lijkt mij handiger...en dat lukt met C/C++ en ik geloof zelfs met Java nog altijd beter dan met VB.
Hoewel ADO niet al te slecht is...

[Verwijderd]

Op vrijdag 07 december 2001 13:30 schreef Xenophage het volgende:
Tja, dingen als dynamic allocation enzo, dat kent VB nou eenmaal niet, maar grote address spaces wel. Je kunt zonder problemen 4GB aan strings aanmaken. Als je tenminste genoeg geheugen hebt.

Incorrect, er is een limitatie in het standaard win32 platform wat je adress space limiteerd tot 2GB, in de enterprise versie van NT4 is dit nog op te hogen naar 3GB maar dan dient de applicatie in z'n pe header wel aan te geven dat ie hier op voorbereid is. in de w2k versies (datacenter enzo) ligt deze limiet nog hoger maar ook daar geld dat je applicatie er op voorbereid moet zijn,in VB zit je gewoon aan max van 2GB.

[Korben]

Op vrijdag 07 december 2001 13:44 schreef Yarvieh het volgende:

[..]

Incorrect, er is een limitatie in het standaard win32 platform wat je adress space limiteerd tot 2GB, in de enterprise versie van NT4 is dit nog op te hogen naar 3GB maar dan dient de applicatie in z'n pe header wel aan te geven dat ie hier op voorbereid is. in de w2k versies (datacenter enzo) ligt deze limiet nog hoger maar ook daar geld dat je applicatie er op voorbereid moet zijn,in VB zit je gewoon aan max van 2GB.

Juist, 2 GB, sorry Yarvieh, kwas ff beetje wazig. Jij niet blijkbaar, hoe doe je dat toch na een hele week?

Uhm maar ff weer on-topic, address space, hoe ging dat ook alweer, per thread, process of applicatie?

[Verwijderd]

Op vrijdag 07 december 2001 13:51 schreef Xenophage het volgende:
Uhm maar ff weer on-topic, address space, hoe ging dat ook alweer, per thread, process of applicatie?

Per process.

[Korben]

Op vrijdag 07 december 2001 13:56 schreef Yarvieh het volgende:

[..]

Per process.

Dan zou het wel kunnen, maak gewoon 2 processes en voila 4 GB aan totale address space. Moet je alleen wel je strings kunnen uitwisselen tussen de processes.

[Verwijderd]

Op vrijdag 07 december 2001 14:05 schreef Xenophage het volgende:
Dan zou het wel kunnen, maak gewoon 2 processes en voila 4 GB aan totale address space. Moet je alleen wel je strings kunnen uitwisselen tussen de processes.

Dat is geen punt, IPC mechnismen genoeg, gezien het hier over VB gaat ga je denk ik uit komen op (D)COM. Ander intresant punt is waarom zou iemand die applicaties maakt die zo geheugen intensief zijn VB gebruiken?!

[Verwijderd]

weet je wat pas écht kickass is?
JSP icm Lotus Domino/Notes.
Ben nog wel bezig met JSP te leren, maar tot nu toe ben ik zwaar impressed, iig veel meer als toen ik aan PHP begon, PHP is trouwens scripting imo, JSP vind ik al veel dichter bij programmeren aanleunen, beter nog, het is gewoon programmeren.

[Korben]

Op vrijdag 07 december 2001 14:12 schreef Yarvieh het volgende:

[..]

Dat is geen punt, IPC mechnismen genoeg, gezien het hier over VB gaat ga je denk ik uit komen op (D)COM. Ander intresant punt is waarom zou iemand die applicaties maakt die zo geheugen intensief zijn VB gebruiken?!

Hum... you got me beat. Maar goed het ging mij erom dat je in VB gewoon de hele address space kunt gebruiken. Zowiezo zou ik voor geheugenintensieve programma's C/C++ gebruiken. VB is gewoon voor heej-ik-heb-binnen-2-dagen-een-programma-nodig-dat-ik-niet-zo-snel-in-C++-kan-bouwen oplossingen.

[PolarWolf]

Op vrijdag 07 december 2001 14:21 schreef SM-DoubleD het volgende:
weet je wat pas écht kickass is?
JSP icm Lotus Domino/Notes.
Ben nog wel bezig met JSP te leren, maar tot nu toe ben ik zwaar impressed, iig veel meer als toen ik aan PHP begon, PHP is trouwens scripting imo, JSP vind ik al veel dichter bij programmeren aanleunen, beter nog, het is gewoon programmeren.

JSP'tjes zijn eigenlijk Servlets die on-the-fly worden gecompiled (en vervolgens gecached)...dus je bent inderdaad gewoon aan het programmeren.