Program for å gjøre om fra tommer til cm?

[kjetil7]

Jeg vil ikke anbefale Managed C++ for å lære kode GUI i det hele tatt. I sin nåværende stand er Managed C++ bra til å bygge broer mellom native og managed kode. Men skal du lære å bruke .NET framework bruker du ganske enkelt C#.

 

Situasjonen blir kanskje annerledes til neste år når Whidbey kommer (Visual Studio .NET 2005). Den har nye managed C++ extensions som binder sammen C++ og CLI på en mye bedre måte. Det blir f.eks. et tydeligere skille mellom managed referansepekere og tradisjonelle C++ pekere (bruker ^ for managed referanser). Dessuten blir alle keywordene med to underscores først i navnet borte. De blir erstattet med enklere og mer iøyefallende varianter. Og kanskje det beste: "boxing/unboxing" er mye enklere:

int i = 13;
Object^ o = i; // boxing ("implicit" og typesikkert)
int y = *reinterpret_cast<int^>(o); // unboxing

 

Det er mye annet som også blir forbedret. Men kort sagt kommer det helt nye managed C++ extensions i neste Visual Studio, så jeg hadde ikke brukt tid på å lære managed C++ hvis du strengt tatt ikke trenger det.

[Manfred]

Bare et forslag fra min side, egentlig. Jeg har egentlig kun vært borti C# i .net rammeverket, så jeg har ikke sett på managed C++ i det hele tatt.

[pcfreak]

sorry, et innlegg for mye, tabbe.

Endret 12. mai 2004 av pcfreak

[pcfreak]

Jeg ser atd du bruker std::cin og std::cout, du kan, i tilleg til det de andre sa kan du bruke denne metoden for bare å slippe å skrive std:: forran cout, cin, endl.

bruk

 

using std::cout;

using std::cin;

 

eksempel:

 

#include <iostream>

using std::cout;
using std::cin;

int main()
{
   int integer1;
   int integer2;
   int sum;
   
   cout << "Please enter two integers you want to substract: ";
   cin >> integer1 >> integer2;

   sum = integer1 + integer2;

   cout << "\nSum is " << sum;

   return 0;
}

Endret 12. mai 2004 av pcfreak

[Manfred]

legg inn

using namespace std;

i stedet for

using std::cin;
using std::cout;

[☀ ❄]

pcfreak, hvem er det du skriver til?

 

 

Jeg mener at det er bedre å bruke tolower() (den gjør om til små bokstaver, zirener), fordi den gjør at man ser at det er "case insensitive" bare ett sted. tolower() gjør koden tydeligere, og gjør at det blir mindre å skrive. Mindre å skrive betyr at det er færre steder det kan bli feil.

 

Er du ikke enig i at dette:

 

switch(tolower(my_char)) {
case 'a':
    // ...
    break;
case 'b':
    // ...
    break;
case 'c':
    // ...
    break;
case 'd':
    // ...
    break;
case 'e':
    // ...
    break;
case 'f':
    // ...
    break;
}

 

er tydeligere, enklere og bedre enn:

 

switch(my_char) {
case 'a': case 'A':
    // ...
    break;
case 'b': case 'B':
    // ...
    break;
case 'c': case 'C':
    // ...
    break;
case 'd': case 'D':
    // ...
    break;
case 'e': case 'E':
    // ...
    break;
case 'f': case 'F':
    // ...
    break;
}

 

..?

 

 

 

(Jo, vi er nok delvis off-topic, men det er vi vel strengt tatt ikke alene om.)

 

 

(Diskusjonen om using namespace ...; using ...; og ...::...; er alt tatt av meg og søppel i en annen tråd. Lag en ny tråd hvis dere vil diskutere det mer...)

[Fredrik90]

(Jo, vi er nok delvis off-topic, men det er vi vel strengt tatt ikke alene om.)

ja, selv om mange gjør bør ikke alle gjøre det.

 

for å gi et litt bedre bilde så kan jeg si WIN32 API. men dere trenger ikke å svare mer for jeg har funnnet delvis greie tutorials på http://www.gametutorials.com/

 

edit: en tabbe på linken ok nå.

Endret 12. mai 2004 av Fredrik90

[Dead_Rabbit]

Hehe, enten er det jeg som missforstår eller så er det du Myubi .

Jeg mente at det er bedre å bruke toupper() enn

