---

Hej

Jeg skal efter sommerferien til at undervise i programmering på HTX.
Det er grundlæggende programmering for elever, hvor nogen ingen
programmeringserfaring har overhovedet.
Fra Undervisningsministeriets side, ligger der ingen krav mht. valg af
programmeringssprog, hvorfor jeg har valgt Visual C++.

Jeg har dog ikke tidligere arbejdet med Visual C++, men har dog
C-programmeringserfaring gennem min uddannelse som ingeniør, samt lidt
uC-programmering.

Jeg har derfor brug for en lærebog til mig selv, til at lære sproget
ud fra (engelsk ingen hindring - Har overvejet en Teach Yourself ...
in XX days bog), men der er vel andre.
Endvidere har jeg brug for en letforståelig lærebog - gerne på dansk,
der skal bruges som klassesæt til at undervise ud fra.

Er der nogen, der har nogle gode titler, de vil dele med mig?

--
Med venlig hilsen

Tomas Skott

---

"Tomas Skott" <skott@fjernmig.festudvalget.dk> wrote in message
news:11491537420.0162915499297718@dtext.news.tele.dk...

[8<8<8<]
> Jeg skal efter sommerferien til at undervise i programmering på HTX.
> Det er grundlæggende programmering for elever, hvor nogen ingen
> programmeringserfaring har overhovedet.

Hvis man ingen programmeringserfaring har overhovedet vil jeg anbefale
You Can Do It: A Beginner's Introduction to Computer Programming
Francis Glassborow
ISBN 0-470-86398-6
eventuelt efterfulgt af
You Can Program in C++: A Programmer's Introduction
Francis Glassborow
ISBN 0-470-01468-7
Forfatteren er pensioneret skolelærer og har gennem mange år været en del af
C++ standardiserings komitteen.
Han har således både pædagogisk baggrund og god indsigt i C++.

Hvis man har lidt programmeringserfaring er
Accelerated C++: Practical Programming by Example
Andrew Koenig, Barbara E. Moo
ISBN 0-201-70353-X
ualmindelig god.
Begge forfattere har været involveret i C++ siden starten.

> Fra Undervisningsministeriets side, ligger der ingen krav mht. valg af
> programmeringssprog, hvorfor jeg har valgt Visual C++.

Visual C++ er ikke et programmeringssprog, men et produkt som Microsoft
laver til at udvikle C++ og C++/CLI programmer med.

[8<8<8<]
> Jeg har derfor brug for en lærebog til mig selv, til at lære sproget
> ud fra (engelsk ingen hindring - Har overvejet en Teach Yourself ...
> in XX days bog), men der er vel andre.

Umiddelbart vil jeg anbefale klassikeren
C++ Primer, Fourth Edition
Barbara E. Moo, Josee Lajoie, Stanley B. Lippman
ISBN 0-201-72148-1
som også er skrevet af folk der har en lang og dyb indsigt i C++.

Som underviser er du næsten nødt til at have den ultimative reference
The C++ Programming Language Special Edition
Bjarne Stroustrup
ISBN 0-201-70073-5
eller
The C++ Programming Language, Third Edition
Bjarne Stroustrup
ISBN 0-201-88954-4
hvor indholdet er de samme, men prisen, papirkvaliteten og indbindingen er
på et højere niveau i Special Edition

> Endvidere har jeg brug for en letforståelig lærebog - gerne på dansk,
> der skal bruges som klassesæt til at undervise ud fra.

Der findes ikke nogen gode bøger om C++ på dansk.
Derimod findes der nogle som er _forfærdigligt_ dårlige.
Den bedste, som ikke er dårlig, er efter min mening
C++ grundbog
Jesse Liberty
ISBN 87-7843-561-7

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
> "Tomas Skott" <skott@fjernmig.festudvalget.dk> wrote in message
> news:11491537420.0162915499297718@dtext.news.tele.dk...
>
> [8<8<8<]
>
>>Jeg skal efter sommerferien til at undervise i programmering på HTX.
>>Det er grundlæggende programmering for elever, hvor nogen ingen
>>programmeringserfaring har overhovedet.
>
>
> Hvis man ingen programmeringserfaring har overhovedet vil jeg anbefale
> You Can Do It: A Beginner's Introduction to Computer Programming
> Francis Glassborow
> ISBN 0-470-86398-6
> eventuelt efterfulgt af
> You Can Program in C++: A Programmer's Introduction
> Francis Glassborow
> ISBN 0-470-01468-7
> Forfatteren er pensioneret skolelærer og har gennem mange år været en del af
> C++ standardiserings komitteen.
> Han har således både pædagogisk baggrund og god indsigt i C++.
>
> Hvis man har lidt programmeringserfaring er
> Accelerated C++: Practical Programming by Example
> Andrew Koenig, Barbara E. Moo
> ISBN 0-201-70353-X
> ualmindelig god.
> Begge forfattere har været involveret i C++ siden starten.

Det skal også nævnes at Francis Glassborrow har lavet en ny bog for folk
med lidt erfaring. Den ville jeg nok vælge istedet for Accelerated C++.

Den fulde titel er: You Can Program in C++: A Programmer's Introduction

Fordelene ved francis's bøger er bla. at han bruger grafik og lyd
biblioteker til at lave motiverende programmer.

-Thorsten

---

"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message
news:447f347f$0$60785$157c6196@dreader1.cybercity.dk...
> Mogens Hansen wrote:

[8<8<8<]
>> Hvis man ingen programmeringserfaring har overhovedet vil jeg anbefale
>> You Can Do It: A Beginner's Introduction to Computer Programming
>> Francis Glassborow
>> ISBN 0-470-86398-6
>> eventuelt efterfulgt af
>> You Can Program in C++: A Programmer's Introduction
>> Francis Glassborow
>> ISBN 0-470-01468-7
>> Forfatteren er pensioneret skolelærer og har gennem mange år været en del
>> af C++ standardiserings komitteen.
>> Han har således både pædagogisk baggrund og god indsigt i C++.
>>
>> Hvis man har lidt programmeringserfaring er
>> Accelerated C++: Practical Programming by Example
>> Andrew Koenig, Barbara E. Moo
>> ISBN 0-201-70353-X
>> ualmindelig god.
>> Begge forfattere har været involveret i C++ siden starten.
>
> Det skal også nævnes at Francis Glassborrow har lavet en ny bog for folk
> med lidt erfaring. Den ville jeg nok vælge istedet for Accelerated C++.
>
> Den fulde titel er: You Can Program in C++: A Programmer's Introduction

Jeps - den nævnte jeg også
Jeg talte med Francis Glassborow om den og hvordan den adskilte sig fra hans
første bog ved ACCU2006, hvor den blev vist første gang

Venlig hilsen

Mogens Hansen

---

Mogens Hansen <mogens_h@dk-online.dk> skrev:
>
>"Thorsten Ottosen"
><thorsten.ottosen@dezide.com> wrote in message
>news:447f347f$0$60785$157c6196@dreader
>1.cybercity.dk...
>> Mogens Hansen wrote:
>
>[8<8<8<]
>>> Hvis man ingen
>>>programmeringserfaring har
>>>overhovedet vil jeg anbefale
>>> You Can Do It: A Beginner's
>>>Introduction to Computer Programming
>>> Francis Glassborow
>>> ISBN 0-470-86398-6
>>> eventuelt efterfulgt af
>>> You Can Program in C++: A
>>>Programmer's Introduction
>>> Francis Glassborow
>>> ISBN 0-470-01468-7
>>> Forfatteren er pensioneret
>>>skolelærer og har gennem mange år
>>>været en del
>>> af C++ standardiserings komitteen.
>>> Han har således både pædagogisk
>>>baggrund og god indsigt i C++.
>>>
>>> Hvis man har lidt
>>>programmeringserfaring er
>>> Accelerated C++: Practical
>>>Programming by Example
>>> Andrew Koenig, Barbara E. Moo
>>> ISBN 0-201-70353-X
>>> ualmindelig god.
>>> Begge forfattere har været
>>>involveret i C++ siden starten.
>>
>> Det skal også nævnes at Francis
>>Glassborrow har lavet en ny bog for folk
>> med lidt erfaring. Den ville jeg nok
>>vælge istedet for Accelerated C++.
>>
>> Den fulde titel er: You Can Program
>>in C++: A Programmer's Introduction
>
>Jeps - den nævnte jeg også
>Jeg talte med Francis Glassborow om
>den og hvordan den adskilte sig fra hans
>første bog ved ACCU2006, hvor den blev
>vist første gang
>
>Venlig hilsen
>
>Mogens Hansen

