[Alg] beste programmeertaal om mee te beginnen?

[.oisyn]

Macros schreef op 27 november 2003 @ 20:39 iets over genericiteit

je hebt het daar over het concept, zoals MSalters al zei. Generics zoals in Java en .Net zijn wat anders dan C++ templates.

In java en .net wordt er namelijk niet aparte code gegenereerd voor functies en/of classes. Vandaar dat het ook prima past in de intermediate languages van Java en .net. Daar hoeft de implementatie ook niet bekend te zijn om een nieuw type te instantieren, en de gegeneralizeerde classes en methoden kunnen van tevoren gecompileerd worden.

Bij C++ templates ligt dat heel anders: je krijgt bijna letterlijk een substitutie van de template parameters, en op instantiatie-moment wordt er pas code gegenereerd. Vandaar dat je met C++ templates dingen hebt als (partial) specialization, en ander soort template parameters, zoals integral types, (member)pointers, etc. Dat is echt compleet wat anders dan generics zoals gebruikt in java en .net, en het gaat ook een heel stuk verder

[curry684]

.oisyn schreef op 27 november 2003 @ 22:51:
[...]
je hebt het daar over het concept, zoals MSalters al zei. Generics zoals in Java en .Net zijn wat anders dan C++ templates.

Het grote verschil in insteek (en aannames hier) is dat generics niet per definitie templates zijn. Templates zijn wel per definitie een vorm van generic programming.

Zeg maar: een koe is wel vee, maar vee is geen koe

In C++ is generics geimplementeerd als templates, wat inderdaad een heel erg krachtig en flexibel systeem is, wat Java niet heeft, maar alles wat je met generics kan, kan je ook en flexibeler (wel langzamer) met Objects in Java en PHP heeft er al helemaal geen last van omdat die helemaal geen typing heeft.

DIt is dus een fundamenteel foute aanname. Templates zijn in C++ ook overbodig: alles wat je ermee kunt is ook te doen door heel veel typwerk, macro's en/of virtual functies. Het feit dat het voor generieke concepten zoals containers een veel summierdere en helderdere en typesaferdere ( ) notatie levert bepaalt de grote levensvatbaarheid van templates in C++.

Stroustrup heeft in "The C++ Programming Language" een hoofdstuk vol geschreven over waarom de containers van de STL als templates zijn geimplementeerd op de huidige manier, en waarom alternatieven met virtuals e.d. allemaal afvielen, met voor iedere mogelijkheid alle pro's en con's op een rij gezet. Erg interessant leesvoer.

Ik zie hier ook klassiek gevloek op de mogelijkheid van macro's in C++. Laat ik als toch wel zachtjes ervaren programmeur zeggen: macro's zijn fantastisch, macro's zijn allesbehalve evil. Abuse van macro's is evil, en hard ook. Maar goed gebruikt op de goede plekken kun je met macro's fantastische stunts uithalen die hopeloos goed leesbare en krachtige code kunnen reproduceren (oisyn weet in dat verband nog wel hoe ik bijv. code schrijf die in releasebuilds callstacks en profiling optioneel produceert). Macro's bieden je ook de mogelijkheid om language extensions te maken die veelgedane taken uniform continu op dezelfde manier uitvoert en daarmee de mogelijkheid tot typfouten reduceert tot nul.

Macro's per definitie tot evil reduceren getuigt van kortzichtigheid en/of gebrek aan passende ervaring met de goede toepassingen ervan.

[Macros]

MSalters schreef op 27 november 2003 @ 21:42:
[...]

Ik heb een vermoeden dat ik dat college ken. Sterker nog, ik heb het gevoel dat ik dat college 2 jaar geleden zelf heb gegeven TU Delft, ITS? En ik heb het vermoeden dat dit jaar JC van Winkel het college gaf?

In elk geval is er een verschil tussen Generic Programming, het concept en Generics zoals ze in Java 1.5 zitten. Een uitwerking van het eerste vind je in Advanced C++, wat de Loki library presenteert. Dat is een library die bekende patterns in code uitdrukt. Met Java's generics lukt dat niet.

Ja, JC deed het deze keer, hij deed het erg goed. Vorig jaar deed ik het college ook al, alleen toen heb ik erg veel colleges gemist, ook het C++ college.

[Macros]

curry684 schreef op 28 november 2003 @ 00:05:Iets over generics in C++ .

Wat jij nu zei zeg ik toch ook, dat generics is geimplementeerd is als templates. We moeten vee hebben! Laten we koeien nemen!

