/ Forside / Teknologi / Udvikling / C/C++ / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
jdjespers.. 500
kyllekylle 500
Bech_bb 500
scootergr.. 300
gibson 300
molokyle 287
10  strarup 270
random_shuffle
Fra : Bertel Brander


Dato : 03-08-04 23:24

Hej NG,

Jeg lavede for nyligt følgende lille lottotals generator
i et andet fora:

#include <iostream>
#include <vector>
#include <algorithm>
#include <stdlib.h>
#include <time.h>

class RandomClass
{
public:
RandomClass()
{ srand(time(0)); }

int operator()(int range)
{ return rand()%range; }
};

int main()
{
std::vector<int> Vector;
int a;

for(a = 1; a < 90; a++)
Vector.push_back(a);

RandomClass Rand;

std::random_shuffle(Vector.begin(), Vector.end(), Rand);

for(a = 0; a < 5; a++)
std::cout << Vector[a] << std::endl;

return 0;
}

Det er der sådan set ikke de store problemer i, mine
kompilere er glade, og programmet gør det det skal, men;
Det forekommer mig at man burde kunne kalde random_shuffle
med en funktion i stedet for en instans af en klasse
som tredie argument.

Men mine forsøg herpå vil kompilerene ikke kompilere,
dvs. en vil godt kompilere noget, en anden noget andet og
.....

Er der nogen der har en løsning der:
1: Virker med de fleste kompilere
2: Overholder AnsiC++ standarden.

/b

 
 
Mogens Hansen (04-08-2004)
Kommentar
Fra : Mogens Hansen


Dato : 04-08-04 12:47


"Bertel Brander" <bertel@post4.tele.dk> wrote:

[8<8<8<]
> #include <stdlib.h>

#include <cstdlib>
er at foretrække, da den anden form er "depricated"

> #include <time.h>

#include <ctime>

[8<8<8<]
> int operator()(int range)
> { return rand()%range; }

Hvis vi antager at "rand" giver en jævn fordeling af tallene mellem 0 og
RAND_MAX og RAND_MAX er større end "range", så vil denne funktion _ikke_
give en jævn fordeling af tal mellem 0 og "range".

I stedet bør det være noget i retningen af

int operator()(int range)
{
if(range <= 0 || n > RAND_MAX)
throw domain_error("argument out of range");

const int bucket_size = RAND_MAX / range;
int r;
do r = rand() / bucket_size;
while (r >= range);

return r;
}

Se eventuelt
Accelerated C++
Andrew Koenig, Barbara E. Moo
ISBN 0-201-70353-X
side 135 for yderligere detaljer.

[8<8<8<]
> std::random_shuffle(Vector.begin(), Vector.end(), Rand);

Skal det ikke være
std::random_shuffle(Vector.begin(), Vector.end(), Rand());
hvor der faktisk bliver instantieret et "Rand" objekt ?

Bemærk at der findes 2 udgaver af random_shuffle:
* en hvor der bruges en default random generator
* en hvor man selv specificerer random generatoren

Er der nogen grund til at du gerne selv vil specificere random generatoren ?

Det forekommer mig at være nemmere at bruge default: det er både simplere at
bruge og man kan formode at default random generatoren giver en jævn
fordeling

[8<8<8<]
> Det forekommer mig at man burde kunne kalde random_shuffle
> med en funktion i stedet for en instans af en klasse
> som tredie argument.

Det skal være et funktions objekt, men der findes i C++ Standard Library
adaptere, der kan konveretere en "peger til funktion" til et funktions
objekt.

[8<8<8<]
> Er der nogen der har en løsning der:
> 1: Virker med de fleste kompilere

Den er lidt svær - hvad er "de fleste" ?

Jeg vælger at fortolke det upræcist som "moderne, almindeligt brugte
compilere som har implementeret C++ Standarden i rimelig grad". I den gruppe
finder vi på PC platformen f.eks. Microsoft Visual C++ .NET 2003, Intel C++
V7.0/V8.0, gcc 3.x og ofte Borland C++Builder V6.0.

Du har set Turbo C++ blive nævnt for nyligt har i gruppen, men den anser jeg
for at være så gammel at den er ligegyldig i denne sammenhæng. Visual C++
V6.0 hører til samme kategori, selvom den er fortsat er forholdsvis udbredt.

> 2: Overholder AnsiC++ standarden.

Det er oplagt.


Den simple version, som er testet med
Intel C++ for Windows V8.0
Microsoft Visual C++.NET 2003
Borland C++Builder V6.0
gcc 3.2 på Linux
og også oversat med
Comeau C/C++ 4.3.3
er
<C++ kode>
#include <vector>
#include <iostream>
#include <iterator>
#include <algorithm>

using namespace std;

int main()
{
vector<int> all_numbers;
for(int i = 1; i != 90; ++i)
all_numbers.push_back(i);

random_shuffle(all_numbers.begin(), all_numbers.end());
copy(all_numbers.begin(), all_numbers.begin()+5,
ostream_iterator<int, char>(cout, " "));
}
</C++ kode>