Det var da lige et par stykker
Jeg tager da lige en kigger på dem.

Vil I ligefremt fraråde Visual C++ (Ved godt, det "kun" er
brugerfladen, Microsoft står bag), min begrundelse for at vælge
det produkt var, at eleverne lettere vil få et kick ud af
programmering.

Men takker for anbefalingerne.

--
Med venlig hilsen

Tomas Skott

---

Tomas Skott wrote:
> Vil I ligefremt fraråde Visual C++ (Ved godt, det "kun" er
> brugerfladen, Microsoft står bag), min begrundelse for at vælge
> det produkt var, at eleverne lettere vil få et kick ud af
> programmering.


Så vidt jeg ved laver Microsoft både brugerflade og selve
compileren.

Du skal huske på at hvis du vil bruge .net sammen med VC++
skal det programmers i C++/CLI hvilket ikke er rigtig C++

Hvis du vil lære eleverne rigtig C++ (hvilket jeg synes at
du skal) kan I ikke bruge .net, og dermed ikke bruge .nets
muligheder for at lave GUI.

VisualC++ er en udemærket GUI og compiler, også til rigtig
C++.

Men til ren C++ ville jeg nok vælge noget simplere, f.ex:
http://www.codeblocks.org/
Det er en windows GUI til MinGW compileren, der er en
udgave af GCC til windows. GCC er compileren for Linux
og mange embeddede/indlejrede platforme.

--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel

---

Bertel Brander <bertel@post4.tele.dk> skrev:
>Tomas Skott wrote:
>> Vil I ligefremt fraråde Visual C++ (Ved godt, det "kun" er
>> brugerfladen, Microsoft står bag), min begrundelse for at
vælge
>> det produkt var, at eleverne lettere vil få et kick ud af
>> programmering.
>
>
>Så vidt jeg ved laver Microsoft både brugerflade og selve
>compileren.
>
>Du skal huske på at hvis du vil bruge .net sammen med VC++
>skal det programmers i C++/CLI hvilket ikke er rigtig C++

Det er ikke planen. Faget dækker 75 timer over et helt skoleår.
Hvad er CLI?

>
>Hvis du vil lære eleverne rigtig C++ (hvilket jeg synes at
>du skal) kan I ikke bruge .net, og dermed ikke bruge .nets
>muligheder for at lave GUI.

Enig
>
>VisualC++ er en udemærket GUI og compiler, også til rigtig
>C++.
>
>Men til ren C++ ville jeg nok vælge noget simplere, f.ex:
>http://www.codeblocks.org/
>Det er en windows GUI til MinGW compileren, der er en
>udgave af GCC til windows. GCC er compileren for Linux
>og mange embeddede/indlejrede platforme.

Jeg kender ikke MinGW. Hvad står den evt. i?


--
Med venlig hilsen

Tomas Skott

---

"Tomas Skott" <skott@fjernmig.festudvalget.dk> wrote in message
news:11492251750.897759275422317@dtext.news.tele.dk...
> Bertel Brander <bertel@post4.tele.dk> skrev:

[8<8<8<]
> Det er ikke planen. Faget dækker 75 timer over et helt skoleår.
> Hvad er CLI?

Common Language Interface.
En del af det tekniske fundament i det Microsoft kalder .NET - populært sagt
Microsofts svar på Java.

C++/CLI er udvidelser til C++ sproget, der gør det muligt at tilgå og udvide
..NET run-time miljøet.

[8<8<8<]
>>Hvis du vil lære eleverne rigtig C++ (hvilket jeg synes at
>>du skal) kan I ikke bruge .net, og dermed ikke bruge .nets
>>muligheder for at lave GUI.
>
> Enig

Det vil også være min anbefaling.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> C++/CLI er udvidelser til C++ sproget, der gør det muligt at tilgå og udvide
> .NET run-time miljøet.

Ville det ikke være bedre at kalde det en ændringer (ikke udvidelser),
så vidt jeg ved er det ikke al gyldig C++ kode der er gyldig C++/CLI
kode?

--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel

---

Den Fri, 02 Jun 2006 20:43:27 +0200 skrev Bertel Brander:
> Mogens Hansen wrote:
>
>> C++/CLI er udvidelser til C++ sproget, der gør det muligt at tilgå og udvide
>> .NET run-time miljøet.
>
> Ville det ikke være bedre at kalde det en ændringer (ikke udvidelser),
> så vidt jeg ved er det ikke al gyldig C++ kode der er gyldig C++/CLI
> kode?

Du mener: Er "lad os afskaffe multipel arv, det kan VB-folk alligevel
ikke finde ud af" en udvidelse?



Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

On Fri, 02 Jun 2006 20:43:27 +0200, Bertel Brander wrote:

>
> Ville det ikke være bedre at kalde det en ændringer (ikke udvidelser),
> så vidt jeg ved er det ikke al gyldig C++ kode der er gyldig C++/CLI
> kode?
Så længe det drejer sig om tilpasninger til et framework, der er ISO-C++
uvedkommende, er det ikke ændringer, men udvidelser af standarden,
hvorfor det ikke mere er C++.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

"Bertel Brander" <bertel@post4.tele.dk> wrote in message
news:448086ca$0$115$edfadb0f@dread16.news.tele.dk...
> Mogens Hansen wrote:
>
>> C++/CLI er udvidelser til C++ sproget, der gør det muligt at tilgå og
>> udvide .NET run-time miljøet.
>
> Ville det ikke være bedre at kalde det en ændringer (ikke udvidelser),
> så vidt jeg ved er det ikke al gyldig C++ kode der er gyldig C++/CLI
> kode?

Som jeg har forstået det er der tale om en (stor) udvidelse. ISO C++ kode
skulle uden begrænsninger eller ændret semantik *) kunne oversættes i
C++/CLI mode (option /clr).
Når man begynder at bruge udvidelserne sker der ting og sager, som muligvis
er overraskende sommetider (f.eks. dyb virtuel funktions-kald i
constructor/destructor - iøvrigt præcis som i VCL i Borland C++Builder)
Begrundelserne for designet af C++/CLI kan ses i
http://www.gotw.ca/publications/C++CLIRationale.pdf

Der har jo været noget kritik af C++/CLI ISO standardiserings-processen af
fra BSI.
På min hjemmeside kan man se et par billeder fra en debat panel mellem Herb
Sutter (designeren af C++/CLI) og medlemmer fra BSI:
http://www.hansen4.dk/fotoalbum/displayimage.php?album=24&pos=19
http://www.hansen4.dk/fotoalbum/displayimage.php?album=24&pos=20

Venlig hilsen

Mogens Hansen


*) I den udstrækning Visual C++ 2005 kan oversætte koden i native mode.
Den er ikke 100% compliant - men temmeligt tæt på

---