Als we het toch over evil code hebben. C++ heeft meer mogelijkheden dan C om evil code te schrijven. Laatst vroeg ik me af wat de sneltste manier is om uit een dubbele while/for loop te springen zonder een return te gebruiken om uit een functie te springen en dat was toch echt een goto jump. Wat ik me daarna afvroeg, kan je ook naar een label in een andere functie of een hogere scope springen? Zo ja, worden dan de stack geschoont van de functie calls waar je uit springt? Als dat niet gebeurd, kan dat dan slechte invloed op je programma hebben? Vreemd gedrag, memory leaks en dergelijke?

Toen ik 12 was in Basic schreef op de Commodore 64 was er alleen maar goto en gosub, dus toen verneukte goto's de gosubs niet, ook waarschijnlijk omdat je gosubs niet kon nesten (als ik me goed herinner)

[alienfruit]

Waarom geen discussie over Java vs. C#

[curry684]

Macros schreef op 28 november 2003 @ 00:14:
[...]
Als we het toch over evil code hebben. C++ heeft meer mogelijkheden dan C om evil code te schrijven. Laatst vroeg ik me af wat de sneltste manier is om uit een dubbele while/for loop te springen zonder een return te gebruiken om uit een functie te springen en dat was toch echt een goto jump. Wat ik me daarna afvroeg, kan je ook naar een label in een andere functie of een hogere scope springen? Zo ja, worden dan de stack geschoont van de functie calls waar je uit springt? Als dat niet gebeurd, kan dat dan slechte invloed op je programma hebben? Vreemd gedrag, memory leaks en dergelijke?

Ach ik heb Stroustrup hier toch liggen, hoofdstuk 6.3.4 dus:

6.3.4 Goto

C++ possesses the infamous goto:

goto identifier ;
identifier : statement

The goto has few uses in general high-level programming, but it can be very useful when C++ code is generated by a program rather than written directly by a person; for example, gotos can be used in a parser generated from a grammar by a parser generator. The goto can also be important in the rare cases in which optimal efficiency is essential, for example, in the inner loop of some real-time application.

The scope of a label is the function it is in. This implies that you can use goto to jump both into and out of blocks. The only restriction is that you cannot jump past an initializer or into an exception handler.

One of the few sensible uses of goto in ordinary code is to break out from a nested loop or switch-statement (a break breaks out of only the innermost enclosing loop or switch-statement).

En ook voor dat laatste 'sensible' use is het in het algemeen evil en lelijk

Goto is gewoon generally accepted als een nutteloos concept tenzij je idd in realtime 100% timecritical applications zit waar de compiler je bedoeling anders net niet goed snapt (zelden dus).

Toen ik 12 was in Basic schreef op de Commodore 64 was er alleen maar goto en gosub, dus toen verneukte goto's de gosubs niet, ook waarschijnlijk omdat je gosubs niet kon nesten (als ik me goed herinner)

Je had toen ook geen variabelen op de stack maar alleen return positions

[.oisyn]

Macros schreef op 28 november 2003 @ 00:14:
Wat ik me daarna afvroeg, kan je ook naar een label in een andere functie of een hogere scope springen?

andere functies kan natuurlijk niet met puur C++. Wat hoogstens kan is gebruik te maken van setjmp() en longjmp (), maar die moet je absoluut niet gebruiken in C++ code omdat ze niet de C++ object semantics ondersteunen. C++ is daar verder heel correct in: objecten op de stack worden altijd netjes geconstruct en gedestruct. Zoals curry al zei, springen voorbij een initializer kan niet, maar uit een scope springen kan altijd: alles wordt netjes opgeruimd. Ook bij het gooien van een exception wordt alles goed opgeruimd.

Sterker nog, destructor calls zijn de methode voor exception safe programming. Als je een stukje code hebt dat opruimwerk doet als de functie exit dan kun je dat in een destructor van een class gieten. Als je daar een instantie van maakt op de stack, dan wordt ie altijd gedestruct, ook al wordt er ergens een exception gegooid. Op die manier kun je bepaalde niet-atomaire acties dus rollbacken. Als er een exception optreedt tussen 2 acties kun je de eerste ongedaan maken, zodat je programma in een consistente staat blijft.

Deterministic finalization komt ook in vs.net whidbey , iets wat java en .net nu toch wel sterk missen

[ Voor 6% gewijzigd door .oisyn op 28-11-2003 01:22 ]

