Random

[☀ ❄]

Med all respekt, søppel:

 

1) Hvordan mener du at det der skal besvare et allerede besvart spørsmål om hvordan srand(time(0)); rand() % x; virker? Spesielt med tanke på at du trekker inn templates, operator overloading og flere andre irrelevante trekk som sannsynligvis bare forvirrer zirener.

 

2) Hvis han hadde stilt et spørsmål som svaret ditt faktisk hadde relevanse til, tror du ikke han ville lært adskillig mer hvis han hadde skrevet koden? (Retorisk spørsmål).

 

3) Som svar til en mindre erfaren programmer burde du i det minste ta deg bryet med å skrive ordentlig kode. Altså, unngå dårlige praktiseringer som:

- bruker std::cerr til vanlig output

- bruke underscore foran identifikatorer (forbeholdt kompilatoren)

- hente inn hele namespace std; i global namespace (når det er sagt: Det er dessverre mange tekstbøker som gjør det samme)

[søppel]

Eksemplene til nå manglet mulighet til å generere flytetall og negative tall; så kan like greit ta alt i en smell - og regne med at det varer en stund.

 

Jeg anser ikke bruk av cerr som dårlig praksis i slike ex. Jeg gidder ikke begrunne hvis du ikke i det minste kan tenke deg hvorfor. (Slå det opp, eller lag en ny tråd.)

 

Anser heller ikke bruk av underscore som dårlig praksis inne i egne klasser, og jeg har et par veldig gode grunner til at jeg gjør det. Jeg gidder ikke nevne disse.

 

Anser heller ikke det å hente inn hele std i det globale namespace som dårlig praksis når det globale namespacet er alt som eksisterer i den (lille) sammenhengen her, og jeg på forhånd vet at dette er en programsnutt som ikke er ment å bygges videre på, men bare ment å vise et eksempel. Jeg synes ikke det er så fryktelig spennende å forklare hvorfor eller mer rundt dette heller.

 

Bruken av funksjonene jeg refererer til v.h.a. linker kommer klart frem hvis man ser bort i fra bruken av templates og alt annet man eventuellt ikke måtte forstå eller ikke gidder å slå opp for å se hvordan fungerer .. o.s.v. (Er ikke bare jeg som ikke gidder.)

 

Hele poenget med klasser er forresten også at man skal kunne bruke dem uten å måtte vite hvordan de fungerer på "innsiden". Så de som vil står fritt til å bruke den, eller la være, og eventuellt siden finne ut hvordan den fungerer.

 

..og i bunn å grunn har jeg selvstendige meninger, og har altid rett. :}

Endret 7. april 2004 av søppel

[☀ ❄]

Hva du gjør, synes og mener (for deg selv) er selvfølgelig din sak, og jeg skal ikke legge meg borti det.

 

 

 

...men, jeg syns det er interessant å høre argumentene dine. Det er, så vidt jeg vet, to forskjeller på std::cout og std::cerr:

1) std::cout brukes til output, std::cerr til error output -- Dette gir programmerere assosiasjoner, og gjør at han/hun tenker "hva er feil med dette?" når std::cerr brukes til vanlig output.

2) std::cout er bufret.

 

Punkt 1 gjør bruk av std::cerr til vanlig output mindre leselig. Punkt 2 gjør bruk av std::cerr til vanlig output mindre effektivt. Skulle det, mot formodning, være hensiktsmessig eller ønskelig å tømme bufferen til std::cout kan dette gjøres ved std::cout::flush(), eller ved std::cout::operator<<(std::endl).

 

 

 

"Et par veldig gode grunner" til å bruke underscore i identifikatornavn. En opplagt grunn er å holde medlemsnavn adskilt fra andre navn, som for eksempel navn på funksjoner eller argumenter. Den eneste andre grunnen jeg kan se er å gjøre programmene potensielt ukompilerbare på andre kompilatorer, evt. en nyere versjon av samme kompilator -- Dette er noe de fleste jeg kjenner ville prøvd å unngå.

 

 

 

Hva importering av namespace std angår er dette selvfølgelig, som jeg nevnte i forrige post, en bagatell.

 

 

 

Siden du nevner å alltid ha rett; alltid skrives med to L'er, å er infinitivsmerke (og er konjunksjonen du er ute etter), og akronymer skrives ikke med punktum etter hver bokstav på norsk.

[søppel]

:} Jeg vet alt det der om buffere, tømming, effektivitet .. etc. -- jeg bare gidder ikke i slike eksempler og sammenhenger. cerr funker 101% av tiden uten at jeg behøver å tenke på det. "Jeg vil bare ha noe tekst på skjermen -- samme hva .. målet er ikke konsoll-programmet/er i seg selv, men forståelsen av koden rundt det som får tekst til å havne i konsollet eller på skjermen."

 

_ er regnet som en bokstav i C++. (Finn frem side 81 (§4.9.3) i den nye TCPL-boken din. Jeg er ikke så fryktelig urolig for det Bjarne navner litt under; "..reserved for special facilities..", (bruk ::_system_thingy hvis du også har en system_thingy i din egen klasse/namespace) og en random-klasse bør jo i grunn regnes som en del av et bibliotek, ikke en "application".) Så den gangen kompileren min velger å gjøre slike navn ukompilerbare er da jeg bytter kompiler, eller sender inn en patch med henvisning til standaren. (I.e. det skjer "aldrig".)

 

Hakke tid til å skrive rektig. Bryr meg ikke i sammenhenger som f.eks. et forum. Jeg snakker fort -- hopper over bokstaver .. glemmer 'r'; sier 'ejj' i stedet. Det blir ofte det samme med skrivingen. Folk som ikke skjønner hva jeg mener får spørre igjen.

 

Det at jeg altid har rett er seff. tull, i hvertfall når jeg tar feil. Er dette riktig? ..hehe..

Endret 7. april 2004 av søppel

[☀ ❄]

Interessant at du skulle nevne det. Se litt lenger ned på siden, litt over midten. Jeg siterer: "Names starting with an underscore are reserved for special facilities in the implementation and the run-time environment, so such names should not be used in application programs."

 

Det var det jeg mente, at programmet ikke ville kompilere fordi navnet allerede var i bruk.

 

 

Uansett, jeg skjønte at du ikke mente "jeg har alltid rett" så seriøst Begrenset hvor seriøst mitt svar på det var også, noe jeg regner med at du skjønte..

[Peter]

Interessant å se hvor bra dere klarer å holde dere til temaet.

Like morsomt å se hva dere diskuterer foran oss nye karer, som omtrent ikke bryr eller skjønner bæret av hele siste side.

[☀ ❄]

Du kommer nok sikkert til å forstå det -- og bry deg -- en gang Hva den lille off-topic diskusjonen angår, følte jeg at tråden i seg selv hadde utspilt sin rolle, og at en liten avsporing på slutten derfor ikke var kritisk.