Bertel Brander wrote:
> Ville det ikke være bedre at kalde det en ændringer (ikke udvidelser),
> så vidt jeg ved er det ikke al gyldig C++ kode der er gyldig C++/CLI
> kode?

Så vidt jeg ved kan den oversætte ethvert standard C++
program.

Den har en lang række udvidelser og det er ikke kun
klasse biblioteker men også udvidelser til selve
sproget.

Disse udvidelser og standard features kan ikke
nødvendigvis blandes. Men det gør den vel ikke
til non compliant.

Arne

---

Den Fri, 02 Jun 2006 21:02:43 -0400 skrev Arne Vajhøj:
> Bertel Brander wrote:
>> Ville det ikke være bedre at kalde det en ændringer (ikke udvidelser),
>> så vidt jeg ved er det ikke al gyldig C++ kode der er gyldig C++/CLI
>> kode?
>
> Så vidt jeg ved kan den oversætte ethvert standard C++
> program.

Sålænge man husker at vælge NATIVE, ja.

Ellers kan man ikke bruge de ting der ikke er supporteret i .NET
runtime'n, fx multipel arv. Eller er det lavet om i .NET 2.0?

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Fri, 02 Jun 2006 21:02:43 -0400 skrev Arne Vajhøj:
>> Bertel Brander wrote:
>>> Ville det ikke være bedre at kalde det en ændringer (ikke udvidelser),
>>> så vidt jeg ved er det ikke al gyldig C++ kode der er gyldig C++/CLI
>>> kode?
>> Så vidt jeg ved kan den oversætte ethvert standard C++
>> program.
>
> Sålænge man husker at vælge NATIVE, ja.
>
> Ellers kan man ikke bruge de ting der ikke er supporteret i .NET
> runtime'n, fx multipel arv. Eller er det lavet om i .NET 2.0?

Mit indtryk er at der for unmanaged typer gælder
de normale C++ regler, men at der for managed
typer gælder .NET regler.

Og et lille eksperiment kunne ihvertfald ikke
afkræfte den hypotese.

#using <mscorlib.dll>

class A
{
public:
int a;
A() { a = 123; };
};

class B
{
public:
int b;
B() { b = 456; };
};

class C : public A, public B
{
};

int main()
{
C *c = new C();
System::Console::WriteLine(c->a);
System::Console::WriteLine(c->b);
return 0;
}

compiler fint i både 13.1/7.1/2003/1.1 og 14.0/8.0/2005/2.0.

#using <mscorlib.dll>

__gc class A
{
public:
int a;
A() { a = 123; };
};

__gc class B
{
public:
int b;
B() { b = 456; };
};

__gc class C : public A, public B
{
};

int main()
{
C *c = new C();
System::Console::WriteLine(c->a);
System::Console::WriteLine(c->b);
return 0;
}

fejler i 7.1.

#using <mscorlib.dll>

ref class A
{
public:
int a;
A() { a = 123; };
};

ref class B
{
public:
int b;
B() { b = 456; };
};

ref class C : public A, public B
{
};

int main()
{
C^ c = gcnew C();
System::Console::WriteLine(c->a);
System::Console::WriteLine(c->b);
return 0;
}

fejler i 8.0.

[det første eksempel skulle naturligvis bruge cout for at
være standard C++, men jeg valgte System::Console for
at dokumentere at der var brugt /clr]

Så jeg tror stadigvæk at standard C++ kode opfører sig
som standard C++ kode, men at det først er når man begynder
at ændre tingene til .NET måden (med __gc og ref) at man
kommer under .NET reglerne.

Disclaimer: jeg har ikke arbejde ret meget med C++ .NET,
så jeg skal absolut ikke udelukke, at der er standard C++
kode som ikke vil compile med /clr - jeg er bare ikke
stødt på det endnu.

Arne

---

"Arne Vajhøj" <arne@vajhoej.dk> wrote in message
news:iL6gg.37724$fG3.33395@dukeread09...

[8<8<8<]
> Disclaimer: jeg har ikke arbejde ret meget med C++ .NET,
> så jeg skal absolut ikke udelukke, at der er standard C++
> kode som ikke vil compile med /clr - jeg er bare ikke
> stødt på det endnu.

Det er der helt sikkert.
Det skulle være præcis de samme ISO C++ ting som heller ikke oversætter med
native med Microsoft Visual C++ .NET 2005 - hvilket betyder at der er en høj
grad af compliance, men ikke 100%
Dertil kommer at der naturligvis kan være konkrete fejl i implementering.

Venlig hilsen

Mogens Hansen

---

Den Fri, 02 Jun 2006 22:47:51 -0400 skrev Arne Vajhøj:
> Kent Friis wrote:
>> Den Fri, 02 Jun 2006 21:02:43 -0400 skrev Arne Vajhøj:
>>> Bertel Brander wrote:
>>>> Ville det ikke være bedre at kalde det en ændringer (ikke udvidelser),
>>>> så vidt jeg ved er det ikke al gyldig C++ kode der er gyldig C++/CLI
>>>> kode?
>>> Så vidt jeg ved kan den oversætte ethvert standard C++
>>> program.
>>
>> Sålænge man husker at vælge NATIVE, ja.
>>
>> Ellers kan man ikke bruge de ting der ikke er supporteret i .NET
>> runtime'n, fx multipel arv. Eller er det lavet om i .NET 2.0?
>
> Mit indtryk er at der for unmanaged typer gælder
> de normale C++ regler, men at der for managed
> typer gælder .NET regler.

Unmanaged, Native, ok, så fik jeg skrevet det forkerte ord - og så kan
jeg jo spørge hvor h*vede forskellen er på de to ord, udover hvilke
bogstaver de består af...

Det er nok mindst et år siden jeg testede, så det kan vel ikke
overraske at jeg ikke kan huske præcis hvad der stod i menuen.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

"Kent Friis" <nospam@nospam.invalid> wrote in message
news:44813eab$0$15792$14726298@news.sunsite.dk...

[8<8<8<]
> Unmanaged, Native, ok, så fik jeg skrevet det forkerte ord - og så kan
> jeg jo spørge hvor h*vede forskellen er på de to ord, udover hvilke
> bogstaver de består af...

Ok - måske misforstår jeg hvad du mener med at "vælge NATIVE".
Jeg forstår det som en compiler option, hvor man vælger enten at oversætte
til native CPU instruktion (f.eks. Intel x86) eller managed så der genereres
MSIL instruktioner (option /clr).
Det har således _intet_ med source-koden at gøre.
Med unmaged typer snakker jeg om ting der står i source-koden, f.eks.
class foo {};
i modsætning til en managed type f.eks.
clr class foo {};

Venlig hilsen

Mogens Hansen

---

Den Sat, 3 Jun 2006 10:03:19 +0200 skrev Mogens Hansen:
>
> "Kent Friis" <nospam@nospam.invalid> wrote in message
> news:44813eab$0$15792$14726298@news.sunsite.dk...
>
> [8<8<8<]
>> Unmanaged, Native, ok, så fik jeg skrevet det forkerte ord - og så kan
>> jeg jo spørge hvor h*vede forskellen er på de to ord, udover hvilke
>> bogstaver de består af...
>
> Ok - måske misforstår jeg hvad du mener med at "vælge NATIVE".
> Jeg forstår det som en compiler option, hvor man vælger enten at oversætte
> til native CPU instruktion (f.eks. Intel x86) eller managed så der genereres
> MSIL instruktioner (option /clr).
> Det har således _intet_ med source-koden at gøre.
> Med unmaged typer snakker jeg om ting der står i source-koden, f.eks.
> class foo {};
> i modsætning til en managed type f.eks.
> clr class foo {};