[Verwijderd]

misschien een goed idee om gewoon een sticky te maken van het onderwerp " wat is de beste programmeeertaal"

het komt toch zo eens in de 2 weken terug... en de trend is steeds het zelfde het wordt een flame of het word een rant

[Macros]

Verwijderd schreef op 28 november 2003 @ 07:17:
misschien een goed idee om gewoon een sticky te maken van het onderwerp " wat is de beste programmeeertaal"

het komt toch zo eens in de 2 weken terug... en de trend is steeds het zelfde het wordt een flame of het word een rant

Ik heb niet echt een rant gezien, en al helemaal geen flame.
Ik denk dat het over het algemeen geen ruk uit maakt welke programmeer taal je mee begint. Het is alleen belangrijk dat je de eerste paar stappen gestructureerd neemt en niet helemaal alles je zelf aanleert, wat kan leiden tot jaren lange training om dingen opnieuw goed te leren. Kies een taal die je het makkelijkst lijkt, ik zou met PHP beginnen als ik nu kon kiezen. Is erg vergevings gezind, en heeft redelijk veel feutures die je kan leren. Als je dan een beetje kan programmeren kan je een andere taal nemen die meer past bij wat je dan wilt.
Bijkomend voordeel van PHP is dat je vaak meteen HTML, SQL leert.

[whoami]

Macros schreef op 28 november 2003 @ 08:33:
[...]
Bijkomend voordeel van PHP is dat je vaak meteen HTML, SQL leert.

Bij iedere applicatie die je wilt schrijven die gegevens in een DB propt en er weer uithaalt, zal je SQL moeten leren. Dat heeft dus niets met PHP op zich te maken ofzo.
Trouwens, als je SQL leert mbhv MySQL (wat veel het geval is als je met PHP aan de slag gaat), dan leer je bepaalde dingen mbt SQL fout, dat heb ik hier al genoeg gezien.

[Skaah]

Superlogo!

code:

leer start
penneer
herhaal 4 zijde
wacht 10
penop
eind

leer zijde
vooruit 100
rechts 100
eind

[ Voor 4% gewijzigd door Skaah op 28-11-2003 09:05 ]

[whoami]

alienfruit schreef op 28 november 2003 @ 00:25:
Waarom geen discussie over Java vs. C#

Omdat we die al eens gehad hebben:
[rml][ Alg]Is C# een Java-clone? Waarom of waarom niet[/rml]

[Riegstar]

Verwijderd schreef op 27 november 2003 @ 22:03:
euh..

bedankt allemaal van jullie aandacht hehe..

maar nu weet ik het niet meer goed

iedereen zegt wat anders

sinds gisteravond gepost en nu al 90 berichtjes ofzo .

wat is c en c++ ofzo voor een programma? want dat hoor ik het meeste hier...

alvast bedankt voor jullie aandacht

Ik begrijp hieruit dat je door de bomen het bos niet meer ziet.
Want je vraag blijft natuurlijk staan: Welke taal....

Voor web:
Serverside: php of asp
Clientside: java (applets)

Voor windows / GUI:
Delphi
C++
Visual Basic
C# of VB.NET (.NET heeft toekomst maar hogere systeem/software eisen)
Java (vereist iets meer werk voor GUI)

Voor console:
Java
C
C++

Dos:
Modula
Pascal
C

Dus ieder taal/omgeving heeft voor- en na-delen.

[whoami]

Het belangrijkste is dat je leert programmeren. Niet dat je een taal leert.
Het is natuurlijk wel nodig dat je leert programmeren dmv een taal, maar die taal is een middel, geen doel.
Met talen zoals C++, pascal, Java en C# kan je imho goed leren programmeren. Je wordt gedwongen om nette/gestructureerde code te schrijven. De talen zijn wmb goed geschikt om de basisbeginselen van 't programmeren onder de knie te krijgen. Als je die basis hebt en snapt, kan je nog altijd verder bouwen met dezelfde taal om de wat geavanceerdere principes onder de knie te krijgen.

[Alarmnummer]

.oisyn schreef op 27 november 2003 @ 22:51:
[...]
je hebt het daar over het concept, zoals MSalters al zei. Generics zoals in Java en .Net zijn wat anders dan C++ templates.

In java en .net wordt er namelijk niet aparte code gegenereerd voor functies en/of classes.