Den lidt mere komplicerede model, hvor man specificerer random funktionen,
testet med
Intel C++ for Windows V8.0
Microsoft Visual C++ .NET 2003
men virker ikke med
gcc 3.2 på Linux
Borland C++Builder V6.0
Comeau C/C++ 4.3.3
er
<C++ kode>
#include <vector>
#include <iostream>
#include <iterator>
#include <algorithm>
#include <stdexcept>
#include <functional>
#include <cstdlib>

using namespace std;

int nrand(int n)
{
if(n <= 0 || n > RAND_MAX)
throw domain_error("Argument to nrand is out of range");

const int bucket_size = RAND_MAX / n;
int r;

do r = rand() / bucket_size;
while (r >= n);

return r;
}

int main()
{
vector<int> all_numbers;
for(int i = 1; i != 90; ++i)
all_numbers.push_back(i);

random_shuffle(all_numbers.begin(), all_numbers.end(), ptr_fun(nrand));
copy(all_numbers.begin(), all_numbers.begin()+5,
ostream_iterator<int, char>(cout, " "));
}
</C++ kode>

For at få det til at virke med C++Builder, gcc og Comeau skal man ændre
random_shuffle(all_numbers.begin(), all_numbers.end(), ptr_fun(nrand));
til
pointer_to_unary_function<int, int> pnrand = ptr_fun(nrand);
random_shuffle(all_numbers.begin(), all_numbers.end(), pnrand);
eller på anden måde hjælpe med lave overload resolution, selvom jeg ikke
mener at det skulle være nødvendigt.
Det er klart grimmere, men dog er i overensstemmelse med C++ Standarden - og
opfylder dermed formodentligt dit ønske om at "virke med de fleste
compilere".

Venlig hilsen

Mogens Hansen




Bertel Brander (04-08-2004)
Kommentar
Fra : Bertel Brander


Dato : 04-08-04 19:05

Mogens Hansen wrote:
> "Bertel Brander" <bertel@post4.tele.dk> wrote:
>
> [8<8<8<]
>
>>#include <stdlib.h>
>
>
> #include <cstdlib>
> er at foretrække, da den anden form er "depricated"

Ja, problemet er blot at Visual C++ 6.0 ikke implementerer cstdlib
og ctime osv rigtigt, så indtil videre bruger jeg dem med .h

>
>> int operator()(int range)
>> { return rand()%range; }
>
>
> Hvis vi antager at "rand" giver en jævn fordeling af tallene mellem 0 og
> RAND_MAX og RAND_MAX er større end "range", så vil denne funktion _ikke_
> give en jævn fordeling af tal mellem 0 og "range".
>
> I stedet bør det være noget i retningen af
>

Lad os nu ikke forfalde til diskursion af random generatorer,
det er ikke emnet her.