Det er muligt det kan ændres i source-koden, det var i menuen jeg
fandt det.

Jeg kan dog ikke mindes at have set "clr class", men det er som sagt
over et år siden jeg gjorde forsøget.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Unmanaged, Native, ok, så fik jeg skrevet det forkerte ord - og så kan
> jeg jo spørge hvor h*vede forskellen er på de to ord, udover hvilke
> bogstaver de består af...

Ordene er fuldstændigt ligegyldige.

Det vigtige er at det ikke er compiler switchen som
gør forskellen.

Der er den eksplicitte angivelse i source koden at
noget skal være en .NET type som gør forskellen.

At

ref class C : public A, public B
{
};

giver fejl fordi man ikke kan arve fra 2 klasser
kan vel ikke kaldes en ISO C++
overtrædelse, fordi ingen ISO C++ kode vil have
det ref keyword.

Programmøren har eksplicit valgt at ville
bruge .NET fremfor C++ for den type.

Arne

---

"Kent Friis" <nospam@nospam.invalid> wrote in message
news:4480e553$0$15791$14726298@news.sunsite.dk...

[8<8<8<]
> Sålænge man husker at vælge NATIVE, ja.

Nej, det mener jeg bestemt ikke er rigtigt.
Man kan sagtens oversætte ISO C++ til MSIL med optin /clr.

>
> Ellers kan man ikke bruge de ting der ikke er supporteret i .NET
> runtime'n, fx multipel arv.

Man kan godt bruge multiple arv i C++/CLI - det kræver ikke at .NET runtime
supporterer det. På samme måde som det ikke er påkrævet at en Intel x86 CPU
supporterer multiple arv.
Det man ikke kan er at lave en klasse med f.eks. multiple arv og gøre den
tilgængelig for andre .NET sprog som f.eks. C#. Det vil nemlig kræve CLI
specifikationen understøtter multiple arv.

> Eller er det lavet om i .NET 2.0?

Nej - men der er tilføjet support for Generics

Venlig hilsen

Mogens Hansen

---

Den Sat, 3 Jun 2006 08:01:43 +0200 skrev Mogens Hansen:
>
> "Kent Friis" <nospam@nospam.invalid> wrote in message
> news:4480e553$0$15791$14726298@news.sunsite.dk...
>
> [8<8<8<]
>> Sålænge man husker at vælge NATIVE, ja.
>
> Nej, det mener jeg bestemt ikke er rigtigt.
> Man kan sagtens oversætte ISO C++ til MSIL med optin /clr.
>
>>
>> Ellers kan man ikke bruge de ting der ikke er supporteret i .NET
>> runtime'n, fx multipel arv.
>
> Man kan godt bruge multiple arv i C++/CLI - det kræver ikke at .NET runtime
> supporterer det.

Og du er sikker på det ikke bliver compilet som native code der bare
kræver .NET runtimen (og stadig kan kalde funktionerne)?

> På samme måde som det ikke er påkrævet at en Intel x86 CPU
> supporterer multiple arv.

Nævn en CPU der ikke gør, hvor det er implementeret.

> Det man ikke kan er at lave en klasse med f.eks. multiple arv og gøre den
> tilgængelig for andre .NET sprog som f.eks. C#. Det vil nemlig kræve CLI
> specifikationen understøtter multiple arv.

Og hvad kan man så bruge det til? Det samme som en native DLL?

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

"Kent Friis" <nospam@nospam.invalid> wrote in message
news:44814028$0$15792$14726298@news.sunsite.dk...

[8<8<8<]
> Og du er sikker på det ikke bliver compilet som native code der bare
> kræver .NET runtimen (og stadig kan kalde funktionerne)?

Ja, det bliver oversat til MSIL.
Nogle få funktioner, f.eks. hvis de indeholder inline assembler, bliver
oversat til native instruktion (f.eks. Intel x86).

>
>> På samme måde som det ikke er påkrævet at en Intel x86 CPU
>> supporterer multiple arv.
>
> Nævn en CPU der ikke gør, hvor det er implementeret.

Fidusen er at multiple arv, exception, template etc. blot er abstraktioner
der eksisterer i source-koden, men som ikke er repræsenteret direkte i det
eksekverbare program.

>
>> Det man ikke kan er at lave en klasse med f.eks. multiple arv og gøre den
>> tilgængelig for andre .NET sprog som f.eks. C#. Det vil nemlig kræve CLI
>> specifikationen understøtter multiple arv.
>
> Og hvad kan man så bruge det til? Det samme som en native DLL?

Det er meget analogt til DLL'er:
Man kan bruge al det C++ inde i DLL'et man har lyst til, men hvis man vil
stille det til rådighed for andre, uafhængig af compiler og compiler version
skal man brug et C eller COM interface.

Venlig hilsen

Mogens Hansen

---

Den Sat, 3 Jun 2006 10:02:56 +0200 skrev Mogens Hansen:
>
> "Kent Friis" <nospam@nospam.invalid> wrote in message
> news:44814028$0$15792$14726298@news.sunsite.dk...
>
> [8<8<8<]
>> Og du er sikker på det ikke bliver compilet som native code der bare
>> kræver .NET runtimen (og stadig kan kalde funktionerne)?
>
> Ja, det bliver oversat til MSIL.

For sjov skyld, eller med alle de "fordele" det påstås at give?

>>> På samme måde som det ikke er påkrævet at en Intel x86 CPU
>>> supporterer multiple arv.
>>
>> Nævn en CPU der ikke gør, hvor det er implementeret.
>
> Fidusen er at multiple arv, exception, template etc. blot er abstraktioner
> der eksisterer i source-koden, men som ikke er repræsenteret direkte i det
> eksekverbare program.

Abstraktioner, ja, men repræsenteret? Ja det kommer selvfølgelig an på
hvad du mener med repræsenteret, men de er der, selvom der naturligvis
ikke direkte står "multipel arv" i exe-filen.

>>> Det man ikke kan er at lave en klasse med f.eks. multiple arv og gøre den
>>> tilgængelig for andre .NET sprog som f.eks. C#. Det vil nemlig kræve CLI
>>> specifikationen understøtter multiple arv.
>>
>> Og hvad kan man så bruge det til? Det samme som en native DLL?
>
> Det er meget analogt til DLL'er:
> Man kan bruge al det C++ inde i DLL'et man har lyst til, men hvis man vil
> stille det til rådighed for andre, uafhængig af compiler og compiler version
> skal man brug et C eller COM interface.

Og hvor er så lige fordelen ved at bruge .NET compileren, det er så vidt
jeg kan se præcis det samme som hvis man brugte tidligere versioner
af MSVC++.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Og hvor er så lige fordelen ved at bruge .NET compileren, det er så vidt
> jeg kan se præcis det samme som hvis man brugte tidligere versioner
> af MSVC++.

Se det er et godt spørgsmål.

VC++.NET uden /clr er bare en opgradering af VC++6 (glimrende
opdatering hvis du spørger mig).

VC++.NET med /clr er en underlig fisk. Hvis man ikke bruger
..NET features så er der ligesom ikke nogen fordele. Hvis man
bruger .NET features så er det ikke rigtig C++ længere. Og jeg
har meget svært ved at se hvorfor man ikke lige så godt kunne bruge
C# hvis man vil udnytte .NET fuldtud. Det burde ikke være
svært at lære C++ programmører C#. Og det de vil mangle i
sproget må være ret beskedent.

Teknisk set mener jeg at VC++.NET med /clr er et
software enginersk mester stykke. Jeg er ret sikker
på at det at få C++ og .NET til at hænge sammen på den
måde gør det til langt den mest avancerede C++
compiler nogensinde. Men jeg kan bare ikke rigtigt
se noget stort behov for den.