case 'a' case: 'A': //Noe

men det var fordi jeg ikke viste om noe annet som tolower(). Det var derfor jeg nevnte den. Så om det er:

switch(variabel)
{
case 'a': //blabla
            break;
case 'b': //blabla
}

eller:

switch(variabel)
{
case 'A': //blabla
            break;
case 'B': //blabla

 

Så syns jeg ikke dette har stor betydning for lesbarheten.

Jeg får en liten følse av en missforståerlse...

[søppel]

Ikke for å være pirkete ..(ok, litt kanskje).. men et funksjonskall tar mer tid enn en sammenligning (ekstra), tror jeg.

[GNUfan]

Ikke for å være pirkete ..(ok, litt kanskje).. men et funksjonskall tar mer tid enn en sammenligning (ekstra), tror jeg.

Hehe... 10-20 klokkesykluser ekstra? På 1 ghz kan man jo regne ut hvor fort det vil gå...

[søppel]

Når jeg tenker meg om en gang til, så kan det jo faktisk ta lengre tid å sammenligne hvis det er veldig mange -- da vil man kanskje spare 50% (sammenligning i verstefall) ved å gjøre étt funksjonskall først.

 

Tegner man triangler ellernoesånnt i en tight loop har jo slikt mye å si.

 

Mulig jeg suser mer enn vanlig.

 

hehe

Endret 13. mai 2004 av søppel

[☀ ❄]

Ja, zirener, om man skal bruke toupper() eller tolower() er helt irrelevant Så om du trodde jeg mente at det var noen forskjell var det nok en misforståelse ute og gikk..

 

Jeg er litt usikker selv, søppel. Jeg vet at et funksjonskall er relativt dyrt, men jeg er litt usikker på om en kompilator effektivt kan optimalisere bort den ekstra case'en for hver bokstav. Uansett er nok kanskje dette en "80-del" med tanke på 80/20-regelen.

[Fredrik90]

nå bare lurer jeg på om jeg har forstått det riktig. når du har en dll fil så trenger du ikke å lage exe filen så diger. du har bare alt av info i dll filen og bare programet i exe filen.(mener at du har det viktigste i exe filen.)

 

vet at det er dårlig skrevet. men jeg har litt dårlig tid så det for ikke hjelpe.

[søppel]

Man plasserer ofte-brukte funksjoner og ting-og-tang i biblioteker ja.

 

Det finnes to måter å linke seg til biblioteker; dynamisk og statisk.

 

Når man linker dynamisk sparer man plass .. men man må legge ved biblioteker når man skal gi programmet til andre.

 

Når man linker statisk legges de deler som trengs fra biblioteket "inne i" .exe-fila.

 

..gikk rimelig fort det her også..

 

*ut å grille* :]

Endret 14. mai 2004 av søppel

[Fredrik90]

takk for det svaret. det ga et rimmelig greit svar.(forklarte det jeg trengte å vite.)

[pcfreak]

pcfreak, hvem er det du skriver til?

 

 

Jeg mener at det er bedre å bruke tolower() (den gjør om til små bokstaver, zirener), fordi den gjør at man ser at det er "case insensitive" bare ett sted. tolower() gjør koden tydeligere, og gjør at det blir mindre å skrive. Mindre å skrive betyr at det er færre steder det kan bli feil.

 

Er du ikke enig i at dette:

 

switch(tolower(my_char)) {
case 'a':
    // ...
    break;
case 'b':
    // ...
    break;
case 'c':
    // ...
    break;
case 'd':
    // ...
    break;
case 'e':
    // ...
    break;
case 'f':
    // ...
    break;
}

 

er tydeligere, enklere og bedre enn:

 

switch(my_char) {
case 'a': case 'A':
    // ...
    break;
case 'b': case 'B':
    // ...
    break;
case 'c': case 'C':
    // ...
    break;
case 'd': case 'D':
    // ...
    break;
case 'e': case 'E':
    // ...
    break;
case 'f': case 'F':
    // ...
    break;
}

 

..?

 

 

 

(Jo, vi er nok delvis off-topic, men det er vi vel strengt tatt ikke alene om.)

 

 

(Diskusjonen om using namespace ...; using ...; og ...::...; er alt tatt av meg og søppel i en annen tråd. Lag en ny tråd hvis dere vil diskutere det mer...)