In .NET gebeurt dit wel, gelukkig vind dit runtime plaats (lees anders de documentatie van Gyro maar eens). Dit heeft als voordeel dat dat je niet van te voren alles hoeft uit te compileren (voor alle types de code te maken) en dat je dit kan:

code:

void foo(List<X> l){
      foo(List<List<X>> null)
}

[edit]
oeps.. haakjes vergeten

Dit het polymorfe recursie en dat vind c++ niet leuk. .NET en java hebben er geen problemen mee.

Dat is echt compleet wat anders dan generics zoals gebruikt in java en .net, en het gaat ook een heel stuk verder

ALs je gaat kijken naar de details dan is de werking idd heel anders. Maar als je aan een leek uit moet leggen, dan vind ik templates toch erg veel lijken op generics. Ik zou er niet zo moeilijk over doen om het verschil zo duidelijk te maken.

[ Voor 10% gewijzigd door Alarmnummer op 28-11-2003 10:28 ]

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 19-02-2015 00:00 ]

[Alarmnummer]

Eelis schreef op 28 november 2003 @ 10:15:
[...]

Kun je dit fragment misschien meer toelichten? Zijn dit twee functies? Zo nee, wat is dan het idee van deze constructie? (En zo ja, is er een reden dat het returntype van de tweede functie mist?)

Dit is een recursieve aanroep van de functie foo. Stel dat je de eerste keer aanroept met List<int>, dan zal dit de 2e keer een aanroep zijn naar List<List<int>> en ik neem aan dat je wel aanvoelt dat dit wel een tijdje door kan gaan. Een c++ compiler kan hier onmogelijk alle code voor genereren omdat hij compiletime alles wil maken. Als je het lazy gaat doen (runtime), dan kan het wel (gyro).

[edit]
Ik zie dat ik de haakjes helemaal vergeten ben.. *eet hand vol koffie (is veel geconcentreerder)*...

[ Voor 13% gewijzigd door Alarmnummer op 28-11-2003 10:31 ]

[drm]

curry684:
Goto is gewoon generally accepted als een nutteloos concept tenzij je idd in realtime 100% timecritical applications zit waar de compiler je bedoeling anders net niet goed snapt (zelden dus).

Ik begrijp hieruit dat een goto eigenlijk alleen (goed) gebruikt wordt om uit meerdere levels te "breaken".

Om maar even een achterlijk (en vooral zinloos) voorbeeld te geven:

C++:

#include <iostream>

int main () {
   int a;
   for ( int i = 1; i < 16; i++ ) {
      a = i % 3;
      switch ( a ) {
         case 1:
            std::cout << "woei";
         case 2:
            break;
         case 0:
            std::cout << "spef!";
            goto end_for;
      }
   }
   end_for:
   return 0;
}

Waarom heeft ons Bjarne dan niet het ingenieuze break [level]; geintroduceerd? Dus dat je regel 14 hier vervangt door

C++:

break 2; // break for-loop

Enig idee

[.oisyn]

Alarmnummer schreef op 28 november 2003 @ 09:42:
[...]

In .NET gebeurt dit wel, gelukkig vind dit runtime plaats (lees anders de documentatie van Gyro maar eens). Dit heeft als voordeel dat dat je niet van te voren alles hoeft uit te compileren (voor alle types de code te maken)

compileren voor andere typen, zelfs at runtime, lijkt me een beetje nutteloos. Immers, je template parameters voldoen aan een bepaalde specificatie, het moet een bepaalde interface implementeren of een class extenden. Je kunt dus prima met de base class werken.

Het verschil in code zit 'm vervolgens in het gebruik van die template functie of class. Want als je een generic functie hebt zoals bijvoorbeeld (en ik ken de notatiewijze verder niet, maar dit is wel begrijpbaar denk ik)

Java:

generic<T extends Object> T eenFunctie (T t);

En je stopt er een MyClass in, dan verwacht je er ook een MyClass weer uit. Intern werkt de functie echter gewoon op Object. In feite zijn de volgende 2 regels code dan ook identiek:

Java:

MyClass c = eenFunctie<MyClass> (c);
MyClass c = (MyClass)eenFunctie ((Object)c);

(waarbij de cast naar Object op regel 2 slechts ter illustratie dient)
Intern aan eenFunctie hoeft er niets te veranderen aan de code. Wat erbij komt is slechts een cast op het eind naar MyClass (en de impliciete cast naar Object bij het argument).

En daarom is het mijs inziens ook fundamenteel anders dan C++ templates, waar er een lexicale substitutie plaatsvindt bij de template parameters.