Arne

---

Den Sat, 03 Jun 2006 11:51:08 -0400 skrev Arne Vajhøj:
> Kent Friis wrote:
>> Og hvor er så lige fordelen ved at bruge .NET compileren, det er så vidt
>> jeg kan se præcis det samme som hvis man brugte tidligere versioner
>> af MSVC++.
>
> Se det er et godt spørgsmål.
>
> VC++.NET uden /clr er bare en opgradering af VC++6 (glimrende
> opdatering hvis du spørger mig).

Det kræver (hvis jeg har opfattet kritikken af VC++6 rigtigt) heller
ikke så meget.

> VC++.NET med /clr er en underlig fisk. Hvis man ikke bruger
> .NET features så er der ligesom ikke nogen fordele.

Altså ulemperne fra begge dele... Virker kun hos dem der har frameworket
installeret, men kræver alligevel at programmøren gør det på den
besværlige måde.

> Hvis man
> bruger .NET features så er det ikke rigtig C++ længere. Og jeg
> har meget svært ved at se hvorfor man ikke lige så godt kunne bruge
> C# hvis man vil udnytte .NET fuldtud. Det burde ikke være
> svært at lære C++ programmører C#. Og det de vil mangle i
> sproget må være ret beskedent.

Det var sådanset også det jeg konkluderede da jeg legede med C++.NET
- der er alligevel så mange ændringer (jeg nægter at kalde mangler
for "udvidelser") i forhold til standard C++, at C# er lige så nemt
at gå til, og samtidig er C# en "helhed", hvor C++.NET er sådan
lidt halvt det ene, halvt det andet.

> Teknisk set mener jeg at VC++.NET med /clr er et
> software enginersk mester stykke. Jeg er ret sikker
> på at det at få C++ og .NET til at hænge sammen på den
> måde gør det til langt den mest avancerede C++
> compiler nogensinde. Men jeg kan bare ikke rigtigt
> se noget stort behov for den.

Var der ikke noget med en GCC-backend der target'er JRE? Det må da
være noget i samme stil.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Var der ikke noget med en GCC-backend der target'er JRE? Det må da
> være noget i samme stil.

gcj kan så vidt jeg ved kun konvertere Java source
til Java byte code (svarende til MSIL) og Java source
til native executable. Jeg har ihvertfald aldrig hørt om
at den kunne konvertere f.eks. C++ til Java byte code.

Arne

---

Den Sat, 03 Jun 2006 18:53:48 -0400 skrev Arne Vajhøj:
> Kent Friis wrote:
>> Var der ikke noget med en GCC-backend der target'er JRE? Det må da
>> være noget i samme stil.
>
> gcj kan så vidt jeg ved kun konvertere Java source
> til Java byte code (svarende til MSIL) og Java source
> til native executable. Jeg har ihvertfald aldrig hørt om
> at den kunne konvertere f.eks. C++ til Java byte code.

gcj er frontend'en, den jeg tænker på skal være en backend til
g++, der compiler til JRE i stedet for Intel / Alpha / PPC osv.
Men det er flere år siden jeg har hørt om den, så det er da muligt
at den aldrig nåede længere end tegnebrættet.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Sat, 03 Jun 2006 18:53:48 -0400 skrev Arne Vajhøj:
>> gcj kan så vidt jeg ved kun konvertere Java source
>> til Java byte code (svarende til MSIL) og Java source
>> til native executable. Jeg har ihvertfald aldrig hørt om
>> at den kunne konvertere f.eks. C++ til Java byte code.
>
> gcj er frontend'en, den jeg tænker på skal være en backend til
> g++, der compiler til JRE i stedet for Intel / Alpha / PPC osv.
> Men det er flere år siden jeg har hørt om den, så det er da muligt
> at den aldrig nåede længere end tegnebrættet.

Jeg har aldrig hørt om det. Men der er meget jeg ikke har hørt
om, så det skal man ikke udlede så meget af.

Google finder http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html
som antyder at der er politisk modvilje i FSF mod java
byte code, men at der faktisk var et initiativ i den
retning.

Måske strandede projektet p.g.a. dette.

Det vil helt klart være teknisk muligt. JGnat
kan compile det samme Ada kode til Java byte code
som almindelig Gnat kan compile til native (og MGnat
kan compile til MSIL).

Og andre projekter såsom IKVM der kan køre Java byte
code i .NET runtime og MainSoft's produkter til at
køre .NET kode i en J2EE application server.

Men det er stadig nemmere end hvad MS har laver. Hvis
de skulle have nøjes med at lave det samme så ville
compileren med /clr acceptere hverken mindre eller mere
syntax mæssigt end uden /clr.

At nogen så måske ville have foretrukket den løsning er
en anden sag.

Arne

---

Den Sat, 03 Jun 2006 19:56:42 -0400 skrev Arne Vajhøj:
> Kent Friis wrote:
>> Den Sat, 03 Jun 2006 18:53:48 -0400 skrev Arne Vajhøj:
>>> gcj kan så vidt jeg ved kun konvertere Java source
>>> til Java byte code (svarende til MSIL) og Java source
>>> til native executable. Jeg har ihvertfald aldrig hørt om
>>> at den kunne konvertere f.eks. C++ til Java byte code.
>>
>> gcj er frontend'en, den jeg tænker på skal være en backend til
>> g++, der compiler til JRE i stedet for Intel / Alpha / PPC osv.
>> Men det er flere år siden jeg har hørt om den, så det er da muligt
>> at den aldrig nåede længere end tegnebrættet.
>
> Jeg har aldrig hørt om det. Men der er meget jeg ikke har hørt
> om, så det skal man ikke udlede så meget af.
>
> Google finder http://gcc.gnu.org/ml/gcc/2001-02/msg00895.html

Nice, jeg havde ingen held med google.

> som antyder at der er politisk modvilje i FSF mod java
> byte code, men at der faktisk var et initiativ i den
> retning.
>
> Måske strandede projektet p.g.a. dette.

Det kunne godt tyde på det, som jeg læser det, er Java-backend'en
blevet implementeret *to* gange, så når der ikke er nogen der har
hørt om den, kan det ikke være af tekniske årsager.

Den kunne ellers have fjernet en af de store ulemper ved JRE - at
man er tvunget til et bestemt sprog, uanset om man kan li' det eller
ej. I stedet blev det så .NET der løste det problem.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den kunne ellers have fjernet en af de store ulemper ved JRE - at
> man er tvunget til et bestemt sprog, uanset om man kan li' det eller
> ej. I stedet blev det så .NET der løste det problem.

At Java byte code er et bestemt sprog er en sandhed ligesom
at C# er til et bestemt styre system.

95% sand.

Andre sprog kan generere Java byte code. Det er bare ikke
specielt udbredt.

De to mest udbredte (blandt de lidt udbredte) er:
* JGnat - en Ada compiler
* Jython - en Python intepreter *og* compiler

Arne

---

"Kent Friis" <nospam@nospam.invalid> wrote in message
news:4481467e$0$15788$14726298@news.sunsite.dk...

[8<8<8<]
> Og hvor er så lige fordelen ved at bruge .NET compileren, det er så vidt
> jeg kan se præcis det samme som hvis man brugte tidligere versioner
> af MSVC++.