Jeg kommenterer med det jeg sier noe som står langt tilbake i begynnelsen i artikkelen, kansje litt sent, men, er det andre å bedre måter å gjøre dette på så legger jeg meg flat for det, jeg er selv nybegynner, er ikke ferdig å lære om C++. Men slik lærer C++ How to program det bort, men jeg har ikke lest hele da, så, dere som er mere erfarene har sikkert rett, ja, det finnes sikkert flere måter å gjøre det på, er vel opp til en hver hva han/hun liker best etc. Kansje dumt av meg å kommentere nå mens jeg er selv i en læringsprosess, men men...

[☀ ❄]

(Prøv å korte ned på quotes, hvis du finner ut at de er absolutt nødvendige å ha med i det hele tatt...)

 

Det er aldri dumt å kommentere: om ikke annet får man rettet opp i feil. Hva man skal bruke her er, som du sier, smak og behag. Poenget med namespaces er å hindre at identifikatorer blir "opptatt", og da er det dumt å ødelegge for det ved uhensiktsmessig bruk av namespace-importering. Cluet er altså å importere det du trenger til en funksjon -- men ikke stort mer.

[Feynman]

Når man linker statisk legges dll-fila "inne i" .exe-fila.

 

..gikk rimelig fort det her også..

D-en i DLL står for dynamic. Statisk DLL?? Skurrer litt. Ser det gikk litt fort, men siden det er mange andre som blander begreper syns jeg det var viktig å nevne det.

 

Når det gjelder hvordan en programmerer "best" må en tenke på programmets behov. Hvis det er sanntidsprogram eller et program som skal gjøre kompliserte regneoperasjoner er det viktig å tenke gjennom hvor mye de forskjellige funksjonskallene koster. Hvis det er et stort prosjekt der man må samarbeide med andre er det viktig at koden er lett forståelig.

[☀ ❄]

søppel sa det på den måten for å illustrere at man kan linke den inn når man kompilerer. Det er selvfølgelig ikke en DLL-fil (Dynamic Link Library) man linker inn, men en .lib / .a-fil. (Dette har søppel forklart i en tidligere tråd, så det er ingen som helst tvil om at søppel blander dynamisk og statisk linking.)

 

Og om det er en .dll/.a-fil eller en .lib/.so som linkes inn er ganske så irrelevant. Selv om det (så vidt jeg vet) er noen forskjeller i kallprosedyrene o.l. er formålet det samme: Å samle mye brukt kode i en modul.

 

 

Med mindre det er spesielt nødvendig med hurtighet bør nok lesbarhet prioriteres i kode. Uansett om man programmerer sammen med andre eller ikke; det er viktig at man forstår sin egen kode også. C++ er tross alt et temmelig raskt språk, og det er ikke så ofte man trenger all den hastigheten. Som tidligere nevnt har vi 80-20-regelen, som bl.a. sier at tjue prosent av programmer bruker åtti prosent av tiden. Det er de tjue prosentene man må optimalisere. Kode som den diskutert ovenfor kjøres som regel så sjeldent at det ikke spiller noen stor rolle fra eller til.

 

Det er sant at enkelte ting koster. Funksjonskall koster. Virtuelle funksjonskall koster enda mer. Betyr det at vi skal la være å bruke abstraksjoner som klasser, siden de som oftest fører til mer utstrakt bruk av funksjoner? Nei, selvfølgelig ikke. Hvis man har det så travelt når man skal kjøre programmer får man heller kode i asm (selv om det sies at kompilatorer er bedre til å optimalisere enn håndskreven asm).

 

Som nevt er det dessuten sannsynlig at det økte antallet case-statements koster mer enn et funksjonskall...

[søppel]

Jeg skrev ".dll-fil" med "bibliotek" i parantes bak (øverst) for å ikke forvirre (når jeg startet å skrive hadde jeg egentlig bare tenkt å skrive om .dll-filer, men så ble det mer, og mer generellt), men det var kanskje akkurat det jeg gjorde - så jeg har byttet alle forekomster av ".dll-fil" med "bibliotek" nå.

 

Dynamiske (shared) biblioteker kalles ofte *.dll under Win32 og *.so under *nix.

Statiske kalles ofte *.lib eller *.a, både under Win32 og *nix.

Endret 14. mai 2004 av søppel