C++:

template <class T>
void roepEenFunctieAan (T & t)
{
    t.eenFunctie ();
}

struct A
{
    void eenFunctie () { std::cout << "hoi" << std::endl; }
};

struct B
{
    struct functor
    {
        int operator () (int i = 0)
        {
            return i + 10;
        }
    };

    functor eenFunctie;
};

int main ()
{
    A a;
    B b;
    roepEenFunctieAan (a);
    roepEenFunctieAan (b);
}

A::eenFunctie en B::eenFunctie zijn compleet anders. Bij A is het gewoon een functie zonder parameters en returntype. Bij B is het een object, dat door middel van operator overloading aan te roepen is als een functie. En het heeft bovendien een compleet andere signature dan A::eenFunctie. A en B hebben totaal niets met elkaar gemeen, ze voldoen niet aan een bepaalde gespecificeerde interface oid. Dit werkt ook alleen maar als roepEenFunctieAan<A> en roepEenFunctieAan<B> totaal verschillende stukjes code produceren. En dit werkt dan ook alleen maar als de implementatie at compile-time bekend is (met uitzondering van het export keyword, waarmee de compilatie verplaatst kan worden naar link-time)


Ik moet er overigens wel bijzeggen dat ik eigenlijk alleen java generics ken, en alleen maar een beetje (door discussies van oa mbravenboer ). Uit de presentatie van visual c++ whidbey heb ik begrepen dat generics in .net ook ongeveer zo werkt als in java, en heel anders is dan c++ templates (anders is het ook vrij onlogisch om generics naar c++ te brengen, wat dus gebeurt in whidbey ). Ik zal vanavond als ik tijd heb de docs van Gyro eens doornemen, lijkt me wel interessant

[curry684]

drm schreef op 28 november 2003 @ 11:30:
Waarom heeft ons Bjarne dan niet het ingenieuze break [level]; geintroduceerd? Dus dat je regel 14 hier vervangt door

C++:

break 2; // break for-loop

Grote vraag inderdaad. Ik vind die syntax trouwens ook niet prettig: nodigt enorm uit tot fouten als je een nestlaag toevoegt. De beste oplossing imho zou zijn:

C++:

while(true)
  for(int i = 0; i != 1000; i++)
    switch(Value[i])
      {
      case BreakOutOfForBlock:
        break for;
      case BreakOutOfInnerBlock:
        break;
      case BreakOutOfSwitchBlock:
        break switch;
      case BreakOutOfWhileBlock:
        break while;
      }

Hier zou je vrijwel alle gevallen mee af kunnen vangen, het is taaltechnisch zuiver en introduceert geen nieuwe keywords. Aan de andere kant heb ik in een jaar of 8 C++ development nog nooit goto gemist of uberhaupt overwogen 'm te gebruiken: de constructie is echt obsolete en imho blijft het een teken van slechte programmeerinzichten als je 'm wilt/moet gebruiken.

Het eeuwige enige voorbeeld van de nuttige goto is de 5-dubbel geneste for-loop. Wanneer gebruik je echter 5-dubbel geneste for-loops? Alleen bij lookups. Wat is een voordeel aan lookups? Ze zijn generiek herbruikbaar voor de lijst, niet alleen voor 1 functie. Waarom schrijf je de lookup dan uit in de functie? Maak gewoon een aparte FindXXX(...) functie en return zodra je gevonden hebt, exit alle goto-problemen...

[whoami]

Over de verschillen mbt C++ templates / Java Generics en de generics in C# (.NET):

Differences between C# generics and other implementations
C++ templates differ significantly from C# generics. Where C# generics are compiled into IL, causing specialization to occur intelligently at run-time for each value type and once only for reference types, C++ templates are essentially code expansion macros that generate a specialized type for each type parameter supplied to a template. So, when the C++ compiler encounters a template, say a Stack of integers, it will expand the template code into a Stack class that contains integers internally as its native type. Regardless of whether the type parameter is a value or reference type, unless the linker is specifically designed to reduce code bloat, the C++ compiler will create a specialized class each time, resulting in a significant increase in code bloat over C# generics.

Moreover, C++ templates cannot define constraints. C++ templates may only define constraints implicitly by simply using a member that might or might not belong to the type parameter. If the member does exist in the type parameter that is eventually passed to the generic class, the program will work properly. If the member does not exist in the type parameter, the program will fail and a cryptic error message will likely be returned. Because C# generics can declare constraints and are strongly typed, these potential errors do not exist.