Fordelen ved at bruge C++/CLI compileren, med integrationen mellem .NET og
C++, er rimelig indlysende hvis man f.eks. har noget "business logic"
skrevet i ISO C++ og ønsker at anvende det fra en applikation der anvender
..NET. f.eks. hvis man vil lægge en APS.NET front-end på sin "business
logic".

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
> "Kent Friis" <nospam@nospam.invalid> wrote in message
> news:4481467e$0$15788$14726298@news.sunsite.dk...
>> Og hvor er så lige fordelen ved at bruge .NET compileren, det er så vidt
>> jeg kan se præcis det samme som hvis man brugte tidligere versioner
>> af MSVC++.
>
> Fordelen ved at bruge C++/CLI compileren, med integrationen mellem .NET og
> C++, er rimelig indlysende hvis man f.eks. har noget "business logic"
> skrevet i ISO C++ og ønsker at anvende det fra en applikation der anvender
> .NET. f.eks. hvis man vil lægge en APS.NET front-end på sin "business
> logic".

Det er jo en mulighed.

Men der er også andre løsninger på det problem.

DllImport, COM etc..

Arne

---

"Tomas Skott" <skott@fjernmig.festudvalget.dk> wrote in message
news:11491975130.676234378223164@dtext.news.tele.dk...

[8<8<8<]
> Vil I ligefremt fraråde Visual C++ (Ved godt, det "kun" er
> brugerfladen, Microsoft står bag), min begrundelse for at vælge
> det produkt var, at eleverne lettere vil få et kick ud af
> programmering.

Det er udemærket at bruge Visual C++.
Man kan gratis downloade en "lille" version: Microsoft Visual C++ Express.
Den er bestemt rigtig god - men måske er den lidt stor.
Bemærk at til bogen "You can do it" følger der en CD-ROM med compiler og
udviklingsmiljø med. Hvis man bruger den bog er det nok en god ide at holde
sig til det udviklingsmiljø i første omgang, da det er omhyggeligt beskrevet
hvordan man bruger det.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen <mogens_h@dk-online.dk> skrev:
>
>"Tomas Skott"
><skott@fjernmig.festudvalget.dk> wrote in message
>news:11491975130.676234378223164@dtext
>.news.tele.dk...
>
>[8<8<8<]
>> Vil I ligefremt fraråde Visual C++
>>(Ved godt, det "kun" er
>> brugerfladen, Microsoft står bag),
>>min begrundelse for at vælge
>> det produkt var, at eleverne lettere
>>vil få et kick ud af
>> programmering.
>
>Det er udemærket at bruge Visual C++.
>Man kan gratis downloade en "lille"
>version: Microsoft Visual C++ Express.
>Den er bestemt rigtig god - men måske
>er den lidt stor.
>Bemærk at til bogen "You can do it"
>følger der en CD-ROM med compiler og
>udviklingsmiljø med. Hvis man bruger
>den bog er det nok en god ide at holde
>sig til det udviklingsmiljø i første
>omgang, da det er omhyggeligt beskrevet
>hvordan man bruger det.
>
Mit argument for at anvende et Visuelt programmeringssprog er,
at forberede dem på et kommende universitetsstudie, hvor det
hyppigt bruges. Vælger de ingeniørvejen hedder det mest Visual
C++ eller Borland Builder, og her er VC den billigste.

Jeg vil dog prøve at finde bogen, du omtaler. Er det en fri
compiler med en god editor, er det jo værd at tage med også.
Jeg underviser også i teknikfag. Her benytter jeg CodeVision som
compiler til AVR's uC'ere. Det er min ide, at de elever, der har
valgt programmering og "mit" teknikfag skal kunne kombinere
Programmering og Teknikfag bedst muligt.


--
Med venlig hilsen

Tomas Skott

---

Tomas Skott skrev:

> Mit argument for at anvende et Visuelt programmeringssprog er,
> at forberede dem på et kommende universitetsstudie, hvor det
> hyppigt bruges. Vælger de ingeniørvejen hedder det mest Visual
> C++ eller Borland Builder, og her er VC den billigste.

Visual C++ er ikke en skid visuelt. Det er kun et salgsnavn som
Microsoft følte sig tvunget til at bruge efter at Visual Basic
(som *er* grafisk baseret) havde haft succes.

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

---

Bertel Lund Hansen wrote:
> Tomas Skott skrev:
>> Mit argument for at anvende et Visuelt programmeringssprog er,
>> at forberede dem på et kommende universitetsstudie, hvor det
>> hyppigt bruges. Vælger de ingeniørvejen hedder det mest Visual
>> C++ eller Borland Builder, og her er VC den billigste.
>
> Visual C++ er ikke en skid visuelt. Det er kun et salgsnavn som
> Microsoft følte sig tvunget til at bruge efter at Visual Basic
> (som *er* grafisk baseret) havde haft succes.

VC++.NET i .NET mode har faktisk drop and drag
GUI builder.

Arne

---

"Tomas Skott" <skott@fjernmig.festudvalget.dk> wrote in message
news:11492427790.868696483665222@dtext.news.tele.dk...

> Mit argument for at anvende et Visuelt programmeringssprog er,

Et Visuelt programmeringssprog ?

Ordet "Visual" er blot Microsoft produkt navn for integrede udviklings
miljøer
(IDE), f.eks.
Visual Basic
Visual C#
Visual C++
hvor man ofte har adgang til en grafisk GUI builder.
Tilsvarende kalder Borland en del af deres produkter for "Builder" (Delphi
er undtagelsen), f.eks.
JBuilder
C#Builder
C++Builder

Visual Basic var vist eet af de første værktøjer der havde den grafiske GUI
builder til MS-Windows.
Hvis man kigger historisk på det var der 2 problemer navnet "Visual C++":
1. Det var ikke visuelt (som man kendte fra Visual Basic)
2. Det var ikke C++ (som man kendte fra ARM)
Det var først fra og med Visual Studio .NET 2003 at navnet "Visual C++" var
rimeligt retvisende.

Hvis vi snakker undervisning i ISO C++ er der ikke meget visuelt over det -
altså man sidder ikke og designer GUI med en GUI builder.
Pratisk taget alle IDE'er har integeret editor, debugger og build-miljø.

> at forberede dem på et kommende universitetsstudie, hvor det
> hyppigt bruges. Vælger de ingeniørvejen hedder det mest Visual
> C++ eller Borland Builder, og her er VC den billigste.

Det kan jeg godt forstå. Det er også den bedste implementering af C++ og den
med udbredte.

Venlig hilsen

Mogens Hansen

---

Tomas Skott <skott@fjernmig.festudvalget.dk> writes:

> Mogens Hansen <mogens_h@dk-online.dk> skrev:
-snip-
> Mit argument for at anvende et Visuelt programmeringssprog er,
> at forberede dem på et kommende universitetsstudie, hvor det
> hyppigt bruges. Vælger de ingeniørvejen hedder det mest Visual
> C++ eller Borland Builder, og her er VC den billigste.

Vi kan downloade en hel masse Microsoft-programmer fuldstændigt gratis,
kvit og frit, som en del af deres licensaftale... Det vi bruger til
programmering er nok hovedsageligt microsoft visual studio 2005 i øjeblikket...


Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Tomas Skott wrote:
> Mit argument for at anvende et Visuelt programmeringssprog er,
> at forberede dem på et kommende universitetsstudie, hvor det
> hyppigt bruges. Vælger de ingeniørvejen hedder det mest Visual
> C++ eller Borland Builder, og her er VC den billigste.

Hvis de skal universitets uddannes indenfor IT, så
vil deres kommende arbejdsgivere nok have en forventning
om at de kan bruge enhver IDE.

Arne

---

On 2006-06-02, Tomas Skott <skott@fjernmig.festudvalget.dk> wrote:
> Mit argument for at anvende et Visuelt programmeringssprog er,
> at forberede dem på et kommende universitetsstudie, hvor det
> hyppigt bruges. Vælger de ingeniørvejen hedder det mest Visual
> C++ eller Borland Builder, og her er VC den billigste.

