---

Er der en eller anden med C++ erfaring der kan fortælle mig, hvordan jeg
laver et variablet array i C++. Problemet er at jeg skal indlæse et ukendt
antal linier i et array, lave nogle beregninger der er afhængig af dato og
tidspunkt, og skrive resultatet i en ny fil. I PHP kan man noget i stil med

$i=0
while (! feof(FileInput))
{
linie=fgets(FileInput, 100);
LinieArray[$i] = linie;
$i++;
}
og så kan PHP selv finde ud af resten
Men i C++ skal man vel definere størrelsen af array (ex: char
LinieArray[<størrelse af arrayet>], når det bliver definieret i main-delen
af programmet og så er den ligesom ikke så variabel, som jeg godt kunne
tænke mig.

Forslag???

Mvh.
Kåre

---

Prøv: LinieArray = new type[størrelse];

"Kåre Mølgård Rasmussen" <kaare@obel.auc.dk> skrev i en meddelelse
news:9b0qai$9gu$1@sunsite.dk...
> Er der en eller anden med C++ erfaring der kan fortælle mig, hvordan jeg
> laver et variablet array i C++. Problemet er at jeg skal indlæse et ukendt
> antal linier i et array, lave nogle beregninger der er afhængig af dato og
> tidspunkt, og skrive resultatet i en ny fil. I PHP kan man noget i stil
med
>
> $i=0
> while (! feof(FileInput))
> {
> linie=fgets(FileInput, 100);
> LinieArray[$i] = linie;
> $i++;
> }
> og så kan PHP selv finde ud af resten
> Men i C++ skal man vel definere størrelsen af array (ex: char
> LinieArray[<størrelse af arrayet>], når det bliver definieret i main-delen
> af programmet og så er den ligesom ikke så variabel, som jeg godt kunne
> tænke mig.
>
> Forslag???
>
> Mvh.
> Kåre
>
>
>

---

Hej Kåre,
"Kåre Mølgård Rasmussen" <kaare@obel.auc.dk> wrote in message
news:9b0qai$9gu$1@sunsite.dk...

Du kan bruge klassen std::vector<T>


Venlig hilsen

Mogens Hansen

---

On Wed, 11 Apr 2001 12:10:27 +0200, Mogens Hansen wrote:
>Hej Kåre,
>"Kåre Mølgård Rasmussen" <kaare@obel.auc.dk> wrote in message
>news:9b0qai$9gu$1@sunsite.dk...
>
>Du kan bruge klassen std::vector<T>

Jeps. Brug vector-containeren fra STL (Standard Template
Library). Jeg mener du lige skal #include <vector.h> og så
eller bare:


#include <iostream.h>
#include <fstream.h>
#include <vector.h>

int
main( int argc, char** argv )
{
   ifstream   f(argv[1]);
   int      i;
   vector<int>   v;


   if ( argc != 2 ) {
      cerr << "syntax: " << argv[0] << " <filename>" << endl;
      return -1;
   }

   if ( !f.is_open() ) {
      cerr << "crap!" << endl;
      return -1;
   }


   while ( !f.eof() ) {
      f >> i;         // Indlæs tal fra ASCII-fil.
      v.push_back(i);      // Stop en værdi ind i vektoren.
   }
   f.close();


   for ( i = 0 ; i < v.size() ; i++ ) {
      cout << "v[" << i << "] = " << i << endl;
   }

   return 0;
}



Eller noget..


--
Stephan Henningsen /
/ http://tisprut.dk

---

* Stephan Henningsen

[snip]

> Jeg mener du lige skal #include <vector.h> og så eller bare:


Det er synd at du mener det, fordi det er feil.


> #include <iostream.h>
> #include <fstream.h>
> #include <vector.h>


#include <iostream>
#include <fstream>
#include <vector>


> int
> main( int argc, char** argv )
> {
>    ifstream   f(argv[1]);
>    int      i;
>    vector<int>   v;
>
>
>    if ( argc != 2 ) {
>       cerr << "syntax: " << argv[0] << " <filename>" << endl;
>       return -1;
>    }


Du ville ha fått en segfault (hint: testen står altforsent):


if ( argc != 2 ) {
// die
return 1;
}

ifstream f( argv[1] );
if ( !f ) {
return 2;
}


>    if ( !f.is_open() ) {
>       cerr << "crap!" << endl;
>       return -1;
>    }
>
>
>    while ( !f.eof() ) {
>       f >> i;         // Indlæs tal fra ASCII-fil.
>       v.push_back(i);      // Stop en værdi ind i vektoren.
>    }


Nei, dette vil gi deg et element for mye, da eof ikke er sann før
_etter_ at man prøver å lese forbi EOF (det er veldig enkelt å tenke
seg inputfiler der koden over ikke vil virke). Den kanoniske måten å
lese sånt på er:

while ( f >> i ) {
v.push_back( i );
}

eller

copy( istream_iterator< int >( f ),
istream_iterator< int >(),
back_inserter( v ) );

[snip]





ivr
--
"making it suck less, one module at a time..."
John Bode on comp.lang.c (comment on program development)

---

On 11 Apr 2001 18:01:24 +0200, Igor V. Rafienko wrote:
>
>Det er synd at du mener det, fordi det er feil.
>
>> #include <iostream.h>
>> #include <fstream.h>
>> #include <vector.h>
>
>#include <iostream>
>#include <fstream>
>#include <vector>

Jeg ved ikke hvad dit eller din compilers problem er, men
det compiler, læser, udskriver og exit'er fint her. Desuden
var det ikke meningen koden skulle vinde noget VM, men blot
fungerer som demonstration på, hvordan STL's vectors kunne
bruges.


--
Stephan Henningsen /
/ http://tisprut.dk

---

[snip om *.h vs. *]

| Jeg ved ikke hvad dit eller din compilers problem er, men det
| compiler, læser, udskriver og exit'er fint her.


Det er _komplett_ irrelevant. Det du skrev var feil. Period. Hvis du
insisterer, kan jeg peke på den relevante paragrafen i
språkdefinisjonen. Hva kompilatoren din/min/hans måtte akseptere er
uinteressant.


| Desuden var det ikke meningen koden skulle vinde noget VM, men blot
| fungerer som demonstration på, hvordan STL's vectors kunne bruges.


Det var en _dårlig_ demonstrasjon, da koden ikke fungerte.





ivr
--

---

On 12 Apr 2001 00:57:30 +0200, Igor V. Rafienko wrote:
>
>| Jeg ved ikke hvad dit eller din compilers problem er, men det
>| compiler, læser, udskriver og exit'er fint her.
>
>Det er _komplett_ irrelevant. Det du skrev var feil. Period. Hvis du
>insisterer, kan jeg peke på den relevante paragrafen i
>språkdefinisjonen. Hva kompilatoren din/min/hans måtte akseptere er
>uinteressant.

Er du altid sådan?


>| Desuden var det ikke meningen koden skulle vinde noget VM, men blot
>| fungerer som demonstration på, hvordan STL's vectors kunne bruges.
>
>Det var en _dårlig_ demonstrasjon, da koden ikke fungerte.

FUT: dk.helbred.misbrug


--
Stephan Henningsen /
/ http://tisprut.dk

---

Stephan Henningsen skrev:

>>Det er _komplett_ irrelevant. Det du skrev var feil. Period.
>Er du altid sådan?

Hvad vil du ellers have folk skal gøre hvis der er fejl i den
kode eller de råd der postes?

>FUT: dk.helbred.misbrug

Et godt råd: Gå lidt stille med dørene.

--
Bertel
http://lundhansen.dk/bertel/   FIDUSO: http://fiduso.dk/

---

On Thu, 12 Apr 2001 07:21:35 +0200, Bertel Lund Hansen wrote:
>Stephan Henningsen skrev:
>
>>>Det er _komplett_ irrelevant. Det du skrev var feil. Period.
>>Er du altid sådan?
>
>Hvad vil du ellers have folk skal gøre hvis der er fejl i den
>kode eller de råd der postes?

Jeg gider ikke gøre noget større nummer ud af det her.
Det korte af det lange er det, at han på en provokerende
måde rettede mig i noget, som mine bøger siger, er korrekt
(Deitel + Schildt).


--
Stephan Henningsen /
/ http://tisprut.dk

---

* Stephan Henningsen

[snip]

> Jeg gider ikke gøre noget større nummer ud af det her.


Ah, men det gjør jeg. Det å gi råd som er _feil_ er en ting. Det å gi
dem til nybegynnere gjør ikke saken bedre, men det er nå så. Det å bli
gretten når man irettesettes er iofs også greit, men man bør da
vitterlig beholde evnen til å innse at man har gjort en feil, hva?


> Det korte af det lange er det, at han på en provokerende måde
> rettede mig i noget, som mine bøger siger, er korrekt (Deitel +
> Schildt).


Schildt-bøkene er gode til en ting -- lage bål (hint:
<URL:http://www.accu.org/>. Eller kan du snakke med Peter Seebach
(<URL:http://www.plethora.net/~seebs)). Det eneste du bekrefter er
hvor dårlige slike bøker virkelig er, noe som synes meg å være enda
bedre reklame enn hva det enn måtte være av korrekte og negative
"reviews" som F. Glassborow har kommet med.

Det finnes en rekke bøker om C++. Noen av dem er bedre enn andre. Noen
av dem bør leses av alle (som fx. "The C++ Programming Language", 3rd
ed av B. Stroustrup, eller "Exceptional C++" av H. Sutter), andre bør
unngås av alle.

Du trenger ikke å ta mine ord for god fisk -- slå opp i standarden og
se for deg selv, at koden som _du_ presenterte var feil. _Det_ kan da
umulig være vanskelig.





ivr
--
"making it suck less, one module at a time..."
John Bode on comp.lang.c (comment on program development)

---

On 12 Apr 2001 15:57:48 +0200, Igor V. Rafienko wrote:
>* Stephan Henningsen
>
>> Jeg gider ikke gøre noget større nummer ud af det her.
>
>Ah, men det gjør jeg. Det å gi råd som er _feil_ er en ting. Det å gi
>dem til nybegynnere gjør ikke saken bedre, men det er nå så.

Og jeg er ekspert? Hvem siger, at jeg ikke selv er nybegynder?


>Det å bli
>gretten når man irettesettes er iofs også greit, men man bør da
>vitterlig beholde evnen til å innse at man har gjort en feil, hva?

Hvad skal jeg sige? Det er dit ord mod min undervisers+mine
bøger+min compiler. Og koden virker fint hos mig.


>Schildt-bøkene er gode til en ting -- lage bål (hint:
><URL:http://www.accu.org/>. Eller kan du snakke med Peter Seebach
>(<URL:http://www.plethora.net/~seebs)). Det eneste du bekrefter er
>hvor dårlige slike bøker virkelig er, noe som synes meg å være enda
>bedre reklame enn hva det enn måtte være av korrekte og negative
>"reviews" som F. Glassborow har kommet med.

Så du _er_ altså udemærket klar over situationen..


>Du trenger ikke å ta mine ord for god fisk -- slå opp i standarden og
>se for deg selv, at koden som _du_ presenterte var feil. _Det_ kan da
>umulig være vanskelig.

Du har lige selv skrevet, hvorfor min kode var forkert. Og
alligevel skal du lige nå at tale ned til mig, inden du
afslutter dit indlæg. Kan du ikke komme med et link til de
standarder du hele tiden fabler om og gøre dig lidt nyttig
i stedet for at opføre dig så smart? Tror du det her giver
mig mere lyst til at komme med nogen form for undskyldning?


--
Stephan Henningsen /
/ http://tisprut.dk

---

Den Thu, 12 Apr 2001 22:59:13 +0000 skrev Stephan Henningsen:
>On 12 Apr 2001 15:57:48 +0200, Igor V. Rafienko wrote:
>>* Stephan Henningsen
>>
>>> Jeg gider ikke gøre noget større nummer ud af det her.
>>
>>Ah, men det gjør jeg. Det å gi råd som er _feil_ er en ting. Det å gi
>>dem til nybegynnere gjør ikke saken bedre, men det er nå så.
>
>Og jeg er ekspert? Hvem siger, at jeg ikke selv er nybegynder?

Så skift din lærer ud, inden det er for sent. Jeg har efterhånden
fundet ud af at Igor er _den_ mest kompetente i denne gruppe hvad
angår C++.

>>Det å bli
>>gretten når man irettesettes er iofs også greit, men man bør da
>>vitterlig beholde evnen til å innse at man har gjort en feil, hva?
>
>Hvad skal jeg sige? Det er dit ord mod min undervisers+mine
-----------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>bøger+min compiler. Og koden virker fint hos mig.


>>Schildt-bøkene er gode til en ting -- lage bål (hint:
>><URL:http://www.accu.org/>. Eller kan du snakke med Peter Seebach
>>(<URL:http://www.plethora.net/~seebs)). Det eneste du bekrefter er
>>hvor dårlige slike bøker virkelig er, noe som synes meg å være enda
>>bedre reklame enn hva det enn måtte være av korrekte og negative
>>"reviews" som F. Glassborow har kommet med.
>
>Så du _er_ altså udemærket klar over situationen..
>
>
>>Du trenger ikke å ta mine ord for god fisk -- slå opp i standarden og
>>se for deg selv, at koden som _du_ presenterte var feil. _Det_ kan da
>>umulig være vanskelig.
>
>Du har lige selv skrevet, hvorfor min kode var forkert. Og
>alligevel skal du lige nå at tale ned til mig, inden du
>afslutter dit indlæg.

Du brokker dig over at han henviser til standarden, og det på trods
af at du lige har påstået at det blot er hans ord mod dit. Tag lige
og bestem dig - vil du have beviser eller ikke?

>Kan du ikke komme med et link til de
>standarder du hele tiden fabler om og gøre dig lidt nyttig
>i stedet for at opføre dig så smart? Tror du det her giver
>mig mere lyst til at komme med nogen form for undskyldning?

Du kunne jo starte med at prøve de links du allerede har fået.

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: planets.png

---

On Thu, 12 Apr 2001 21:57:12 +0000 (UTC), Kent Friis wrote:
>Du brokker dig over at han henviser til standarden, og det på trods
>af at du lige har påstået at det blot er hans ord mod dit. Tag lige
>og bestem dig - vil du have beviser eller ikke?

Den eneste henvisning jeg har fået stod i samme sætning med
noget om at brænde bøger af. Jeg må indrømme, at jeg troede
ikke, at de henviste til noget seriøst.


>>Kan du ikke komme med et link til de
>>standarder du hele tiden fabler om og gøre dig lidt nyttig
>>i stedet for at opføre dig så smart? Tror du det her giver
>>mig mere lyst til at komme med nogen form for undskyldning?
>
>Du kunne jo starte med at prøve de links du allerede har fået.

Jeg kigger..


--
Stephan Henningsen /
/ http://tisprut.dk

---

* Stephan Henningsen

[snip]

> >Ah, men det gjør jeg. Det å gi råd som er _feil_ er en ting. Det å gi
> >dem til nybegynnere gjør ikke saken bedre, men det er nå så.
>
> Og jeg er ekspert? Hvem siger, at jeg ikke selv er nybegynder?


Er ens kompetansenivå relevant for korrektheten av den koden man
poster? Jeg tror ikke det. Kan man det riktige svaret (eller et av de
riktige svarene), poster man det. Kan man ikke det, holder man kjeft.
Tror man at man kan det riktige svaret og poster det og det viser seg
å være feil, takker man for rettelser og unnskylder seg. Nå da, er det
så vanskelig eller urimelig å forvente, selv fra en nybegynner?

[snip]


> Hvad skal jeg sige? Det er dit ord mod min undervisers+mine
> bøger+min compiler. Og koden virker fint hos mig.


Du trenger ikke å _si_ noe som helst, _før_ du har tatt deg tid til å
undersøke _hvilke_ elementer i koden din jeg protesterte på. Det mest
merkelige av alt er at du nekter fremdeles å slå opp i språkets
definisjon, for å finne ut hva som er den _riktige_ måten å gjøre ting
på.

_Etter_ at du har gjort det, kan vi diskutere rettelsene som ble
gjort.

[snip]


> Du har lige selv skrevet, hvorfor min kode var forkert. Og alligevel
> skal du lige nå at tale ned til mig, inden du afslutter dit indlæg.


Hvordan skal man ellers snakke til deg, når du nekter å bruke hodet?


> Kan du ikke komme med et link til de standarder du hele tiden fabler
> om


<URL:http://webstore.ansi.org/> eller <URL:http://www.iso.ch/>. Eller
lese FAQ'en til <news:comp.lang.c++>. Eller ta en titt på Jack Klein's
side, <URL:http://home.att.net/~jackklein/c/c_main.html>. Mulighetene
er mange.


> og gøre dig lidt nyttig i stedet for at opføre dig så smart?


:)


> Tror du det her giver mig mere lyst til at komme med nogen form for
> undskyldning?


Jeg forventer ikke en unnskyldning til meg. Jeg forventer å se en
unnskyldning til Kåre Mølgård Rasmussen som kunne ha blitt villedet av
postingen din.





ivr
--
"making it suck less, one module at a time..."
John Bode on comp.lang.c (comment on program development)

---

On 13 Apr 2001 16:17:45 +0200, Igor V. Rafienko wrote:
>Jeg forventer ikke en unnskyldning til meg. Jeg forventer å se en
>unnskyldning til Kåre Mølgård Rasmussen som kunne ha blitt villedet av
>postingen din.

Undskyld Kåre, hvis min kode har villedt dig. Men jeg
handlede i god tro =).


--
Stephan Henningsen /
/ http://tisprut.dk

---

"Stephan Henningsen" <stephan@sanxion.tisprut.dk> wrote in message
news:slrn9db87m.hk.stephan@sanxion.tisprut.dk...
> On Thu, 12 Apr 2001 07:21:35 +0200, Bertel Lund Hansen wrote:
> >Stephan Henningsen skrev:
>
> Jeg gider ikke gøre noget større nummer ud af det her.
> Det korte af det lange er det, at han på en provokerende

"Don't flip the bozo bit" (fra den glimrende bog "Dynamics of Software
Development", Jim McCarthy, Microsoft Press, ISBN 1-55615-823-8)
Prøv at se bort fra formen, hvis du føler dig provokeret. Se budskabet. Som
det ofte er tilfældet når Igor V. Rafienko skriver et indlæg, er der faktisk
noget viden at hente.

> måde rettede mig i noget, som mine bøger siger, er korrekt
> (Deitel + Schildt).
>

Med hensyn til om det er rigtigt skrive

#include <vector.h>

eller

#include <vector>
using std::vector;

kommer det an på hvad man bruger som reference.

Hvis man går tilbage til pre-standard C++, omkring 1994 hvor Alexander
Stephanov og Meng Lee skrev STL hos HP, skulle man skrive

#include <vector.h>

for at få adgang til vector klassen (som ikke er det samme som std::vector)
i deres bibliotek.

Hvis man tager ISO C++ Standarden (ISO/IEC 14882:1998) som reference, så er
det rigtigt at skrive
#include <vector>

I mit indlæg tidligere i denne tråd skrev jeg bevidst "std::vector<T>" i
stedet for "vector<T>" for at indikere at jeg mente klassen fra C++
Standarden.

Det er væsentligt at bemærke at STL _ikke_ er en del af C++ Standard
Library. STL, som det blev beskrevet i "The Standard Template Library"
Technical Report HPL-94-34 af Alexander Stephanov og Meng Lee, udgjorde
grundlaget for de container, iterator og algoritme-klasser der blev medtaget
i C++ Standarden. De gjorde et arbejde der flyttede bevidstheden i C++
kredse.

Hvis dine bøger siger at man skal skrive
#include <vector.h>
så er beskriver de pre-standard C++.
Personligt syntes jeg der er gode grunde til at foretrække Standard C++ -
bl.a. fordi det er en reference.
Jeg er af den opfattelse at man bør foretrække bøger der beskriver Standard
C++ frem for bøger der beskriver pre-standard C++ (f.eks. vil jeg anbefale
Bjarne Stroustrup's "The C++ Programming Language, Special Edition" (eller
third edition) ISBN 0-201-70073-5, frem for Bjarne Stroustrup's "The C++
Programming Language, Second Edtion" ISBN 0-201-53992-6). Specielt vil jeg
(igen-igen) anbefale "Accelerated C++, Practical Programming by Example" af
Andrew Koenig og Barbara E. Moo ISBN 0-201-70353-X som en enestående
introduktion til moderne C++.
Min holdning er også, at når man bruger tid og mental kapacitet (to
begrænsede resourcer) på at læse en bog, kan man lige så godt gå efter de
absolut bedste bøger og forfattere.
Når nu inderkredsen i C++ (Bjarne Stroustrup, Andrew Koening og Barbara E.
Moo om C++ og Matt Austern, David Musser og Atul Saini om STL og Standard
Library) har skrevet velansete bøger, så kan man lige så gå efter dem.
Se endvidere Bjarne Stroustrup's papir "Learning Standard C++ as a New
Language" (http://www.research.att.com/~bs/papers.html".

Venlig hilsen

Mogens Hansen

---

"Stephan" == Stephan Henningsen <stephan@sanxion.tisprut.dk> writes:

> On Thu, 12 Apr 2001 07:21:35 +0200, Bertel Lund Hansen wrote:
>> Stephan Henningsen skrev:
>>
>>>> Det er _komplett_ irrelevant. Det du skrev var feil. Period.
>>> Er du altid sådan?
>>
>> Hvad vil du ellers have folk skal gøre hvis der er fejl i den
>> kode eller de råd der postes?

> Jeg gider ikke gøre noget større nummer ud af det her.
> Det korte af det lange er det, at han på en provokerende
> måde rettede mig i noget, som mine bøger siger, er korrekt
> (Deitel + Schildt).

Hvis det er Herbert Schildt, så er du på vej ud i noget der kan komme
til at koste dig liv og førlighed, eller i hvert fald din mentale
sundhed. Jeg blev en gang udsat for et kursus i C++, hvor
undervisningsmaterialet var "C++ from the ground up". Og det var en
meget interessant oplevelse, idet stort set alle eksempler var
fejlbehæftede i et ikke-trivielt omfang. Klassikerne indbefatter
sammenblanding mellem "\0" og NULL i strenge, tilgang af element 1 til
11(sic!) i et array med 10 elementer, og en generel modvilje mod at
checke om filoperationer gik godt. Alt i alt et noget sjusket skrift.

Det fleste af eksemplerne kunne dog compiles, nogen endda uden
warnings, men folk der skriver C på den måde får *IKKE* lov til at
styre mine vindmøller.

Mit råd til dig er at du lægger Schildt på hylden, og studerer FAQ'en
fra comp.lang.c++ for at finde en liste over bøger der ikke er
skadelige.

--
/Wegge

---

Anders Wegge Jakobsen <wegge@wegge.dk> skrev i en
news:m2hezudpks.fsf@obelix.wegge.dk...
> Mit råd til dig er at du lægger Schildt på hylden, og studerer FAQ'en
> fra comp.lang.c++ for at finde en liste over bøger der ikke er
> skadelige.

comp.lang.c++ ??

Er det en URL eller dele heraf eller hvad?

--
Mvh. PR

---

Den Thu, 12 Apr 2001 22:10:43 +0200 skrev PRime:
>
>Anders Wegge Jakobsen <wegge@wegge.dk> skrev i en
>news:m2hezudpks.fsf@obelix.wegge.dk...
>> Mit råd til dig er at du lægger Schildt på hylden, og studerer FAQ'en
>> fra comp.lang.c++ for at finde en liste over bøger der ikke er
>> skadelige.
>
>comp.lang.c++ ??
>
>Er det en URL eller dele heraf eller hvad?

Nope, det er en newsgroup, ligesom dk.edb.programmering.c

Mvh
Kent
--
http://www.celebrityshine.com/~kfr - sidste billede: easter.png
Fedt - ferie helt til 1/5 :-þ

---

On 12 Apr 2001 18:56:35 +0200, Anders Wegge Jakobsen wrote:
> Hvis det er Herbert Schildt, så er du på vej ud i noget der kan komme
>til at koste dig liv og førlighed, eller i hvert fald din mentale
>sundhed.

>Jeg blev en gang udsat for et kursus i C++, hvor
>undervisningsmaterialet var "C++ from the ground up". Og det var en
>meget interessant oplevelse, idet stort set alle eksempler var
>fejlbehæftede i et ikke-trivielt omfang.

>Klassikerne indbefatter
>sammenblanding mellem "\0" og NULL i strenge,

Hvad er forskellen? Nu er '\0' vel den rigtige
null-terminering til strenge, ikke?


>tilgang af element 1 til
>11(sic!) i et array med 10 elementer,

Usmart.


>og en generel modvilje mod at
>checke om filoperationer gik godt. Alt i alt et noget sjusket skrift.

Jeg vil mene, at det kommer an på, hvad det enkelte
kodeeksempel skal demonsterer. Hvis det er første side i
kapitlet om brugen af filer, så skal der naturligvis testes.
Men er det længere omme i bogen i et afsnit omhandlende
f.eks. .. ja, hvad ved jeg, måske sampler op på en masse
ting, og illusterer dette ved at implementere en ultra
simpel database, så er der forskel.

Men på den anden side, hvis der konsekvent testes hver evig
eneste gang, så bliver læseren nok mere opmærksom på dette,
og er mere tilbøjelig til selv at gøre det.

Jeg synes nu det er en fin opslagsbog, hvis det er meget
længe siden, jeg har programmeret og ikke lige kan huske,
hvordan jeg åbner en fil, laver en case-sætning osv. Men
ret meget mere kan den heller ikke bruges til.


> Mit råd til dig er at du lægger Schildt på hylden, og studerer FAQ'en
>fra comp.lang.c++ for at finde en liste over bøger der ikke er
>skadelige.

Den næste bog jeg har tænkt mig at købe er Linux Programming
Unleashed, tror jeg. Eller Linux Device Drivers. Men måske
skulle jeg i stedet få mig en rigtig, god C++-bog.



--
Stephan Henningsen /
/ http://tisprut.dk

---

"Stephan" == Stephan Henningsen <stephan@sanxion.tisprut.dk> writes:

> On 12 Apr 2001 18:56:35 +0200, Anders Wegge Jakobsen wrote:
>> Hvis det er Herbert Schildt, så er du på vej ud i noget der kan komme
>> til at koste dig liv og førlighed, eller i hvert fald din mentale
>> sundhed.

>> Jeg blev en gang udsat for et kursus i C++, hvor
>> undervisningsmaterialet var "C++ from the ground up". Og det var en
>> meget interessant oplevelse, idet stort set alle eksempler var
>> fejlbehæftede i et ikke-trivielt omfang.

>> Klassikerne indbefatter
>> sammenblanding mellem "\0" og NULL i strenge,

> Hvad er forskellen? Nu er '\0' vel den rigtige
> null-terminering til strenge, ikke?

Det er den ja.

NULL derimod er en pointerværdi, som man for eksempel får tilbage fra
malloc(), hvis det ikke lod sig gøre at opfylde den request man havde.

>> tilgang af element 1 til
>> 11(sic!) i et array med 10 elementer,

> Usmart.

Meget.

>> og en generel modvilje mod at
>> checke om filoperationer gik godt. Alt i alt et noget sjusket skrift.

> Jeg vil mene, at det kommer an på, hvad det enkelte
> kodeeksempel skal demonsterer. Hvis det er første side i
> kapitlet om brugen af filer, så skal der naturligvis testes.
> Men er det længere omme i bogen i et afsnit omhandlende
> f.eks. .. ja, hvad ved jeg, måske sampler op på en masse
> ting, og illusterer dette ved at implementere en ultra
> simpel database, så er der forskel.

> Men på den anden side, hvis der konsekvent testes hver evig
> eneste gang, så bliver læseren nok mere opmærksom på dette,
> og er mere tilbøjelig til selv at gøre det.

> Jeg synes nu det er en fin opslagsbog, hvis det er meget
> længe siden, jeg har programmeret og ikke lige kan huske,
> hvordan jeg åbner en fil, laver en case-sætning osv. Men
> ret meget mere kan den heller ikke bruges til.


>> Mit råd til dig er at du lægger Schildt på hylden, og studerer FAQ'en
>> fra comp.lang.c++ for at finde en liste over bøger der ikke er
>> skadelige.

> Den næste bog jeg har tænkt mig at købe er Linux Programming
> Unleashed, tror jeg. Eller Linux Device Drivers. Men måske
> skulle jeg i stedet få mig en rigtig, god C++-bog.

Det afhænger helt og holdent af hvad du kan, og hvad du vil med
c++. Men gør dig selv en tjeneste og kig på www.accu.org, hvis du skal
have dig en generel lærebog. De har reviews af 2000+ bøger.

--
/Wegge

---

On 13 Apr 2001 10:23:06 +0200, Anders Wegge Jakobsen wrote:
> > Hvad er forskellen? Nu er '\0' vel den rigtige
> > null-terminering til strenge, ikke?
>
> Det er den ja.
>
> NULL derimod er en pointerværdi, som man for eksempel får tilbage fra
>malloc(), hvis det ikke lod sig gøre at opfylde den request man havde.

Jamen NULL må da stadigvæk være representeret af en char et
eller andet sted? Eller hvordan er den gemt? Kan man ikke
gemme NULL i en variabel?


--
Stephan Henningsen /
/ http://tisprut.dk

---

"Stephan Henningsen" <stephan@sanxion.tisprut.dk> wrote in message
news:slrn9ddtpn.ia.stephan@sanxion.tisprut.dk...
> On 13 Apr 2001 10:23:06 +0200, Anders Wegge Jakobsen wrote:
> > > Hvad er forskellen? Nu er '\0' vel den rigtige
> > > null-terminering til strenge, ikke?
> >
> > Det er den ja.
> >
> > NULL derimod er en pointerværdi, som man for eksempel får tilbage fra
> >malloc(), hvis det ikke lod sig gøre at opfylde den request man havde.
>
> Jamen NULL må da stadigvæk være representeret af en char et
> eller andet sted? Eller hvordan er den gemt? Kan man ikke
> gemme NULL i en variabel?
>


NULL er (i Visual C++, og i de fleste andre compiler-miljøer AFAIK) blot en
macro defineret som "#define NULL 0", hvilket vil sige at NULL faktisk er en
int type konstant med værdien 0. Når du bruger den i forbindelse med
eksempelvis pointer-sammenligning så cast'es NULL til pointer typen
hvorefter sammenligningen laves.

Der er ikke noget i vejen for at bruge NULL med andre typer variable end
pointere. Så længe kompileren kan finde ud af selv at caste mellem de
enkelte typer kan det lade sig gøre, hvilket er tilfældet med de fleste
indbyggede (primitive) typer.

Dog er der en stærk tradition blandt mange for at NULL bruges i forbindelse
med pointere. Personligt foretrækker jeg at bruge "0" (int 0) overalt hvor
jeg har brug for en 0-værdi.

--
Claus Brinch Jensen

-!- When replying by e-mail please remove _all_ dashes from my e-mail
address.

---

"Claus Brinch Jensen" <c-b-j@e-mail.dk> wrote in message
news:9b6ui5$2u8j$1@news.cybercity.dk...
>
>
> Der er ikke noget i vejen for at bruge NULL med andre typer variable end
> pointere.
Er det virkeligt et godt og rigtigt råd ?
C++ Standarden siger i C.2.2.3 "The macro NULL, ..., is an
implementation-defined C++ null pointer constant ...".
Det er at foretrække aldrig at anvende NULL i C++.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:9b7235$27n$1@news.cybercity.dk...
>
> "Claus Brinch Jensen" <c-b-j@e-mail.dk> wrote in message
> news:9b6ui5$2u8j$1@news.cybercity.dk...
> >
> >
> > Der er ikke noget i vejen for at bruge NULL med andre typer variable end
> > pointere.
> Er det virkeligt et godt og rigtigt råd ?
> C++ Standarden siger i C.2.2.3 "The macro NULL, ..., is an
> implementation-defined C++ null pointer constant ...".
> Det er at foretrække aldrig at anvende NULL i C++.

Tjoeh, hvis du opfatter det som om at jeg råder Stephan til at bruge NULL i
alle de andre tilfælde. Det kan det måske også godt lyde som om, ikke mindst
med din hardcore redigering af tidligere brev . Men hvis det er den
opfattelse du, Stephan og evt. andre har fået har, så må jeg skynde mig at
sige at det ikke var det der var meningen.

Naturen af Stephans spørgsmål gik på få NULL afmystificeret, og det var i
den ånd at jeg svarede.

Men jeg må indrømme at jeg faktisk ikke anede at standarden direkte
forbinder NULL makroen til pointere. Jeg troede at den altovervejende brug
af NULL i forbindelse med pointere var konventionel snarere end det var
fastlagt i standarden. I så fald kan det undre mig hvorfor NULL ikke
defineres som en pointer (á la "#define NULL (void*)0") i stedet for et
0-int.

I øvrigt kunne jeg godt tænke mig en kopi af diverse standarder, C og C++
(så jeg også kan spille smart en gang imellem med diverse citater . Jeg
ved man kan købe dem hos standardiseringsorganistaionen (ISO) for et ikke
ubetydeligt beløb. Ved du om de tilfældigvis findes i online versioner til
gratis download anywhere?

--
Claus Brinch Jensen

-!- When replying by e-mail please remove ALL dashes from the address.

---

Hej Claus,
"Claus Brinch Jensen" <c-b-j@e-mail.dk> wrote in message
news:9b9krl$mac$1@news.cybercity.dk...

> alle de andre tilfælde. Det kan det måske også godt lyde som om, ikke
mindst
> med din hardcore redigering af tidligere brev .

Jeg undskylder, hvis du syntes jeg klippede for meget af.

> fastlagt i standarden. I så fald kan det undre mig hvorfor NULL ikke
> defineres som en pointer (á la "#define NULL (void*)0") i stedet for et
> 0-int.

Fordi ((void*)0) i C automatisk kan konverteres til en hvilken som helst
type pointer, uden brug af cast.
Det tilsvarende gælder ikke for C++.

>
> I øvrigt kunne jeg godt tænke mig en kopi af diverse standarder, C og C++
> (så jeg også kan spille smart en gang imellem med diverse citater . Jeg
> ved man kan købe dem hos standardiseringsorganistaionen (ISO) for et ikke
> ubetydeligt beløb. Ved du om de tilfældigvis findes i online versioner til
> gratis download anywhere?

De findes ikke gratis - med mindre det er ulovligt.
De kan dog købes som PDF filer for er rimeligt beløb $18 (ca. kr. 150,-) pr
styk.
C++ standarden hedder "ISO/IEC 14882:1998"
C standarden hedder "ISO/IEC 9899:1999"
Se http://webstore.ansi.org

Venlig hilsen

Mogens Hansen

---

Hej Mogens

"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:9b9lua$p32$1@news.cybercity.dk...
> Hej Claus,
> "Claus Brinch Jensen" <c-b-j@e-mail.dk> wrote in message
> news:9b9krl$mac$1@news.cybercity.dk...
>
> > fastlagt i standarden. I så fald kan det undre mig hvorfor NULL ikke
> > defineres som en pointer (á la "#define NULL (void*)0") i stedet for et
> > 0-int.
>
> Fordi ((void*)0) i C automatisk kan konverteres til en hvilken som helst
> type pointer, uden brug af cast.
> Det tilsvarende gælder ikke for C++.

Jamen netop derfor. Hvis man definerer NULL som en (void*), så vil den i C
netop virke med alle pointere, hvorimod den ikke vil virke med eksempelvis
en int, hvilket jo er ønskværdigt i henhold til standarden.

--C code--
#define NULL ((void*)0)

char * p1 = NULL; // lovligt
int i = NULL; // ulovligt
--C code--

> > ubetydeligt beløb. Ved du om de tilfældigvis findes i online versioner
til
> > gratis download anywhere?
>
> De findes ikke gratis - med mindre det er ulovligt.
> De kan dog købes som PDF filer for er rimeligt beløb $18 (ca. kr. 150,-)
pr
> styk.
> C++ standarden hedder "ISO/IEC 14882:1998"
> C standarden hedder "ISO/IEC 9899:1999"
> Se http://webstore.ansi.org

Okay, tak.

--
Claus Brinch Jensen

-!- When replying by e-mail please remove ALL dashes from the address.

---

Claus Brinch Jensen skrev:

>Jamen netop derfor. Hvis man definerer NULL som en (void*), så vil den i C
>netop virke med alle pointere, hvorimod den ikke vil virke med eksempelvis
>en int, hvilket jo er ønskværdigt i henhold til standarden.

Ifølge Kernighan&Ritchie (The C programming Language, second
edition) s. 102:
   The symbolic constant NULL is often used in place of
   zero, as a mnemonic to indicate more clearly that this is
   a special value for a pointer. NULL is defined in
   <stdio.h>. We will use NULL henceforth.

Selv foretrækker jeg også at skelne mellem 0 og NULL.

--
Bertel
http://lundhansen.dk/bertel/   FIDUSO: http://fiduso.dk/

---

Hej Claus,
"Claus Brinch Jensen" <c-b-j@e-mail.dk> wrote in message
news:9b9r3v$14p2$1@news.cybercity.dk...
>
> Jamen netop derfor. Hvis man definerer NULL som en (void*), så vil den i C
> netop virke med alle pointere, hvorimod den ikke vil virke med eksempelvis
> en int, hvilket jo er ønskværdigt i henhold til standarden.
>
> --C code--
> #define NULL ((void*)0)
>
> char * p1 = NULL; // lovligt
> int i = NULL; // ulovligt
> --C code--
>

Netop.
Det er væsentligt at skelne mellem C og C++.
I C er det fornuftigt at benytte NULL, af netop den grund du beskriver..
I C++ giver det ikke nogen fordel, fordi NULL ikke kan være defineret som
((void*0), og derfor foretrækkes det at bruge 0.

Fra Bjarne Stroustrup's bog, "The C++ Programming Language, Special
Edition", ISBN 0-201-70073-5, side 88 (Det er samme side i Third Edtion):
"In C, it has been popular to define a macro NULL to represent the zero
pointer. Because of C++'s tighter type checking, the use of plain 0, rather
than any suggested NULL macro, leads to fewer problems".
Som jeg også skrev tidligere i denne tråd, så beskriver Bjarne Stroustrup på
side 229-231, i "The Design and Evolution of C++", ISBN 0-201-54330-3,
baggrunden for null pointer.
Jeg syntes naturligvis begge bøger er fremragende.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen <mogens_h@dk-online.dk> skrev:
>Netop.
>Det er væsentligt at skelne mellem C og C++.
>I C er det fornuftigt at benytte NULL, af netop den grund du beskriver..
>I C++ giver det ikke nogen fordel, fordi NULL ikke kan være defineret som
>((void*0), og derfor foretrækkes det at bruge 0.

Der er i øvrigt en misforståelse (ikke at jeg tror MH lider af den)
som man ofte ser i forbindelse med null-pointere i C, nemlig at de
nødvendigvis svarer til hukommelsesadressen med talværdien 0. Det er
ikke tilfældet. Det er f.eks. implementationsafhængigt hvad
nedenstående C-program udskriver.

#include <stdlib.h>
#include <stdio.h>

int main ()
{
void **p = calloc (1, sizeof (void *));
if (p == 0)
{
fprintf (stderr, "No free memory.\n");
return EXIT_FAILURE;
}
if (*p == 0)
{
printf ("A null pointer is represented as all bits zero.\n");
}
else
{
printf ("A null pointer is not represented as all bits zero.\n");
}
free (p);
return EXIT_SUCCESS;
}

---

"Stephan Henningsen" <stephan@sanxion.tisprut.dk> wrote in message
news:slrn9ddtpn.ia.stephan@sanxion.tisprut.dk...
> On 13 Apr 2001 10:23:06 +0200, Anders Wegge Jakobsen wrote:
> > > Hvad er forskellen? Nu er '\0' vel den rigtige
> > > null-terminering til strenge, ikke?
> >
> > Det er den ja.
> >
> > NULL derimod er en pointerværdi, som man for eksempel får tilbage fra
> >malloc(), hvis det ikke lod sig gøre at opfylde den request man havde.
>
> Jamen NULL må da stadigvæk være representeret af en char et
> eller andet sted? Eller hvordan er den gemt? Kan man ikke

Nej, NULL er ikke representeret af en char. NULL er en implementations
defineret null pointer konstant.
Du kan således skrive:
char* p = NULL;

Almindeligvis foretrækkes det i C++ at anvende 0 for null-pointere frem for
NULL - dette er i modsætning til C.
I C vil NULL ofte være defineret som ((void*)0), hvor den i C++ ofte vil
være definere som 0, og bidrager derfor ikke med noget ud over hvad
anvendelsen af 0 giver.
Se "The Design and Evolution of C++", Bjarne Stroustrup, ISBN 0-201-54330-3,
side 229-231 for en beskrivelse af baggrunden.

Det foretrækkes derfor at skrive
char* p = 0;

> gemme NULL i en variabel?

Jo, hvis den er af pointer type.

Hvis man

Venlig hilsen

Mogens Hansen

---

* Stephan Henningsen

[snip]

> > Det er _komplett_ irrelevant. Det du skrev var feil. Period. Hvis
> > du insisterer, kan jeg peke på den relevante paragrafen i
> > språkdefinisjonen. Hva kompilatoren din/min/hans måtte akseptere
> > er uinteressant.
>
> Er du altid sådan?


Nei, men det er vel lite relevant i gruppens kontekst. Det som _er_
relevant er korrektheten av koden. Jeg _vet_ jeg kan underbygge mine
påstander med språkets definisjon (hvilket er den endelige instansen i
den type diskusjoner). Legg merke til _hva_ jeg protesterer på.

[snip]


> > Det var en _dårlig_ demonstrasjon, da koden ikke fungerte.
>
> FUT: dk.helbred.misbrug


Du har, mao., ingen _tekniske argumenter_ for å forsvare det søppelet
som ble postet. Fint, takk for at du spilte. Bruk litt mer tid neste
gang.





ivr
--
"making it suck less, one module at a time..."
John Bode on comp.lang.c (comment on program development)

---

"Kåre Mølgård Rasmussen" <kaare@obel.auc.dk> wrote:

>Forslag???

Hvis du bruger MFC skulle overveje at bruge CStringList.
-Bjarne

---

Hej Bjarne,
"Bjarne Laursen" <pyramide@po.ia.dk> wrote in message >
> Hvis du bruger MFC skulle overveje at bruge CStringList.

Hvilke fordele mener du at giver det at bruge CStringList i forhold til at
anvende klassen "std::vector<T>" som det er blevet foreslået i denne tråd ?

De åbenlyse ulemper ved at bruge CStringList er bl.a.:
* Man binder sig til et proprietært klasse-bibliotek
* Det er et gammelt, inferiørt design med mange velkendte problemer
* Selv Microsoft bevæger sig væk fra MFC i forbindelse med .NET
initiativet
* Det opfører sig ikke som et array, hvilket var hvad Kåre Mølgård
Rasmussen efterspurgte (f.eks. har overskrevet operator[], og har hurtig
random access)

De åbenlyse fordele ved at bruge "std::vector<T>" er bl.a.
* Den findes i alle tilnærmelsesvis seriøse og moderne C++ compilere (vi
snakker siden ca. 1996)- inklusiv Microsoft Visual C++
* Det er et moderne design, der passer godt til C++
* Det er performancemæssigt godt og velspecificeret
* Det stiller få krav til typerne som det kan indeholde
* Det opfører sig som et array

Hvis du ikke kender container klasserne i C++ Standard Library - vector,
deque, list, map, multimap, set, multiset og bitset - så kan jeg varmt
anbefale at du kigger på dem.
De findes beskrevet i online hjælpen til Visual C++, og der findes en del
glimrende bøger om dem.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote:

>Hvis du ikke kender container klasserne i C++ Standard Library - vector,
>deque, list, map, multimap, set, multiset og bitset - så kan jeg varmt
>anbefale at du kigger på dem.
Øh ja, det må jeg vist hellere.
-Bjarne