Meanwhile, Sun has proposed the addition of generics in the next version of the Java language, codenamed Tiger. Sun has chosen an implementation that does not require modifying the Java Virtual Machine. As such, Sun is faced with implementing generics on an unmodified virtual machine.

The proposed Java implementation uses similar syntax to templates in C++ and generics in C#, including type parameters and constraints. But, because it treats value types differently than reference types, the unmodified Java Virtual Machine will not be able to support generics for value types. As such, generics in Java will gain no execution efficiency. Indeed, the Java compiler will inject automatic downcasts from the specified constraint, if one is declared, or the base Object type, if a constraint is not declared, whenever it needs to return data. Further, the Java compiler will generate a single specialized type at compile-time that it will then use to instantiate any constructed type. Finally, because the Java Virtual Machine will not support generics natively, there will be no way to ascertain the type parameter for an instance of a generic type at run-time and other uses of reflection will be severely limited.

Meer info:
[rml][ .NET] New language features in C#[/rml]

[PeeJay]

.oisyn schreef op 27 november 2003 @ 16:35:
[...]

het is natuurlijk subjectief, maar ik denk dat je dan niet genoeg ervaren was in C++.

Ben ik wel met je eens. Toen was ik nog maar net 18 en zat het logisch denken nog niet op een redelijk niveau.
Toch vind ik Java tegenwoordig fijner werken. Maar dat komt waarschijnlijk omdat de opdrachten hier makkelijker (sneller) op te lossen zijn met Java. Ik steek gewoon veel minder tijd in C++, waardoor het omschakelen ook bemoeilijkt wordt.

Dat betwijfel ik ten zeerste. 5000 regels vind ik niet bepaald klein (comments tellen niet mee natuurlijk), dat code je denk ik niet in een week als je er ook nog over na moet denken (en dus niet simpel typwerk, zoals het ophalen of initialiseren van allerlei data enzo)

Als je met een groep van 5 man werkt, valt de tijd die je nodig hebt reuze mee

[drm]

curry684:
Grote vraag inderdaad. Ik vind die syntax trouwens ook niet prettig: nodigt enorm uit tot fouten als je een nestlaag toevoegt. De beste oplossing imho zou zijn:

code:

snipz0r

daar zit een zelfde soort probleem in, namelijk dat als je 2 while loops genest hebt je dus alleen of de "dichtsbijzijnde" while kan breaken of de "verste". Dan zou een nummertje toch sort of inevitable zijn Maar goed.

Hier zou je vrijwel alle gevallen mee af kunnen vangen, het is taaltechnisch zuiver en introduceert geen nieuwe keywords. Aan de andere kant heb ik in een jaar of 8 C++ development nog nooit goto gemist of uberhaupt overwogen 'm te gebruiken: de constructie is echt obsolete en imho blijft het een teken van slechte programmeerinzichten als je 'm wilt/moet gebruiken.

Ben ik met je eens inderdaad. Misschien is dat ook wel de reden dat een dergelijke break constructie niet bestaat, juist omdat het uitnodigt tot vreemde constructies/luie oplossingen? Who knows

[Eelis]

.

[ Voor 103% gewijzigd door Eelis op 19-02-2015 00:00 ]

[curry684]

Eelis schreef op 28 november 2003 @ 15:19:
Om die reden zou ik ook willen pleiten voor een loop-keyword zonder ingebakken conditiecheck, voor in die situaties waarin een check aan het begin of eind van de loop gewoon niet nodig/handig is.

Mjah ik vind while(true) lekker weglezen hoor

[Eelis]

.

[ Voor 99% gewijzigd door Eelis op 19-02-2015 00:00 ]

[Soultaker]

offtopic:
Ik vind zelf for(;;) echt veel lelijker dan while(true), maar blijkbaar is dat dus erg persoonlijk. Van mij mag je trouwens prima een regel #define loop while(true) toevoegen aan je project.

[curry684]

Bliep, je vind while(true) er workaroundachtig uit zien, en for(;;) niet met 3 lege expressies?

Ik vind de while-vorm heel logisch, "doe dit zolang true true is", ergo ad infinitum Waarom nieuwe keywords introduceren zonder nieuwe functionaliteit?

[curry684]

Soultaker schreef op 28 november 2003 @ 15:29:

offtopic:
Ik vind zelf for(;;) echt veel lelijker dan while(true), maar blijkbaar is dat dus erg persoonlijk. Van mij mag je trouwens prima een regel #define loop while(true) toevoegen aan je project.

Waren macro's trouwens niet per definitie evil?

[Eelis]

.

[ Voor 113% gewijzigd door Eelis op 19-02-2015 00:00 ]

[drm]

[flauw]
Er is ook wel wat te zeggen voor do { ... } while (true);
Aangezien de conditie in een while (true) { ... } altijd waar is, is een eerste iteratie onvermijdelijk. Aangezien dat ook de bedoeling is van een do {..} while zou die eigenlijk netter zijn dan een while{...}
[/flauw]

edit:
en nou in 't nederlands

[ Voor 16% gewijzigd door drm op 28-11-2003 15:53 ]

[Tomatoman]

Laten we vooral

Delphi:

repeat
  // bladibla
until False;

niet vergeten

[ Voor 4% gewijzigd door Tomatoman op 28-11-2003 15:58 ]

[drm]

ok, ik zal het niet vergeten

[Alarmnummer]

*vind het gesprek behoorlijk richting miereneukerij gaan

[Verwijderd]

om dan maar Offspring_nl een beetje op weg te helpen;

download gratis;

Dev-C++ - een c/c++ compiler
(tevens is hier te vinden een gratis delphi compiler)
http://www.bloodshed.net/

python;
http://www.python.org/


processing;
(per e-mail aan te vragen)
http://proce55ing.net/download/index.html

java;
(tja welke sdk je het beste kan downloaden,
daar durf ik even geen antwoord op te geven.)
http://java.sun.com/

edit:

laat ons weten waneer je, je eerste 'hello world' programma aan de praat heb gekregen.. puur uit nostalgie........

[ Voor 14% gewijzigd door Verwijderd op 28-11-2003 21:49 ]

[.oisyn]

Alarmnummer schreef op 28 november 2003 @ 16:11:
*vind het gesprek behoorlijk richting miereneukerij gaan

met de summiere topicstart van de topicstarter kun je alle kanten op

[Verwijderd]

ach ja..

wist ik veel

[Grijze Vos]

drm schreef op 28 november 2003 @ 11:30:
[...]

Ik begrijp hieruit dat een goto eigenlijk alleen (goed) gebruikt wordt om uit meerdere levels te "breaken".

Waarom heeft ons Bjarne dan niet het ingenieuze break [level]; geintroduceerd? Dus dat je regel 14 hier vervangt door

C++:

break 2; // break for-loop

Enig idee

Goto komt uit een tijd dat programmeertalen net iets geavanceerder werden dan Assembly. Aangezien assembly niet kan loopen en die gein, om te branchen kan assembly alleen maar jumpen cq goto-en (effectief gezien). Goto is gewoon een higher-level language afkijksel van assembly talen.

Dijkstra is een van de eerste mensen die dat compleet heeft afgezeken, omdat het uiteraard de simpliciteit van je code, en met name de leesbaarheid, negatief beinvloed..

goto's cq jumps zijn nog steeds uitermate nuttig hoor, net als self-modifying code, als je het maar op assembly niveau houdt

[curry684]

Grijze Vos schreef op 30 november 2003 @ 03:31:
[...]
Aangezien assembly niet kan loopen en die gein, om te branchen kan assembly alleen maar jumpen cq goto-en (effectief gezien).

Intel assembly is niet m'n sterkste kant, dus misschien dat je wat dat betreft gelijk hebt, maar op bijv. de Motorola 680x0 series kon je wel asm-style loopen met de Dxx serie van instructies: Decrement Register and Branch Conditionally.

Even roestige 8 jaar oude kennis uitproberen:

code:

  // 10 iteraties
  moveq #10, d0
  lea Source, a0
  lea Target, a1

myloop:
  move.l (a0)+, (a1)+
  dne d0, myloop

Hierbij wordt dus het D0-register gedecrement, getest en vervolgens als de Z-bit (zero) niet gezet is gebranched naar myloop

* curry684 hoopt dat dit syntactisch klopte

[Macros]

Ik heb nog Motorola 680x0 assembly gehad in mijn eerste jaar, was wel erg cool. Ook al is het RISC, sommige instructies konden de hond uitlaten, je peuter van de creche halen en tegelijk je afwasmachine uitruimen

[PommeFritz]

offtopic:
680x0 is geen RISC. Ben je in de war met de 88000 serie?