På datalogisk institut ved Københavns Universitet bliver der ikke brugt
Visual noget som helst i særlig udpræget grad.

--
Med venlig hilsen
- Jacob Atzen

---

On 02 Jun 2006 10:02:04 GMT
Tomas Skott <skott@fjernmig.festudvalget.dk> wrote:
> Mit argument for at anvende et Visuelt programmeringssprog er,
> at forberede dem på et kommende universitetsstudie, hvor det
> hyppigt bruges. Vælger de ingeniørvejen hedder det mest Visual
> C++ eller Borland Builder, og her er VC den billigste.


hvilket ingeniør studie er det lige du taler om? Jeg har været på
software ingeniør studiet på både DTU og AAU og ingen af de steder er
der blevet benytte nogen form for "Visual" C++ miljø i undervisningen -
faktisk foregik alt primært med g++ og emacs. Generelt så bliver man
ikke undervist i IDE'er men i at programmere - det er det som det hele
går ud på husker du nok.
C++ havde en meget lille plads i undervisningen generelt på det studie
jeg har været igennem hvorimod Java og C# (og SML) har vundet meget
større indpas.
Vi lavede et stort projekt hvor vi (frivilligt) brugte MS Visual C++ og
sjældent har jeg været så irriteret på et IDE. Den antager brugeren er
dum, har en elendig debugger (giver f.eks. fejl beskeder på tomme
linjer), forsøger at snige MFC/.NET ind konstant og så har den de
frygtelige DEBUG og RELEASE mode (man burde aldrig bruge DEBUG).

Jeg rører aldrig ved MS VC++ igen hvis jeg kan slippe (og er sikker
på at de 6 andre i min gruppe er enige)- det er simpelthen spild af min tid.
BloodShed Dev-C++ (http://www.bloodshed.net/devcpp.html) ville jeg
anbefale til din undervisning. Den er gratis, god og overlader
programmeringen til eleven - så lærer han det og kan det også næste
gang.


MVH
Kim Schulz

---

Kim Schulz <kim@schulz.dk> writes:

> On 02 Jun 2006 10:02:04 GMT
> Tomas Skott <skott@fjernmig.festudvalget.dk> wrote:
-snip-
> hvilket ingeniør studie er det lige du taler om? Jeg har været på
> software ingeniør studiet på både DTU og AAU og ingen af de steder er
> der blevet benytte nogen form for "Visual" C++ miljø i undervisningen -
> faktisk foregik alt primært med g++ og emacs. Generelt så bliver man

Det er kun i unix-databarerne. Men de har også windows-databarer på dtu
og jeg mener at de tidligere har kørt visual c++ som du snakker om.

> ikke undervist i IDE'er men i at programmere - det er det som det hele
> går ud på husker du nok.
> C++ havde en meget lille plads i undervisningen generelt på det studie
> jeg har været igennem hvorimod Java og C# (og SML) har vundet meget
> større indpas.
> Vi lavede et stort projekt hvor vi (frivilligt) brugte MS Visual C++ og
> sjældent har jeg været så irriteret på et IDE. Den antager brugeren er
> dum, har en elendig debugger (giver f.eks. fejl beskeder på tomme
> linjer), forsøger at snige MFC/.NET ind konstant og så har den de
> frygtelige DEBUG og RELEASE mode (man burde aldrig bruge DEBUG).

Jeg har et program på ca. 150 kb... Og release er *UFATTELIGT* langsom
om at snøvle sig igennem programmet. Derfor bruger jeg konstant debug
men kun i kombination med at jeg nu har fundet ud af at få gcc til at
smide den ene advarsel i hovedet på mig efter den anden...

> Jeg rører aldrig ved MS VC++ igen hvis jeg kan slippe (og er sikker
> på at de 6 andre i min gruppe er enige)- det er simpelthen spild af min tid.

gcc er superb god, men nok mere beregnet til unix/linux-folk (findes den
overhovedet til windows, bortset fra til cygwin?)...

Jeg er fuldstændigt imponeret over hvor mange gode advarsler gcc kan
komme med på måske det kvarte af det stykke tid som "Release" laver det
på i visual studio 2005.... Læg dertil at visual studio 2005, ikke
fanger mere end højst 1/5 af det gcc fanger med det warning-level jeg
kører med nu. Men jeg syntes visual studio 2005 har en god
debugger med en fantastisk "mouse hovering" ting, som jeg ikke kan
undvære...


Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Martin Jørgensen wrote:
> gcc er superb god, men nok mere beregnet til unix/linux-folk (findes den
> overhovedet til windows, bortset fra til cygwin?)...

Ja.

Mingw. Som også bruges af diverse IDE'er.

Arne

---

---

On Fri, 02 Jun 2006 20:57:53 -0400
Arne Vajhøj <arne@vajhoej.dk> wrote:

> Kim Schulz wrote:

> Der er mange som har beklaget sig over C++ standardens
> overholdelse i VC++ i versioner før 13.0/7.0/2002.

Ja men det kan jeg leve med da MS's dokumentation er rimelig. Det jeg
ikke kan leve med er at de for at bruge selv simple ting krævede at man
brugte Managed/MFC.

> Men VC++ er nok den mest anvendte C++ IDE og jeg kender
> mange erfarne C++ programmører som mener at
> VC++ IDE og specielt debuggeren er *den* bedste.

Det er så nok dem der ikke har prøvet alternative debuggere. Jeg følte
at MS gjorde grin med mig da jeg brugte debuggeren i VC++/VS.NET - den
gav simpelthen forkerte info tilbage ofte.
> Jeg vil tro, at I har haft for lidt tid til at lære
> værktøjet at kende.

Tjaa jeg arbejde med det 5-8 timer dagligt i et år - hvis man ikke
kender et IDE efter den tid, ja så ved jeg ikke.

Noget jeg specielt fandt skræmmende var den måde at DEBUG mode gav
typerne mere plads i hukommelsen end de skulle bruge. Vi havde et par
stykker med i gruppen som ikke var erfarne med C/C++ og når man kørte i
DEBUG mode, så fangede den simpelthen ikke når de fik overskrevet for
meget i hukommelsen - det virkede jo. I RELEASE så virkede programmet
selvfølgelig ikke og folk kunne så gå igen med den store omgang
debugging ved gættemetoden - I DEBUG mode virkede det jo som sagt.
smart smart - NOT!

---

Kim Schulz <kim@schulz.dk> writes:

> On Fri, 02 Jun 2006 20:57:53 -0400
> Arne Vajhøj <arne@vajhoej.dk> wrote:
-snip-
>> Men VC++ er nok den mest anvendte C++ IDE og jeg kender
>> mange erfarne C++ programmører som mener at
>> VC++ IDE og specielt debuggeren er *den* bedste.

Jeg går udfra at den nogenlunde er ligesom visual studio 2005 og i så
fald giver jeg dig helt ret... Det er også den eneste grund til at jeg
hovedsageligt sidder med visual studio 2005. Super debugger...

> Det er så nok dem der ikke har prøvet alternative debuggere. Jeg følte
> at MS gjorde grin med mig da jeg brugte debuggeren i VC++/VS.NET - den
> gav simpelthen forkerte info tilbage ofte.

Eeerhm.... LOL... Jeg har netop haft tilsvarende problemer..... Men jeg
nægter at tro at det er debuggeren der er problemet - i må have lavet
fejl i koden. F.eks. har jeg bandet meget over at jeg havde en:

for(noget=0 ; noget<noget_andet; noget++);
{
noget_tredje();
noget_fjerde... osv.
}

Debuggeren viste noget komplet forkert og jeg fattede ikke hvad der var
galt fordi compileren er så skod-agtig at selv på warning level 4 (som
jeg tror er det højeste???) så var der ingen advarsler...

>> Jeg vil tro, at I har haft for lidt tid til at lære
>> værktøjet at kende.

Helt enig.

> Tjaa jeg arbejde med det 5-8 timer dagligt i et år - hvis man ikke
> kender et IDE efter den tid, ja så ved jeg ikke.

Prøv at compile koden på en anden compiler engang imellem. Og prøv at
skifte mellem "Release" og "Debug"-mode. Jeg kan ikke forestille mig at
den skulle vise noget forkert, uden at i havde begået nogen fejl.

Hvis du har koden liggende fra dengang, så post et link til den. Så skal
vi finde fejlen (forhåbentligt).

> Noget jeg specielt fandt skræmmende var den måde at DEBUG mode gav
> typerne mere plads i hukommelsen end de skulle bruge. Vi havde et par
> stykker med i gruppen som ikke var erfarne med C/C++ og når man kørte i
> DEBUG mode, så fangede den simpelthen ikke når de fik overskrevet for
> meget i hukommelsen - det virkede jo. I RELEASE så virkede programmet
> selvfølgelig ikke og folk kunne så gå igen med den store omgang
> debugging ved gættemetoden - I DEBUG mode virkede det jo som sagt.
> smart smart - NOT!

Ja, "Debug" er super-hurtig. Jeg plejer at køre med den stort set hele
tiden. Og den fanger stort set ingen fejl - enig. Derfor at jeg skriver
det med at du skal skifte lidt og kompilere med forskellige
værktøjer. Det vil jeg ihvertfald huske at gøre fremover. Og der er det
så at gcc er super-god... Den fanger virkeligt meget dårlig kode og det
bliver man jo kun bedre af at rette...


Best regards
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

---

On Sat, 03 Jun 2006 12:10:39 -0400
Arne Vajhøj <arne@vajhoej.dk> wrote:

> Det er ret normalt at være nødt til at gå ud over
> ISO C++ for at lave et realistisk program.
>
> Men det er da det samme for alle compilere.
>
> Win32 API, MFC, .NET, VCL, wxWidgets, Qt, whatever.
> Principielt er der ingen forskel.
>

Bare ikke fedt når det bagefter skal være porterbar til flere
platforme.
> > følte at MS gjorde grin med mig da jeg brugte debuggeren i
> > VC++/VS.NET - den gav simpelthen forkerte info tilbage ofte.
>
> Er det "fejl beskeder på tomme linjer" du snakker om ? Er du
> sikker på at I ikke har debugget optimized kode ?

Ja det er jeg helt sikker på at vi ikke gjorde. Der var også mange
andre fejl som f.eks. at værdien af variabler ikke blev opdateret i
debuggeren og lignende.

[snip]
> Meget stort projekt ! (1 års kodning må vel betyde at projektet
> har taget ca. 4 år ialt)
Ja det var et rimeligt stort projekt, men nej ikke 4 år i alt, for der
var andre som stod for f.eks. design af systemet og test af systemet.

> 1) Det er absolut ikke specielt for VC++ at programmer oversat med
> debug og programmer oversat uden opfører sig forskelligt. Det er
> meget normalt.
> 2) Selv i release mode kan der sagtens blive sat fillers ind af
> hensyn til normal data alignment eller page alignment af sektioner.