>
>> std::random_shuffle(Vector.begin(), Vector.end,Rand
>
>
> Skal det ikke være
> std::random_shuffle(Vector.begin(), Vector.end( ), Rand)

Jo, min NG læser laver sjove ting, der skal stå:
std::random_shuffle(Vector.begin ( ) , Vector.end ( ) , Rand ) ;

>
> Bemærk at der findes 2 udgaver af random_shuffle:
> * en hvor der bruges en default random generator
> * en hvor man selv specificerer random generatoren

Ja, det ved jeg.

>
> Er der nogen grund til at du gerne selv vil specificere random generatoren ?
>
> Det forekommer mig at være nemmere at bruge default: det er både simplere at
> bruge og man kan formode at default random generatoren giver en jævn
> fordeling

Ideen er at jeg vil kunne seed'e den random generator som random_shuffle
bruger, jeg har ikke fundet en standard måde at gøre det på.

>
>>Det forekommer mig at man burde kunne kalde random_shuffle
>>med en funktion i stedet for en instans af en klasse
>>som tredie argument.
>
>
> Det skal være et funktions objekt, men der findes i C++ Standard Library
> adaptere, der kan konveretere en "peger til funktion" til et funktions
> objekt.
>
> [8<8<8<]
>
>>Er der nogen der har en løsning der:
>>1: Virker med de fleste kompilere
>
>
> Den er lidt svær - hvad er "de fleste" ?

Digital Mars, BorlandC 5.5, G++ 3.3.1, VisualC++ 6.0

> pointer_to_unary_function<int, int> pnrand = ptr_fun(nrand);
> random_shuffle(all_numbers.begin(), all_numbers.end,pnrand

Her har min news reader igen lavet tricks...
Denne model virker med mine kompilere, så den "køber" jeg.

Det er måske ikke så underligt hvis enkelte nybegyndere udi
C++ finder sproget en anelse besværligt at lære...

Mange tak for det udførlige svar.

/b

Mogens Hansen (04-08-2004)
Kommentar
Fra : Mogens Hansen


Dato : 04-08-04 22:07


"Bertel Brander" <bertel@post4.tele.dk> wrote:
> Mogens Hansen wrote:

[8<8<8<]
> Ja, problemet er blot at Visual C++ 6.0 ikke implementerer cstdlib
> og ctime osv rigtigt, så indtil videre bruger jeg dem med .h

Det kan jeg godt forstå.
Det er på mange områder en dårlig compiler med hensyn implementering af C++
Standarden.
Visual C++.NET 2003 er langt, langt bedre.

Det har altid undret mig at folk har brugt MSVC 6, hvis man skal skrive C++
kode der er i overensstemmelse med C++ Standarden, når der hele tiden har
været bedre alternativer tilgængelig.
F.eks. har Intel C++ længe været et simpelt alternativ:
* den er binær kompatibel med bl.a. MSVC 6
* integreret med MSVC 6 IDE'et
* væsentligt bedre til at overholde C++ Standarden
* ofte genereret mere effektiv kode.
Eventuelt kan den kombineres med en nyere version af Standard Library som
længe har været tilgængelig fra Dinkumware, som ligeledes var bedre i
relation til C++ Standarden end den version der leveres med.

[8<8<8<]
> Lad os nu ikke forfalde til diskursion af random generatorer,
> det er ikke emnet her.

Kode der bliver postet risikerer at blive kommenteret
Andre kunne blive fristet til at bruge funktionen, og det er ikke nogen god
ide.

[8<8<8<]
> Det er måske ikke så underligt hvis enkelte nybegyndere udi
> C++ finder sproget en anelse besværligt at lære...

Man kan lade være med at gøre det mere besværligt end nødvendigt.
Brug den simple udgave af random_shuffle og verificer eventuelt om det giver
en brugbar fordeling.
C++ giver _mulighed_ for mere kontrol og det kræver mere viden og arbejde.
Det lyder som en rimelig handel for mig.

Venlig hilsen

Mogens Hansen



Kent Friis (06-08-2004)
Kommentar
Fra : Kent Friis


Dato : 06-08-04 21:18

Den Wed, 4 Aug 2004 23:06:30 +0200 skrev Mogens Hansen:
>
> "Bertel Brander" <bertel@post4.tele.dk> wrote:
>> Mogens Hansen wrote:
>
> [8<8<8<]
>> Ja, problemet er blot at Visual C++ 6.0 ikke implementerer cstdlib
>> og ctime osv rigtigt, så indtil videre bruger jeg dem med .h
>
> Det kan jeg godt forstå.
> Det er på mange områder en dårlig compiler med hensyn implementering af C++
> Standarden.
> Visual C++.NET 2003 er langt, langt bedre.

Bare man husker at vælge "native" i stedet for ".NET", for ellers
mangler alle de ting som ikke er supporteret af .NET runtimen.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

Mogens Hansen (06-08-2004)
Kommentar
Fra : Mogens Hansen


Dato : 06-08-04 22:49


"Kent Friis" <nospam@nospam.invalid> wrote:

[8<8<8<]
> Bare man husker at vælge "native" i stedet for ".NET", for ellers
> mangler alle de ting som ikke er supporteret af .NET runtimen.

Hvilke ting er ikke supporteret af .NET runtimen ?

Du har ret i at jeg konkret testede de programmer jeg postede i denne tråd
som "native", men de kan oversættes til MSIL som eksekveres i .NET runtimen
uden modifikationer.
Det burde være sådan (og jeg har ikke set andet) at alle Standard C++
programmer som Microsoft Visual C++.NET 2003 kan oversætte som native, også
kan oversættes til MSIL med den samme semantik ved at ændre nogle compiler
switche. Det indbefatter blandt andet deterministisk destructor eksekvering
af objekter af typer der ligger inden for hvad Standard C++ tillader.
Bemærk f.eks. at .NET både har en Managed Heap og en Unmanaged Heap.

Der er problemer med integrationen med Standard C++ typer og Managed C++
typer i Visual C++.NET 2003 - men det er en anden historie.
Det bliver tilsyneladende langt bedre i C++/CLI som er en helt ny form for
"Managed C++" der kommer i Visual C++.NET 2005 (og endnu bedre i den
efterfølgende version....).

Her er en lille stump af den generede MSIL fra et af programmerne jeg skrev
i denne tråd:
<MSIL>
; 13 :
; 14 : random_shuffle(all_numbers.begin(), all_numbers.end());

ldloca.s 8 ; _all_numbers$
ldloca.s 7 ; $T12900
call ?begin@?$vector@HV?$allocator@H@std@@@std@@$$FQAE?AViterator@12@XZ
ldobj $MultiByteTokenSym$eccc947032562ea4b9efa500c411b6b3
ldloca.s 8 ; _all_numbers$
ldloca.s 6 ; $T13018
call ?end@?$vector@HV?$allocator@H@std@@@std@@$$FQAE?AViterator@12@XZ
ldobj $MultiByteTokenSym$eccc947032562ea4b9efa500c411b6b3
call
??$random_shuffle@Viterator@?$vector@HV?$allocator@H@std@@@std@@@std@@$$FYAX
Viterator@?$vector@HV?$allocator@H@std@@@0@0@Z
</MSIL>

Venlig hilsen

Mogens Hansen



Kent Friis (06-08-2004)
Kommentar
Fra : Kent Friis


Dato : 06-08-04 23:35

Den Fri, 6 Aug 2004 23:48:33 +0200 skrev Mogens Hansen:
>
> "Kent Friis" <nospam@nospam.invalid> wrote:
>
> [8<8<8<]
>> Bare man husker at vælge "native" i stedet for ".NET", for ellers
>> mangler alle de ting som ikke er supporteret af .NET runtimen.
>
> Hvilke ting er ikke supporteret af .NET runtimen ?

Multipel arv blandt andet, hvilket er en af de største forskelle på
C++ og C#.

Kombiner det med de andre underligheder (I hvilken af alle de filer
den opretter skal int main() være? Hvor kommer stdafx.h fra?), så synes
jeg at C# minder mere om C++ end C++.NET gør.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

Mogens Hansen (07-08-2004)
Kommentar
Fra : Mogens Hansen


Dato : 07-08-04 00:33


"Kent Friis" <nospam@nospam.invalid> wrote:
> Den Fri, 6 Aug 2004 23:48:33 +0200 skrev Mogens Hansen:
> >
> > "Kent Friis" <nospam@nospam.invalid> wrote:
> >
> > [8<8<8<]
> >> Bare man husker at vælge "native" i stedet for ".NET", for ellers
> >> mangler alle de ting som ikke er supporteret af .NET runtimen.
> >
> > Hvilke ting er ikke supporteret af .NET runtimen ?
>
> Multipel arv blandt andet, hvilket er en af de største forskelle på
> C++ og C#.

Hvor kommer C# ind i billedet ?
Taler du om Managed C++ og hvordan det afviger fra ISO Standard C++ ?

Jeg taler om at det _ikke_ er nødvendigt at huske at vælge "native" i stedet
for .NET for at oversætte et program, der er i overensstemmelse med C++
Standarden, med Visual C++.NET 2003.
Min påstand er at det ikke spiller nogen rolle om man har valgt "native"
eller .NET (option /clr) og jeg har vist at et program fra denne tråd kan
oversætte stil MSIL.
Dit oprindelige indlæg påstod det modsatte, hvilket er en almindelig men dog
fejlagtig opfattelse.

Jeg er helt sikker på at man kan bruge multiple arv i et C++ program og
oversætte det til .NET platformen (MSIL). Klassen std::fstream er et
eksempel på det og det giver ikke problemer.
Man kan ikke give et C# program adgang til native C++ typer som f.eks.
"std::vector<char>" eller "std::fstream", men det er en anden historie som
ikke spiller nogen rolle for denne tråd.

>
> Kombiner det med de andre underligheder (I hvilken af alle de filer
> den opretter skal int main() være?

Man kan frit flytte "int main()" over en i anden fil og stadig oversætte det
til MSIL.
Der er f.eks. ikke krav om at "int main" skal ligge en en fil der hedder det
samme som projektet.

> Hvor kommer stdafx.h fra?),

De programmer jeg postede tidligere i denne tråd bruger ikke "stdafx.h" og
de kan alligevel oversættes uden ændringer til MSIL der skal eksekveres på
..NET runtime miljøet.

> så synes
> jeg at C# minder mere om C++ end C++.NET gør.

Jeg forstår ikke hvad du mener.

Venlig hilsen

Mogens Hansen



Kent Friis (07-08-2004)
Kommentar
Fra : Kent Friis


Dato : 07-08-04 00:59

Den Sat, 7 Aug 2004 01:32:41 +0200 skrev Mogens Hansen:
>
> "Kent Friis" <nospam@nospam.invalid> wrote:
>> Den Fri, 6 Aug 2004 23:48:33 +0200 skrev Mogens Hansen:
>> >
>> > "Kent Friis" <nospam@nospam.invalid> wrote:
>> >
>> > [8<8<8<]
>> >> Bare man husker at vælge "native" i stedet for ".NET", for ellers
>> >> mangler alle de ting som ikke er supporteret af .NET runtimen.
>> >
>> > Hvilke ting er ikke supporteret af .NET runtimen ?
>>
>> Multipel arv blandt andet, hvilket er en af de største forskelle på
>> C++ og C#.
>
> Hvor kommer C# ind i billedet ?

C# er det sprog .NET er "født til", og derfor interessant at sammenligne
med når det drejer sig om at se hvilke muligheder .NET giver.

> Taler du om Managed C++ og hvordan det afviger fra ISO Standard C++ ?
>
> Jeg taler om at det _ikke_ er nødvendigt at huske at vælge "native" i stedet
> for .NET for at oversætte et program, der er i overensstemmelse med C++
> Standarden, med Visual C++.NET 2003.
> Min påstand er at det ikke spiller nogen rolle om man har valgt "native"
> eller .NET (option /clr) og jeg har vist at et program fra denne tråd kan
> oversætte stil MSIL.
> Dit oprindelige indlæg påstod det modsatte, hvilket er en almindelig men dog
> fejlagtig opfattelse.

Jeg har forsøgt at compile *et* C++ program i C++.NET, og det kunne
kun compiles når man satte den til native (eller unmanaged? Det er
muligt jeg bytter rundt på ordene)

Det var et lille bitte test-program der ikke indeholdt andet end tre
klasser, hvor den ene arvede fra de andre to.

>> Kombiner det med de andre underligheder (I hvilken af alle de filer
>> den opretter skal int main() være?
>
> Man kan frit flytte "int main()" over en i anden fil og stadig oversætte det
> til MSIL.
> Der er f.eks. ikke krav om at "int main" skal ligge en en fil der hedder det
> samme som projektet.

Men det ændrer ikke på at et normalt C++ program (som man lige har
oprettet (vi helloworld.cc) kun indeholder EN C++-fil, som ikke
indeholder andet end int main(), og der ikke er noget at være i tvivl
om.

Jeg prøvede skam at placere min kode i først den ene fil og så den
anden, og det gjorde ingen forskel, men jeg fandt aldrig ud af hvor
det er meningen den skal placeres. De ser allesammen ud som noget det
ikke er meningen man skal pille ved.

>> Hvor kommer stdafx.h fra?),
>
> De programmer jeg postede tidligere i denne tråd bruger ikke "stdafx.h" og
> de kan alligevel oversættes uden ændringer til MSIL der skal eksekveres på
> .NET runtime miljøet.

Det går jeg heller ikke ud fra at mit program gjorde (det gjorde det i
hvert fald ikke da jeg compilede den med gcc på en linux). Så det
forklarede ikke hvor filen kom fra, og hvorfor den var en del af
projektet.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

Mogens Hansen (07-08-2004)
Kommentar
Fra : Mogens Hansen


Dato : 07-08-04 07:13


"Kent Friis" <nospam@nospam.invalid> wrote:

[8<8<8<]
> Jeg har forsøgt at compile *et* C++ program i C++.NET, og det kunne
> kun compiles når man satte den til native (eller unmanaged? Det er
> muligt jeg bytter rundt på ordene)

Det påviser jo ikke at det ikke kan lade sig gøre at oversætte det som ikke
native (MSIL).
Det viser blot at det ikke lykkedes for dig i første forsøg.

Det _kan_ lade sig gøre.
Jeg _har_ som sagt gjort det uden problemer.
Microsoft siger det kan lade sig gøre - selvom de slår meget højt på tromme
for Managed C++ og .NET og alle der har fulgt trommerne får "glæde" af at
skulle lave det om til C++/CLI.

>
> Det var et lille bitte test-program der ikke indeholdt andet end tre
> klasser, hvor den ene arvede fra de andre to.

Kan du huske hvordan det så ud ?

F.eks. kan følgende lille eksempel, som svarer til min opfattelse af dit
program, uden problemer oversættes som .NET program (altså MSIL - ikke Intel
x86 native)
<C++ kode>
#include <iostream>

using namespace std;

class foo
{
public:
foo();
~foo();
};

class bar
{
public:
bar();
~bar();
};

class foobar : public foo,
public bar
{
public:
foobar();
~foobar();
};


foo::foo()
{
cout << "foo::foo() called" << endl;
}

foo:foo()
{
cout << "foo:foo() called" << endl;
}

bar::bar()
{
cout << "bar::bar() called" << endl;
}

bar:bar()
{
cout << "bar:bar() called" << endl;
}

foobar::foobar()
{
cout << "foobar::foobar() called" << endl;
}

foobar:foobar()
{
cout << "foobar:foobar() called" << endl;
}

int main()
{
cout << "Entering main" << endl;
foobar fb;
cout << "Leaving main" << endl;
}
</C++ kode>

hvilket fuldstændigt som forventet giver følgende output
<output>
Entering main
foo::foo() called
bar::bar() called
foobar::foobar() called
Leaving main
foobar:foobar() called
bar:bar() called
foo:foo() called
</output>

MSIL listningen for constructoren til "foobar" er
<MSIL listning>
..global ??0foobar@@$$FQAE@XZ ; foobar::foobar
??0foobar@@$$FQAE@XZ: ; foobar::foobar
; .proc.def D:I(I)

; Function Header:
; max stack depth = 3
; function size = 74 bytes
; local varsig tk = 0x0
; Exception Information:
; 2 handlers, each consisting of filtered handlers

; .formal.i4 0,"_this$" SIG: Optional C Binding
Modifier(token:0x933A42).Optional C Binding
Modifier(token:0x933A44).ptr.valueType (token:0x933A47)

; .proc.beg

; 49 : {

ldarg.0 ; _this$
call ??0foo@@$$FQAE@XZ
pop
$L12787:
ldarg.0 ; _this$
ldc.i.1 1 ; i32 0x1
add
call ??0bar@@$$FQAE@XZ
pop
$L12788:

; 50 : cout << "foobar::foobar() called" << endl;

ldsflda ?cout@std@@3V?$basic_ostream@DU?$char_traits@D@std@@@1@A
ldsflda $SG11008
call
??$?6U?$char_traits@D@std@@@std@@$$FYAAAV?$basic_ostream@DU?$char_traits@D@s
td@@@0@AAV10@PBD@Z
ldsfld
__unep@?endl@std@@$$FYAAAV?$basic_ostream@DU?$char_traits@D@std@@@1@AAV21@@Z
call
??6?$basic_ostream@DU?$char_traits@D@std@@@std@@$$FQAEAAV01@P6AAAV01@AAV01@@
Z@Z
pop
leave.s $L12789
$L12790:
ldsfld __unep@??1bar@@$$FQAE@XZ
ldarg.0 ; _this$
ldc.i.1 1 ; i32 0x1
add
call ?__CxxCallUnwindDtor@@$$J0YAXP6EXPAX@Z0@Z
endfinally
$L12789:
leave.s $L12791
$L12792:
ldsfld __unep@??1foo@@$$FQAE@XZ
ldarg.0 ; _this$
call ?__CxxCallUnwindDtor@@$$J0YAXP6EXPAX@Z0@Z
endfinally
$L12791:
</MSIL listning>

[8<8<8]
> Men det ændrer ikke på at et normalt C++ program (som man lige har
> oprettet (vi helloworld.cc) kun indeholder EN C++-fil, som ikke
> indeholder andet end int main(), og der ikke er noget at være i tvivl
> om.

Det er præcis det samme når man oversætte til .NET med Microsoft Visual
C++.NET 2003.

>
> Jeg prøvede skam at placere min kode i først den ene fil og så den
> anden, og det gjorde ingen forskel, men jeg fandt aldrig ud af hvor
> det er meningen den skal placeres.

IDE miljøets Wizard tilføjer en "ReadMe.txt" til projektet som indeholder en
beskrivelse af meningen med filerne.

> De ser allesammen ud som noget det
> ikke er meningen man skal pille ved.

Man kan sagtens både pille ved dem eller helt fjerne dem.
Se nedenfor.

Sådan er det tit med wizard: de er næsten for hjælpsomme og man bliver nemt
fremmedgjort overfor hvad de har lavet.

[8<8<8<]
> Det går jeg heller ikke ud fra at mit program gjorde (det gjorde det i
> hvert fald ikke da jeg compilede den med gcc på en linux). Så det
> forklarede ikke hvor filen kom fra, og hvorfor den var en del af
> projektet.

"stdafx.*" er noget som IDE-miljøets wizard laver når f.eks. man laver en
..NET console C++ applikation.
Dem kan du bare slette og fjerne fra projektet og så sætte compiler options
til ikke at bruge pre-compiled headers.

Filen AssembleInfo.cpp _kan_ slettes men jeg er i tvivl om hvorvidt det er
klogt, da man her kan skrive versions information etc. om exe-filen.
Dens eksistens ændrer heller ikke noget ved ens egen source kode - man vælge
at opfatte den som støtte-filer på lige fod med resource filer i Win32.

Referencerne i projektet (til bl.a. mscorlib) kan formodentlig ikke fjernes,
men det svarer jo også blot til runtime libraries på alle andre platforme.

Venlig hilsen

Mogens Hansen



Kent Friis (07-08-2004)
Kommentar
Fra : Kent Friis


Dato : 07-08-04 09:11

Den Sat, 7 Aug 2004 08:12:43 +0200 skrev Mogens Hansen:
>
> "Kent Friis" <nospam@nospam.invalid> wrote:
>
> [8<8<8<]
>> Jeg har forsøgt at compile *et* C++ program i C++.NET, og det kunne
>> kun compiles når man satte den til native (eller unmanaged? Det er
>> muligt jeg bytter rundt på ordene)
>
> Det påviser jo ikke at det ikke kan lade sig gøre at oversætte det som ikke
> native (MSIL).
> Det viser blot at det ikke lykkedes for dig i første forsøg.
>
> Det _kan_ lade sig gøre.
> Jeg _har_ som sagt gjort det uden problemer.
> Microsoft siger det kan lade sig gøre - selvom de slår meget højt på tromme
> for Managed C++ og .NET og alle der har fulgt trommerne får "glæde" af at
> skulle lave det om til C++/CLI.

Hvorfor "selvom"? Hvis det sagtens kan lade sig gøre, er der vel ikke
noget "selvom" over at anbefale folk at gøre det?

For mig at se ødelægger det ord din argumentation.

>> Det var et lille bitte test-program der ikke indeholdt andet end tre
>> klasser, hvor den ene arvede fra de andre to.
>
> Kan du huske hvordan det så ud ?
>
> F.eks. kan følgende lille eksempel, som svarer til min opfattelse af dit
> program, uden problemer oversættes som .NET program (altså MSIL - ikke Intel
> x86 native)

Mit var meget kortere, ingen cout, og jeg tror faktisk heller ikke der
var constructor/destructore i.

> [8<8<8]
>> Men det ændrer ikke på at et normalt C++ program (som man lige har
>> oprettet (vi helloworld.cc) kun indeholder EN C++-fil, som ikke
>> indeholder andet end int main(), og der ikke er noget at være i tvivl
>> om.
>
> Det er præcis det samme når man oversætte til .NET med Microsoft Visual
> C++.NET 2003.

Efter sidste geninstallation har jeg ikke længere C++.NET installeret
(kun VB og C#), så jeg kan ikke engang give dig listen af filer den
opretter.

>> Jeg prøvede skam at placere min kode i først den ene fil og så den
>> anden, og det gjorde ingen forskel, men jeg fandt aldrig ud af hvor
>> det er meningen den skal placeres.
>
> IDE miljøets Wizard tilføjer en "ReadMe.txt" til projektet som indeholder en
> beskrivelse af meningen med filerne.

Medmindre compileren er *meget* underlig, kan den fil ikke have været
imellem dem jeg konstaterede at det virkede at placere main() i.

>> De ser allesammen ud som noget det
>> ikke er meningen man skal pille ved.
>
> Man kan sagtens både pille ved dem eller helt fjerne dem.

Man kan også sagtens (og bliver ofte nødt til) at pille ved "Autogenerated
code, do not edit" sektionen i VB. Men det betyder ikke at det er
meningen man skal.

>> Det går jeg heller ikke ud fra at mit program gjorde (det gjorde det i
>> hvert fald ikke da jeg compilede den med gcc på en linux). Så det
>> forklarede ikke hvor filen kom fra, og hvorfor den var en del af
>> projektet.
>
> "stdafx.*" er noget som IDE-miljøets wizard laver når f.eks. man laver en
> .NET console C++ applikation.
> Dem kan du bare slette og fjerne fra projektet og så sætte compiler options
> til ikke at bruge pre-compiled headers.

Og det skal man bare vide? For det står sg* ikke i min udgave af The
C++ Programming Language...

> Filen AssembleInfo.cpp _kan_ slettes men jeg er i tvivl om hvorvidt det er
> klogt, da man her kan skrive versions information etc. om exe-filen.
> Dens eksistens ændrer heller ikke noget ved ens egen source kode - man vælge
> at opfatte den som støtte-filer på lige fod med resource filer i Win32.

Den overraskede mig til gengæld ikke, den er også i samtlige
VB-projekter. Det var alle de filer med underlige navne som den kun
opretter i C++, men hverken i VB eller C#, og som heller ikke er nævnt
i C++-standarden jeg kommenterede. Når hverken .NET eller C++ kræver
dem, hvorfor opretter den dem så?

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

Mogens Hansen (07-08-2004)
Kommentar
Fra : Mogens Hansen


Dato : 07-08-04 09:58


"Kent Friis" <nospam@nospam.invalid> wrote:
> Den Sat, 7 Aug 2004 08:12:43 +0200 skrev Mogens Hansen:

[8<8<8<]
> > Det _kan_ lade sig gøre.
> > Jeg _har_ som sagt gjort det uden problemer.
> > Microsoft siger det kan lade sig gøre - selvom de slår meget højt på
tromme
> > for Managed C++ og .NET og alle der har fulgt trommerne får "glæde" af
at
> > skulle lave det om til C++/CLI.
>
> Hvorfor "selvom"? Hvis det sagtens kan lade sig gøre, er der vel ikke
> noget "selvom" over at anbefale folk at gøre det?

Jo, set fra Microsoft's side kan jeg se en klar interesse i at promovere
features der binder udviklerne til Microsoft's platform, frem for features
der gør det nemt at flytte til en anden platform.
Det er som det altid har været - mange leverandører prøver på noget i den
stil.

>
> For mig at se ødelægger det ord din argumentation.

Jeg har ikke forklaret mig godt nok.
Vi taler om 3 forskellige sprog med et vist overlap og interoperabilitet:
* ISO Standard C++
* Microsoft Managed C++
* Microsoft/ECMA C++/CLI

Microsoft Visual C++.NET 2003 tilbyder en ikke perfekt men dog meget
glimrende implementering af ISO Standard C++.
Den implementering er lige godt undestøttet på:
* native Win32 på Intel x86 platformen (og vistnok Intel Itanium)
* Microsoft .NET V1.1 (MSIL/CLR) platformen
Der skulle ikke være nogen forskel på hvilke programmer der kan oversættes.
Programmerne der er vist i denne tråd falder ind i denne kategori, og kan
som jeg gang på gang har nævn oversættes til begge platforme (og mange andre
naturligvis).

Microsoft Visual C++.NET 2003 tilbyder at man oversætter Managed C++ til
..NET platformen men ikke til native Win32.

Microsoft Visual C++.NET 2005 (som pt. er i beta) tilbyder at man oversætter
C++/CLR til .NET platformen men formodentlig ikke til native Win32.


Mit "selvom" refererer til at Microsoft ikke gør nær så meget ud af at
fortælle at Visual C++.NET 2003 indeholder en glimrende ISO Standard C++ der
kan oversætte til begge platforme, som de gør ud af at fortælle om deres
Managed C++ og nu om deres C++/CLI.
Kig på deres hjemmeside, så kan du se hvad jeg mener.

Jeg _ved_ fra samtaler med en af udviklerne af Visual C++ compiler
front-enden at han faktisk gerne så at Microsoft gjorde mere for også at
promovere deres Standard C++ implementering - men det vil jeg ikke forvente
sker.

[8<8<8<]
> Mit var meget kortere, ingen cout, og jeg tror faktisk heller ikke der
> var constructor/destructore i.

Indeholdt det elementer som mit ikke gjorde ?

[8<8<8<]
> > IDE miljøets Wizard tilføjer en "ReadMe.txt" til projektet som
indeholder en
> > beskrivelse af meningen med filerne.
>
> Medmindre compileren er *meget* underlig, kan den fil ikke have været
> imellem dem jeg konstaterede at det virkede at placere main() i.



[8<8<8<]
> > "stdafx.*" er noget som IDE-miljøets wizard laver når f.eks. man laver
en
> > .NET console C++ applikation.
> > Dem kan du bare slette og fjerne fra projektet og så sætte compiler
options
> > til ikke at bruge pre-compiled headers.
>
> Og det skal man bare vide?

Man skal kigge i dokumentationen til produktet.
Eller bruge sin viden fra tidligere versioner af Visual C++.

> For det står sg* ikke i min udgave af The
> C++ Programming Language...

Hvor i "The C++ Programming Language" står beskrivelsen af compiler options
til gcc og DigitalMars ?
Produkt specifikke detaljer hører naturligvis ikke hjemme i den bog.

[8<8<8<]
> Når hverken .NET eller C++ kræver
> dem, hvorfor opretter den dem så?

Det kan du ikke med rimelighed kræve at jeg skal svare på - spørg Microsoft.
Det er dog ikke anderledes end hvad Visual C++ V6 gør når man opretter en
Win32 console applikation og ikke vælger "Empty project".
Jeg finder det (også) overflødigt og fremmedgørende.

Venlig hilsen

Mogens Hansen



Kent Friis (07-08-2004)
Kommentar
Fra : Kent Friis


Dato : 07-08-04 10:12

Den Sat, 7 Aug 2004 10:58:17 +0200 skrev Mogens Hansen:
>
> "Kent Friis" <nospam@nospam.invalid> wrote:
>> Den Sat, 7 Aug 2004 08:12:43 +0200 skrev Mogens Hansen:
>
>> Mit var meget kortere, ingen cout, og jeg tror faktisk heller ikke der
>> var constructor/destructore i.
>
> Indeholdt det elementer som mit ikke gjorde ?

Det mener jeg ikke, det indehold nærmest ikke noget

> [8<8<8<]
>> > IDE miljøets Wizard tilføjer en "ReadMe.txt" til projektet som
> indeholder en
>> > beskrivelse af meningen med filerne.
>>
>> Medmindre compileren er *meget* underlig, kan den fil ikke have været
>> imellem dem jeg konstaterede at det virkede at placere main() i.
>
>

Jaja, man skal aldrig sige aldrig, jeg har prøvet at tilføje en .cs
(C#) fil til et VB projekt (fordi VB mangler bit-rotations
funktionerne), og konstateret at den er ligeglad, den forsøger at
compile det som VB alligevel. Så er det da ikke usandsynligt at den
også kunne finde på at compile en .txt.

> [8<8<8<]
>> > "stdafx.*" er noget som IDE-miljøets wizard laver når f.eks. man laver
> en
>> > .NET console C++ applikation.
>> > Dem kan du bare slette og fjerne fra projektet og så sætte compiler
> options
>> > til ikke at bruge pre-compiled headers.
>>
>> Og det skal man bare vide?
>
> Man skal kigge i dokumentationen til produktet.
> Eller bruge sin viden fra tidligere versioner af Visual C++.
>
>> For det står sg* ikke i min udgave af The
>> C++ Programming Language...
>
> Hvor i "The C++ Programming Language" står beskrivelsen af compiler options
> til gcc og DigitalMars ?

head-er filer plejer ikke at høre under compiler options.

> Produkt specifikke detaljer hører naturligvis ikke hjemme i den bog.
>
> [8<8<8<]
>> Når hverken .NET eller C++ kræver
>> dem, hvorfor opretter den dem så?
>
> Det kan du ikke med rimelighed kræve at jeg skal svare på - spørg Microsoft.

Det kunne jo være du vidste det, jeg har indtryk af at du ved meget mere
om .NET end jeg gør.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

Mogens Hansen (05-08-2004)
Kommentar
Fra : Mogens Hansen


Dato : 05-08-04 20:43

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

> random_shuffle(all_numbers.begin(), all_numbers.end(),
> ptr_fun(nrand));

Det burde egentlig være overflødigt med kaldet til "ptr_fun", således at
man blot kan skrive
random_shuffle(all_numbers.begin(), all_numbers.end(), nrand);

Det virker med
Microsoft Visual C++.NET 2003
Intel C++ for Windows V8
gcc 3.2 på Linux
Comeau 4.3.3
men ikke med
Borland C++Builder V6

Venlig hilsen

Mogens Hansen

Anders Melchiorsen (06-08-2004)
Kommentar
Fra : Anders Melchiorsen


Dato : 06-08-04 22:36

Mogens Hansen <mogens_h@dk-online.dk> skrev den 05-Aug-04:

> "Mogens Hansen" <mogens_h@dk-online.dk> wrote:
>
> > random_shuffle(all_numbers.begin(), all_numbers.end(),
> > ptr_fun(nrand));
>
> Det burde egentlig være overflødigt med kaldet til "ptr_fun", således
> at man blot kan skrive
> random_shuffle(all_numbers.begin(), all_numbers.end(), nrand);

Har jeg læst dig rigtigt, at det er ikke alene overflødigt med
"ptr_fun", men det virker faktisk bedre (i flere oversættere) uden?


Anders.

--
Min adresse er gyldig i en uge.
Derefter skal (kun) delen '.dJJJ-YY' fjernes.

Mogens Hansen (06-08-2004)
Kommentar
Fra : Mogens Hansen


Dato : 06-08-04 22:51


"Anders Melchiorsen" <postmaster@anders.d219-04.nospam.kalibalik.dk> wrote:

[8<8<8<]
> Har jeg læst dig rigtigt, at det er ikke alene overflødigt med
> "ptr_fun", men det virker faktisk bedre (i flere oversættere) uden?

Ja.
(Min eneste undskyldning for mit første bud med ptr_fun er at jeg er
miljøskadet da jeg ofte bruger en compiler hvor det er nødvendigt .-( )

Venlig hilsen

Mogens Hansen



Søg
Reklame
Statistik
Spørgsmål : 177459
Tips : 31964
Nyheder : 719565
Indlæg : 6408183
Brugere : 218881

Månedens bedste
Årets bedste
Sidste års bedste