[_the_crow_]

Grijze Vos schreef op 30 november 2003 @ 03:31:
Goto komt uit een tijd dat programmeertalen net iets geavanceerder werden dan Assembly. Aangezien assembly niet kan loopen en die gein, om te branchen kan assembly alleen maar jumpen cq goto-en (effectief gezien). Goto is gewoon een higher-level language afkijksel van assembly talen.

Dijkstra is een van de eerste mensen die dat compleet heeft afgezeken, omdat het uiteraard de simpliciteit van je code, en met name de leesbaarheid, negatief beinvloed..

goto's cq jumps zijn nog steeds uitermate nuttig hoor, net als self-modifying code, als je het maar op assembly niveau houdt

GAS:

MOV  ECX,200h
blaatlabel:
TEST EAX,80h      ; nutteloos iets :+
JZ   blaatlabel2
LOOP blaatlabel
blaatlabel2:

Dat is gewoon een loop in ASM hoor (met ECX 'rondes').
Of begrijp ik je verkeerd?

[ Voor 10% gewijzigd door _the_crow_ op 30-11-2003 18:03 ]

[Macros]

PommeFritz schreef op 30 november 2003 @ 17:39:

offtopic:
680x0 is geen RISC. Ben je in de war met de 88000 serie?

offtopic:
Je hebt gelijk

[GrimaceODespair]

curry684 schreef op 28 november 2003 @ 00:05:
oisyn weet in dat verband nog wel hoe ik bijv. code schrijf die in releasebuilds callstacks en profiling optioneel produceert

Beetje late reactie misschien, maar:

C++:

while (true) // for (;;)
{
    Grimace.listen("veryCarefully");
}

[Grijze Vos]

In opcodes gesproken zijn je 'loopjes' nog altijd jumps. Dat bedoelde ik eigenlijk te zeggen. Hij kan hooguit een register ergens mee comparen en aan de hand daarvan een paar keer ergens naar terugjumpen, dan heb je het wel gehad.

Ik sprak btw niet over Intel assembly, maar over Z80, waar ik nu mee bezig ben..

[alienfruit]

with-commando is pas vervelend in Delphi
Kan van die verschrikkelijk leuke bugs veroorzaken

[.oisyn]

Grijze Vos schreef op 01 december 2003 @ 02:28:
In opcodes gesproken zijn je 'loopjes' nog altijd jumps. Dat bedoelde ik eigenlijk te zeggen. Hij kan hooguit een register ergens mee comparen en aan de hand daarvan een paar keer ergens naar terugjumpen, dan heb je het wel gehad.

en wat is dan het verschil tussen een asm loop en een c++ for-lus

Goto is gewoon een higher-level language afkijksel van assembly talen.

daar ben ik het niet mee eens. Je wilt gewoon kunnen springen naar een bepaald stuk. Dat geldt voor zowel assembly als gewone code. Om dan te zeggen dat het een "aftreksel" is lijkt me een beetje onzin. Het heeft bestaansrecht, en daarom zit het erin. (goto is nog altijd heel erg nuttig bij generated code, zoals bijvoorbeeld voor gegenereerde parsers e.d.)

[whoami]

alienfruit schreef op 01 december 2003 @ 02:37:
with-commando is pas vervelend in Delphi
Kan van die verschrikkelijk leuke bugs veroorzaken

Tja, dat ligt niet aan dat statement, maar eerder aan de programmeur.

[Verwijderd]

Je kan C# en Java ook gebruiken om console apps te schrijven. Deze zullen allen maar gaan draaien op de PC's met de Virtual Machines...

Om ff terug te komen op Delphi platform onafhankelijkheid: Delphi6 en Delphi 7 (van borland) hadden de mogelijk heid om in een windows project ook gebruik te maken van de kylix compiler om zo een linux versie uit te poepen naast je windows versie.

C is idd goed over te brengen naar een linux bak, maar zal daar opnieuw gecompiled moeten worden. Dat is ook niet ALTIJD wenselijk. Het implementeren van de juiste libraries werkt idd, maar veel uitleg wordt gedaan met de geweldige windows libraries.

Op school hebben we C++ colleges gehad waar bijna alleen amar met de windows specifick libraries werd gewerkt....


En als je C++ gaat doen kijk eens naar DEV C++... Die is heeel licht, heeft ook GUI ontwikkelinge geloof ik.... en heeft snelle compiler (draaide op P2 366 veel beter dan die borland producten)