Da vores var system havde meget begrænset med hukommelse, så var det
afgørende af der ikke var fillers i den endelige kode.

> 3) Det er (desværre !) langt fra altid tilfældet at den slags
> overskrivninger giver en umiddelbar runtime fejl i release mode.
> 4) Og brug af debuggeren til at finde den type fejl vil i de
> fleste tilfælde være langsommere end code review og
> assertions.

Det blev også den løsning vi måtte bruge.

---

---

On Sun, 04 Jun 2006 09:23:30 +0200, Mogens Hansen wrote:

>
> Jeg kan varmt anbefale at tage et kig på dynamiske analysatorer som
> Borland CodeGuard, IBM Purify og Compuware BoundsChecker. Eventuelt
> suppleret med statisk analysatorer som PC Lint.
>
Hvad med valgrind-pakken? (http://www.valgrind.org/info/tools.html) Den er
GPL. (http://www.valgrind.org/)

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

"Michael Rasmussen" <mir@miras.org> wrote in message
news:pan.2006.06.04.08.42.49.54000@miras.org...
> On Sun, 04 Jun 2006 09:23:30 +0200, Mogens Hansen wrote:
>
>>
>> Jeg kan varmt anbefale at tage et kig på dynamiske analysatorer som
>> Borland CodeGuard, IBM Purify og Compuware BoundsChecker. Eventuelt
>> suppleret med statisk analysatorer som PC Lint.
>>
> Hvad med valgrind-pakken? (http://www.valgrind.org/info/tools.html) Den er
> GPL. (http://www.valgrind.org/)

Tak - jeg sad og tænkte på den, men kunne ikke huske navnet

Venlig hilsen

Mogens Hansen

---

On Sat, 3 Jun 2006 20:33:17 +0200
"Mogens Hansen" <mogens_h@dk-online.dk> wrote:

> Hvorfor skal man gætte ?
> Debuggeren virker da fortsat udemærket.
> Det kan være vanskelligere, fordi programflowet ikke nødvendigvis
> fuldstændig følger source-koden pga. optimeringer.

Fordi den ikke fejlede i DEBUG mode, men kun i RELEASE mode (pga.
føromtalte fillers).

---

Tomas Skott <skott@fjernmig.festudvalget.dk> writes:

> Mit argument for at anvende et Visuelt programmeringssprog er,
> at forberede dem på et kommende universitetsstudie, hvor det
> hyppigt bruges. Vælger de ingeniørvejen hedder det mest Visual
> C++ eller Borland Builder, og her er VC den billigste.

Det er da vist en sandhed med modifikationer. Jeg er nyuddannet
civilingeniør fra DTU med en fagprofil der hedder "Informatik" fra
2005. Jeg har aldrig brugt Microsoft Visual C++ eller Borland Builder
i forbindelse med mit studie.

Jeg har til gengæld brugt gcc til at oversætte både C og C++ kode jeg
har skrevet i forbindelse med opgaver. Jeg kunne sikkert lige så godt
have brugt en anden compiler, hvis jeg havde haft lyst til det,
værktøjet til at løse opgaven var ikke det væsentlige. Det var
allerførst i studiet at man underviste en lille smule i specifikke
programmeringssprog. Dengang var det for mit vedkommende ML og Java.

Jeg ved at et par af mine venner der har læst på Maskin-retningen har
lært C og at et par af mine venner der har læst på Kemi-retningen har
lært Pascal, men jeg er ikke klar over hvilke værktøjer de har brugt i
den forbindelse.

Jeg bruger i øvrigt stadig hverken Visual C++ eller Borland Builder
selv om jeg nu er havnet i det private erhvervsliv. Den smule C jeg
skriver i ny og næ bliver oversat med gcc, da den normalt er lige ved
hånden, og mine programmer normalt kører på en eller anden form for
Unix.

--
Jacob - www.bunk.cc
You would if you could but you can't so you won't.

---

Kent Friis <nospam@nospam.invalid> writes:

> gcj er frontend'en, den jeg tænker på skal være en backend til
> g++, der compiler til JRE i stedet for Intel / Alpha / PPC osv.
> Men det er flere år siden jeg har hørt om den, så det er da muligt
> at den aldrig nåede længere end tegnebrættet.

Jeg mindes svagt en sådan, men det var kun en proff-of-concept. Den
havde, så vidt jeg husker, en kæmpestor statisk JVM array kaldet
"memory" som så indeholdt alle data i programmet. Pointere blev så
til index'er i det array, så man kunne lave C pointer gymnastik.