---

Hej ...

Jeg har nu igennem hele min læretid som elektronikfagtekniker udviklet
software til embedded løsninger i både C og assembler og har store planer om
at søge ind på NOEA til august som elektronik teknolog jeg er vild med
hardware (mere digital end analog ihvertfald) især når den kombineres med
software jeg har kigget lidt rundt på nettet men ikke rigtigt funden det jeg
søger ...

Findes der nogle uddannelser her i landet, der er programmerings orienteret
inden for embedded verden ? her tænker jeg meget på C jeg er ikke så
interesseret i alt sådan noget windows programmerings "fis" selvfølgelig er
C det samme men vil egentligt helst undgå objekt orienteret programmering da
det er embedded elektronik jeg interessere mig for og ønsker at arbejde med
frem for PC platforme osv.man lærer selvfølgelig nye programmerings "tricks"
i C hele tiden og bliver bedre og bedre men jeg syntes at jeg mangler noget
bevis på kompetancen altså noget papir af en art ... det hjælper jo ikke at
man selv syntes man er en mester hvis man bliver sorteret fra i bunken over
CV'er fordi man ikke har noget papir på ens kunnen bortset fra udtalelser
osv... og man kan vel altid lære noget nyt

M.v.h.
Lasse Madsen

---

> Findes der nogle uddannelser her i landet, der er programmerings
orienteret
> inden for embedded verden ? her tænker jeg meget på C jeg er ikke så
> interesseret i alt sådan noget windows programmerings "fis" selvfølgelig
er
> C det samme men vil egentligt helst undgå objekt orienteret programmering
da
> det er embedded elektronik jeg interessere mig for og ønsker at arbejde
med
> frem for PC platforme osv.man lærer selvfølgelig nye programmerings
"tricks"
> i C hele tiden og bliver bedre og bedre men jeg syntes at jeg mangler
noget
> bevis på kompetancen altså noget papir af en art ... det hjælper jo ikke
at
> man selv syntes man er en mester hvis man bliver sorteret fra i bunken
over
> CV'er fordi man ikke har noget papir på ens kunnen bortset fra udtalelser
> osv... og man kan vel altid lære noget nyt

Jeg ved ikke helt hvad du søger, men måske Hardware Programmør? Man bliver
vist noget IT-diplominginør-nørd eller noget i den retning. Regner selv med
at tage det efter datamatiker.
Anyway, uddanelsen går så vidt jeg har læst mig til ud på at programmere i
hardware, dvs. løse problemer som man normalt løser på en PC direkte i
hardwaren.

Kunne måske være det du søgte.

---

"Lasse Madsen" <Lasse.madsen@elektronik.dk> skrev...
> Findes der nogle uddannelser her i landet, der er programmerings
orienteret
> inden for embedded verden ?

Muligvis Datateknologi?? De laver mange hardware-orienterede ting, og
du vælger selv hvor du "ligger trykket"...

Kast evt. et blik på:
http://www.mip.sdu.dk/education/Datateknologibrochure/datateknologi.html


--
Michael Banzon
http://michael.banzon.dk/
http://southbound.dk/

---

Michael Banzon wrote:

> Muligvis Datateknologi?? De laver mange hardware-orienterede ting, og
> du vælger selv hvor du "ligger trykket"...
>
> Kast evt. et blik på:
> http://www.mip.sdu.dk/education/Datateknologibrochure/datateknologi.html

Ved datateknologi bliver man slæbt igennem tonsvis af fag der ikke direkte
har noget med programmering eller elektronik at gøre, f.eks. en masse
fysik, datalogi og matematik-fag. Netop af samme grund, springer mange fra
dat.tek, og bliver data- eller svagstrøms-ingeniører istedet.
Til gengæld har man en masse generel viden om alle mulige og umulige ting,
som computere og software kan bruges til bagefter.

/Rune - civiling. i datateknologi

---

> Ved datateknologi bliver man slæbt igennem tonsvis af fag der ikke
> direkte har noget med programmering eller elektronik at gøre, f.eks.
> en masse fysik, datalogi og matematik-fag.
DET er ihvertfald rigtigt. Det er meget teoretisk. Godt for nogle...Men for
andre BVADRR

> Netop af samme grund,
> springer mange fra dat.tek, og bliver data- eller
> svagstrøms-ingeniører istedet.
Jep. Jeg gjorde...

Måske vores spørger skulle undersøge en E-retning på et teknikum. Der er
programmering både (lidt) C og mere assambler. Det er desuden meget bredt,
man starter sammen, og senere deles man ud i svagstrøms/data og stærkstrøms
ingeniør

Frederik

---

Rune Larsen wrote:
> Michael Banzon wrote:
>
>
>>Muligvis Datateknologi?? De laver mange hardware-orienterede ting, og
>>du vælger selv hvor du "ligger trykket"...
>>
>>Kast evt. et blik på:
>>http://www.mip.sdu.dk/education/Datateknologibrochure/datateknologi.html
>
>
> Ved datateknologi bliver man slæbt igennem tonsvis af fag der ikke direkte
> har noget med programmering eller elektronik at gøre, f.eks. en masse
> fysik, datalogi og matematik-fag. Netop af samme grund, springer mange fra
> dat.tek, og bliver data- eller svagstrøms-ingeniører istedet.
> Til gengæld har man en masse generel viden om alle mulige og umulige ting,
> som computere og software kan bruges til bagefter.
>
> /Rune - civiling. i datateknologi

Det kan jeg kun bekræfte.. Fysik og matematik føler man ikke man har en
skid at bruge til i starten, men allerede nu (3. semester) er man
faktisk glad for at man har haft den matematik, og når der kommer mere
avanceret teori senere får man også brug for det.
Det siges at man ikke rigtig kan noget som datateknolog (og det tror jeg
gerne), men at man bliver expert i at sætte sig ind i ting meget hurtigt
og på den måde ikke behøver den store erfaring for at løse et stort
problem :)


Mvh / Preben Holm - stud. polyt. i datateknologi

---

"Lasse Madsen" <Lasse.madsen@elektronik.dk> wrote in message
news:btpeal$qoq$1@news.cybercity.dk...
> Findes der nogle uddannelser her i landet, der er programmerings
orienteret
> inden for embedded verden ?

Jeg ved af erfaring at det er der hvis du læser til IT-diplomingeniør på
DTU. Du undgår ikke helt "almindelig" programmering, men du får i hvert fald
det du beder om.

Du kan læse mere om uddannelsen her:
http://www.imm.dtu.dk/cet/Uddannelse/Index.html

Yderligere er det også muligt at specialisere sig i f.eks. digitalt design,
læs mere om dette her:
http://www.adm.dtu.dk/studieinformation/studinfo/retninger/dipit_d.htm

Mvh. Jacob

---

In article <btpeal$qoq$1@news.cybercity.dk>, Lasse.madsen@elektronik.dk
says...

> Findes der nogle uddannelser her i landet, der er programmerings orienteret
> inden for embedded verden ? her tænker jeg meget på C jeg er ikke så

Dataingeniør ved Syddansk Universitet.


--
Med venlig hilsen/best regards
Jesper G. Poulsen

http://www.netmeister.org/news/learn2quote2.html

---

"Lasse Madsen" <Lasse.madsen@elektronik.dk> wrote:

[8<8<8<]
> Findes der nogle uddannelser her i landet, der er programmerings
orienteret
> inden for embedded verden ?

De fleste elektroingeniør uddannelser vil formodentlig kunne tilbude noget
sådant.

Så vidt jeg husker har (havde) Ingeniør Højskolen i Århus og Århus
Universitet et samarbejde om at uddanne dataloger (cand. scient.), specielt
med henblik på den embeddede verden, som så spændende og fornuftigt ud.

[8<8<8<]
> ... men vil egentligt helst undgå objekt orienteret programmering da
> det er embedded elektronik jeg interessere mig ...

Hvor ser du en modsætning mellem objekt orienteret programmering og embedded
elektronik ?

Objektet orienteret programmering bliver brugt til mange embeddede systemer.


Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

>>... men vil egentligt helst undgå objekt orienteret programmering da
>>det er embedded elektronik jeg interessere mig ...
>
>
> Hvor ser du en modsætning mellem objekt orienteret programmering og embedded
> elektronik ?
>
> Objektet orienteret programmering bliver brugt til mange embeddede systemer.

Omend sprog som C og maskinkode er væsentlig mere udbredt da det ikke er
lige så resource-krævende.

---

"Rasmus Christian Kaae" <rasmusTOPHAT@3kings.dk> wrote:
> Mogens Hansen wrote:
>
> >>... men vil egentligt helst undgå objekt orienteret programmering da
> >>det er embedded elektronik jeg interessere mig ...
> >
> >
> > Hvor ser du en modsætning mellem objekt orienteret programmering og
embedded
> > elektronik ?
> >
> > Objektet orienteret programmering bliver brugt til mange embeddede
systemer.
>
> Omend sprog som C og maskinkode er væsentlig mere udbredt da det ikke er
> lige så resource-krævende.
>

Har du nogen form for troværdig opgørelse, der bakker dit udsagn op ?

Hvordan måler man udbredelse:
* Antal projekter der startes op
* Størrelsen på investeringer i projekter med de forskellige sprog
* Antal produkter solgt
eller noget andet ?

Dit udsagn stemmer langt fra med mine erfaringer - men mine erfaringer er jo
også netop kun det: een persons erfaring.

Siden 1991 har jeg i adskellige firmaer arbejdet på eller ved siden af
embeddede projekter, der har indeholdt objekt orienteret programmering i
væsentligt omfang.
Alle projekter er implementeret i C++.
Derudover har jeg kendskab til adskellige andre embeddede projekter, hvor
der anvendes objekt orienteret programmering i væsentligt omfang.
De fleste med anvendelse af C++ men også nogle stykker skrevet i Java.
Ikke siden 1991 har jeg været i nærheden af projekter, hvor væsentlige dele
af koden er blevet skrevet i assembler.
Jeg har ikke personligt set større embeddede projekter skrevet i C, men jeg
ved naturligvis at det findes.
Jeg har set 8051 processorer blive programmeret i C - jeg antager at mindre
systemer er sjældne idag, selvom de findes.

Man kan også kigge på stillings annoncer, hvor man også ofte ser at der
bliver søgt folk med erfaring i C++, Java, UML og objekt orienteret
programmering til embeddede systemer.
Se f.eks.

http://www.jobfinder.dk/shared/cv/source/cv_start.hts?nav_to=no_logon,search
,id,328474795

http://www.jobfinder.dk/shared/cv/source/cv_start.hts?nav_to=no_logon,search
,id,328474204

http://www.jobfinder.dk/shared/cv/source/cv_start.hts?nav_to=no_logon,search
,id,328474117
for nogle aktuelle eksempler.



Mener du at objekt orienteret programmering i sig selv giver mere resource
krævende programmer ?

Det kan sagtens lade sig gøre at skrive objekt orienterede programmer, som
har performance svarende til at være skrevet i C - hvis man designer med det
mål.
Ikke mindst har jeg set kombinationen af objekt orienteret programmering og
generisk programmering i C++ som værende en god måde at opnå lige så god
performance som i C, samtidig med at man hæver abstraktions niveau og
typesikkerhed væsentligt.

Venlig hilsen

Mogens Hansen

---

On Mon, 12 Jan 2004 22:24:07 +0100, Mogens Hansen wrote (subj. "Re:
Uddannelser ?!?"):

> Ikke mindst har jeg set kombinationen af objekt orienteret programmering og
> generisk programmering i C++ som værende en god måde at opnå lige så god
> performance som i C, samtidig med at man hæver abstraktions niveau og
> typesikkerhed væsentligt.

Bliver STL, Boost og den slags ting egentlig brugt i forb. med embedded
software skrevet i C++?

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin wrote:
>
> Bliver STL, Boost og den slags ting egentlig brugt i forb. med embedded
> software skrevet i C++?
Jeg tror ikke det er det sted du vil se disse libs ofte. Jeg vil desvære
mene at templates er for svære at styre (memory footprint) til en
embedded platform. Jeg har endnu ikke fundet en kompiler er optimerer
template's ordenligt endnu ( vi mangler vist C++ export ).

I tråd med det Morgens siger, er C++ ikke det store problem mht.
overhead men det er de forskellige libs man bruger tilgengæld. Hvis man
bruge et lib til embedded code tror jeg at man vil fortrække at linke
det i bund (statisk), så man ikke slæber rundt på kode (dead code) man
ikke bruger, og så man ikke har en så voldsom stor symbol tabel (C++
mangling fylder lidt).

Men, hvis du har plads nok er disse libs lige så gode på embedded som
alle andre steder !

/BL

---

"Bo Lorentsen" <bl@nospam.lue.dk> wrote:
> Troels Arvin wrote:
> >
> > Bliver STL, Boost og den slags ting egentlig brugt i forb. med embedded
> > software skrevet i C++?
> Jeg tror ikke det er det sted du vil se disse libs ofte. Jeg vil desvære
> mene at templates er for svære at styre (memory footprint) til en
> embedded platform.

Jeg har været med til at bruge templates i embedded applikationer.
Jeg mener at det er til at styre, men man skal naturligvis vide hvad man
laver, og somme tider optimere koden - men er det ikke altid sådan hvis man
skal skrive høj performance kode ?

> Jeg har endnu ikke fundet en kompiler er optimerer
> template's ordenligt endnu ( vi mangler vist C++ export ).

Hvilken rolle mener du at export spiller for en compilers evne til at lave
performance optimering ?

> Hvis man
> bruge et lib til embedded code tror jeg at man vil fortrække at linke
> det i bund (statisk), så man ikke slæber rundt på kode (dead code) man
> ikke bruger

Enig.
Ydermere kan templates i C++ være med til at eliminere død kode, fordi
template funktioner først må blive instantieret, når man kalder dem - altså
faktisk bruger dem.

>, og så man ikke har en så voldsom stor symbol tabel (C++
> mangling fylder lidt).

Der er vel ikke nogen grund til at symbol tabellen skal ned på target ?
Jeg er vandt til at symbol tabellen ligger på udviklingsmaskinen, og kun den
eksekverbare kode downloades.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:


> Jeg har været med til at bruge templates i embedded applikationer.
> Jeg mener at det er til at styre, men man skal naturligvis vide hvad man
> laver, og somme tider optimere koden - men er det ikke altid sådan hvis man
> skal skrive høj performance kode ?
Det er desværre nogle år sigen jeg sidst kodet embedded, men jeg har
endnu ikke helt fået styr på "code bloat" når jeg bruger templates, men
det kan jo hænge sammen med mit compiler valg

Kode optimerering er nok en af de mere krævende dicipliner, da man skal
have indgående kendskab til både hardware platform og ALL ens værktøjer,
og så skal man kunne overskue HELE ends projekt.
> Hvilken rolle mener du at export spiller for en compilers evne til at lave
> performance optimering ?
Den eneste performance export kan give er færre cache misses

Jeg forsøgte blot at henvise til at export kunne hjæpe med at styrre
mængten af template instancer, hvile mest af alt har noget med footprint
at gøre.

> Enig.
> Ydermere kan templates i C++ være med til at eliminere død kode, fordi
> template funktioner først må blive instantieret, når man kalder dem - altså
> faktisk bruger dem.
Yeps, men tilgengæld bliver de inlinet ved hver henvisning, og det er
vist her at de compilere jeg har haft med at gøre ikke kan gøre så meget.

> Der er vel ikke nogen grund til at symbol tabellen skal ned på target ?
Nix, derfor mit opstød omkring at linke i bund og shared libs, så enig

> Jeg er vandt til at symbol tabellen ligger på udviklingsmaskinen, og kun den
> eksekverbare kode downloades.
Alt andet ville også være griseri

/BL

---

"Bo Lorentsen" <bl@nospam.lue.dk> wrote:
> Mogens Hansen wrote:

[8<8<8<]
> > Hvilken rolle mener du at export spiller for en compilers evne til
> > at lave performance optimering ?
> Den eneste performance export kan give er færre cache misses
>
> Jeg forsøgte blot at henvise til at export kunne hjæpe med at styrre
> mængten af template instancer, hvile mest af alt har noget med footprint
> at gøre.

Så vidt jeg forstår blander du nogle ting sammen.

Det er rigtigt at een almindelig måde at instantiere template er at for hver
compilation unit, bliver de templates som den unit bruger instantieret og
lagt ned i objekt filen.
Det gør at hvis 2 filer A.cpp og B.cpp begge bruger template funtionen
foo<int>(), vil den findes i A.obj og B.obj (eller hvad de nu hedder).
Men det betyder _ikke_ at der kommer assembler kode til 2 foo<int>() i det
endelige program.
Det skyldes at hvis linkeren er bare nogenlunde anstændig, så vil den
sortere dubletterne fra og kun efterlade een.
Dette er ikke et _krav_ i sprog specifikationen, men et rimeligt krav at
stille til en implementation.
Derimod er det et krav at hvis man i A.cpp tager adressen af foo<int>() skal
man få samme værdi som hvis man tager adressen af foo<int>() i B.cpp.

Se eventuelt
C++ Templates, The Complete Guide
David Vandevoorde, Nicolai M. Josuttis
ISBN 0-201-73484-2
side 155-156 for en bedre og mere detaljeret beskrivelse.

export ændrer ikke på hvor mange instancer er en given funktion man vil
forvente at finde i det binært eksekverbare produkt: nemlig een.



[8<8<8<]
> Yeps, men tilgengæld bliver de inlinet ved hver henvisning, og det er
> vist her at de compilere jeg har haft med at gøre ikke kan gøre så meget.

Jeg forstår ikke helt hvad du mener.
En funktions template behøver ikke at være inlinet, og en inlinet funktion
behøver ikke at være en template.
En funktions template kan være inline.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
>
> Så vidt jeg forstår blander du nogle ting sammen.
Det kan du snilt bilde mig ind

> Det er rigtigt at een almindelig måde at instantiere template er at for hver
> compilation unit, bliver de templates som den unit bruger instantieret og
> lagt ned i objekt filen.
> Det gør at hvis 2 filer A.cpp og B.cpp begge bruger template funtionen
> foo<int>(), vil den findes i A.obj og B.obj (eller hvad de nu hedder).
> Men det betyder _ikke_ at der kommer assembler kode til 2 foo<int>() i det
> endelige program.
Hmm, well --- kun hvis det er inline functioner ?

> Det skyldes at hvis linkeren er bare nogenlunde anstændig, så vil den
> sortere dubletterne fra og kun efterlade een.
Det ville være et rimeligt sted, jeg har blot ikke overblik over hvem
der kan det for tiden. Jeg bruger selv gcc og derved collect2, og jeg
har antaget (på bases af kode størrelse) at den ikke finder doubletter,
men jeg ved det faktisk ikke.

> Dette er ikke et _krav_ i sprog specifikationen, men et rimeligt krav at
> stille til en implementation.
Enig.

> Derimod er det et krav at hvis man i A.cpp tager adressen af foo<int>() skal
> man få samme værdi som hvis man tager adressen af foo<int>() i B.cpp.
Ok, det ville være en rimelig måde at teste doublet code oprydningen.
Man må kunne fine på et lille test eks. der instansierer den samme
template function (ikke inline) to steder, og herefter udskriver disses
functions pointere. De bør være ens, men jeg tror ikke altid de er det !

> Se eventuelt
> C++ Templates, The Complete Guide
> David Vandevoorde, Nicolai M. Josuttis
> ISBN 0-201-73484-2
> side 155-156 for en bedre og mere detaljeret beskrivelse.
Den står ikke på min hylde

> export ændrer ikke på hvor mange instancer er en given funktion man vil
> forvente at finde i det binært eksekverbare produkt: nemlig een.
Ahh, fordi export bliver (skal bruges når den virker) til at lave
templates efter samme opskrift som C/C++'s defination og implimantations
model, hvor vi idag kkun kan skrive kæmpe header filer med templates.

> Jeg forstår ikke helt hvad du mener.
Jeg tror bare jeg vrøvler lidt

> En funktions template behøver ikke at være inlinet, og en inlinet funktion
> behøver ikke at være en template.
> En funktions template kan være inline.
Jeg trængte vist bare til at få støvet lidt teori af, det er over et år
siden jeg kodede templates sidst

/BL

---

"Bo Lorentsen" <bl@nospam.lue.dk> wrote:
> Mogens Hansen wrote:

[8<8<8<]
> > Det gør at hvis 2 filer A.cpp og B.cpp begge bruger template funtionen
> > foo<int>(), vil den findes i A.obj og B.obj (eller hvad de nu hedder).
> > Men det betyder _ikke_ at der kommer assembler kode til 2 foo<int>() i
det
> > endelige program.
> Hmm, well --- kun hvis det er inline functioner ?

Ja, det er en mulighed.
Men det er uafhængigt af om funktionen er en template funktion eller ej.

Det giver desuden ikke nødvendigvis større programmer.
Der er to årsager:
1. Det at sætte stack-framen op på kaldestedet kan fylde mere end den kode
funktionen udfører.
Det er f.eks. typisk tilfældet med less<int>(???) og
vector<???>.begin()
2. Det at compileren indsætter funktionens kode gør, at optimizeren kender
mere til hvad der skal ske, og dermed kan udføre optimeringer, som ellers
ikke er mulige. Det har jeg set og udnyttet i produktionskode til embeddede
systemer.

Hvis man inliner store funktioner, kan det naturligvis give større
programmer, der til gengæld kører hurtigere (bl.a. pga. cache og pipeline
fænomener på moderne CPU'er).
Det er et rimeligt kompromis, og det er rimeligt at udviklingeren har
mulighed for at have kontrol over valget (størrelse/eksekveringshastighed).

Der var iøvrigt fornyligt en interessant, lidt tilsvarende diskution på
comp.lang.c++.moderated.
Du kan søge på Google efter tråden "C++ templates vs. .NET generics".
Den, i denne sammenhæng, relevante del af diskutionen tog fart, da Scott
Meyers (den 9. november 2003) sagde at han hørte fra udviklere og forskere
at templates gav uventede store programmer.
Jeg mener ikke at der i diskutionen fremkom dokumentation for at der er
nogen grund til at det faktisk skulle forholde sig sådan.
Fænomenerne var forståelige, og simple løsninger fandtes.

Desuden gav Scott Meyers links til interessante forskningsrapporter, der
sigtede på at komprimere koden hvor man brugte et profiler output til at
vælge komprimerings strategi, således at hyppigt kørende kode ikke bliver
komprimeret, mens sjældent kort kode bliver komprimeret og foldet.

>
> > Det skyldes at hvis linkeren er bare nogenlunde anstændig, så vil den
> > sortere dubletterne fra og kun efterlade een.
> Det ville være et rimeligt sted, jeg har blot ikke overblik over hvem
> der kan det for tiden.

På MS-Windows platformen fjerner Borland C++Builder, Microsoft Visual
C++.NET og Intel C++ dubletter - og har mig bekendt altid gjort det, fordi
alternativet duplicate fejl fra linkeren.
Derudover er Microsoft linkeren (som Intel C++ også bruger) i stand til at
slå forskellige funktioner, der er binært identiske sammen.
F.eks. vil det almindeligvis være således at std::less<int*> og
std::less<double*> er binært identiske.
Ydermere kan man nemt forestille sig platforme hvor std::less<int*> og
std::less<int> er binært identiske fordi sizeof(int*)==sizeof(int).
Disse 3 funktioner vil Microsoft linkeren (siden Visual C++ V5 - de sidste
ca. 7 år) kunne slå sammen til een, hvis de ikke er inlinet (naturligvis) og
hvis man ikke har taget adressen af dem (da de _skal_ være forskellig).

Hvad andre compilere gør ved jeg ikke - men det er relativt nemt at finde ud
af (kig i mapfilerne, brug en debugger og se hvor funktionerne ligger, kig
på filens størrelse).

Venlig hilsen

Mogens Hansen

---

On Mon, 12 Jan 2004 22:54:26 +0100, Bo Lorentsen wrote:

> Hvis man
> bruge et lib til embedded code tror jeg at man vil fortrække at linke
> det i bund (statisk), så man ikke slæber rundt på kode (dead code) man
> ikke bruger, og så man ikke har en så voldsom stor symbol tabel

Jeg synes at have hørt, at en linker godt kan være selektiv mht. hvilke
object-code elementer, den indsætter, også selvom at den bliver bedt om
at skabe et statisk linket program.

Så vidt jeg har forsået det: På linux findes biblioteker til statisk
linking normalt som *.a filer, der er et arkiv indeholdende en mængde
object-kode elementer, som linkeren antagelig kan hive ud og kopiere efter
forgodtbefindende.

Hvordan fungerer noget lignende egentlig på Windows? Findes der DLLer,
der kan bruges til statisk linking, eller er en DLL per definition kun
relevant til brug ved dynamisk linking?

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

"Troels Arvin" <troels@arvin.dk> wrote:

> Hvordan fungerer noget lignende egentlig på Windows? Findes der DLLer,
> der kan bruges til statisk linking,

Ikke mig bekendt.

> eller er en DLL per definition kun
> relevant til brug ved dynamisk linking?

Ja.

Men samme funktionalitet kan godt stilles til rådighed for udvikleren både
som et DLL og som et statisk LIB.
Det er helt almindeligt. F.eks. er det tilfældet med runtime biblioteket og
MFC (til Microsoft og Borland compilerne).

Venlig hilsen

Mogens Hansen

---

On Mon, 12 Jan 2004 23:19:05 +0100, Mogens Hansen wrote:

>> eller er en DLL per definition kun
>> relevant til brug ved dynamisk linking?
>
> Ja.
>
> Men samme funktionalitet kan godt stilles til rådighed for udvikleren både
> som et DLL og som et statisk LIB.

I hvilken form kommer et sådant? Er der en bestemt konvention for
fil-endelser på sådanne?

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

"Troels Arvin" <troels@arvin.dk> wrote:

[8<8<8<]
> I hvilken form kommer et sådant? Er der en bestemt konvention for
> fil-endelser på sådanne?

*.lib
Dog skal man lige være sikker på at man ikke forveksler dem med import
libraries fra DLL.
Typisk er almindelig LIB filer store, og import libraries små (størrelses
ordenen 10 kbyte).

Venlig hilsen

Mogens Hansen

---

On Mon, 12 Jan 2004 23:36:33 +0100, Mogens Hansen wrote:

> Dog skal man lige være sikker på at man ikke forveksler dem med import
> libraries fra DLL.

Hvad er import libraries?

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

"Troels Arvin" <troels@arvin.dk> wrote:

[8<8<8<]
> Hvad er import libraries?

Et import library kan man bruge til at få adgang til de funktioner et DLL
exporterer (stiller til rådighed).

Der er principielt 2 måder at bruge DLL'er på:
* Explicit loaded, f.eks. vha. LoadLibrary, hvorefter man spørger efter
adresserne på de enkelte funktioner, som man så kan kalde
* Implicit loaded, hvor man bare bruger funktionerne helt normal og
overloader det til linkeren at finde ud af hvor de findes.

Tag en simpel runtime library funktion som "strcpy".
Hvis man bruger den statisk linket, kommer den til at ligge i din EXE-fil.
Hvis man bruger den dynamisk linket, ligger den i et DLL.
Når man i koden bruger "strcpy" spiller det ingen rolle hvor koden ligger.

Hvis man bruger "strcpy" fra et DLL, skal linkeren på et tidspunkt bestemme
hvor "strcpy" findes, og det er her import librariet kommer ind i billedet.
Import librariet indeholder "strcpy", set fra linkeren, men i virkeligheden
er det blot en lille bitte stump kode (call-thunk), der sender programmet
ned i DLL'et hvor funktionen faktisk findes.

Den mest almindelige måde at bruge DLL'er på er via et import library.

Venlig hilsen

Mogens Hansen

---

Troels Arvin wrote:

> On Mon, 12 Jan 2004 22:54:26 +0100, Bo Lorentsen wrote:
>
>
>>Hvis man
>>bruge et lib til embedded code tror jeg at man vil fortrække at linke
>>det i bund (statisk), så man ikke slæber rundt på kode (dead code) man
>>ikke bruger, og så man ikke har en så voldsom stor symbol tabel
>
>
> Jeg synes at have hørt, at en linker godt kan være selektiv mht. hvilke
> object-code elementer, den indsætter, også selvom at den bliver bedt om
> at skabe et statisk linket program.
>
> Så vidt jeg har forsået det: På linux findes biblioteker til statisk
> linking normalt som *.a filer, der er et arkiv indeholdende en mængde
> object-kode elementer, som linkeren antagelig kan hive ud og kopiere efter
> forgodtbefindende.
>
> Hvordan fungerer noget lignende egentlig på Windows? Findes der DLLer,
> der kan bruges til statisk linking, eller er en DLL per definition kun
> relevant til brug ved dynamisk linking?

Nej, men tilgengæld kan du i nogen tilfælde få en .lib fil du kan
statisk linke ind i dit program (f.eks. MFC lib's vs. MFC DLL's).

---

"Troels Arvin" <troels@arvin.dk> wrote:

[8<8<8<]
> Bliver STL, Boost og den slags ting egentlig brugt i forb. med embedded
> software skrevet i C++?

STL blev oprindeligt brugt til embedded formål.
Den første anvendelse af STL var i HP laserprintere.
Da Alexander Stepanov udviklede STL arbejdede han hos HP.


Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> STL blev oprindeligt brugt til embedded formål.
Hmm, tror du ikke en HP printer er en ret "stor" enbedded platform ? I
min lille hp6l sidder der en 68030 med 1M ram, det er da en hel PC

> Den første anvendelse af STL var i HP laserprintere.
> Da Alexander Stepanov udviklede STL arbejdede han hos HP.
Til at skrive postcript fortolkere/rendere ?

/BL

---

"Bo Lorentsen" <bl@nospam.lue.dk> wrote:
> Mogens Hansen wrote:


Hvis man er interesseret i C++ performance aspekter, også i relation til
embeddede systemer vil jeg anbefale at kigge på rapporten "Technical Report
on C++ Performance"
http://www.research.att.com/~bs/performanceTR.pdf
fra C++ standardiserings kommitteen.

[8<8<8<]
>
> > STL blev oprindeligt brugt til embedded formål.
> Hmm, tror du ikke en HP printer er en ret "stor" enbedded platform ? I
> min lille hp6l sidder der en 68030 med 1M ram, det er da en hel PC

Er det en stor embedded platform ?
Det er naturligvis større end en 8051, men det lyder som lidt større end en
Gameboy Advance, men mindre end en mobiltelefon.

Embeddede systemer dække jo over en utrolig bred vifte af system størrelser,
lige fra små 4 bit systemer til kæmpe systemer i f.eks. flyvemaskiner.


Hvis vi antager (uden at have konkret viden om det), at vector<???> findes i
et system af den størrelse du nævner, så er det vel rimeligt at antage at
det kun vil kunne tillades at den fylder en forsvindende del at det samlede
system.


Prøv at kigge på koden og funktionaliteten i std::vector, og du vil
formodentlig se at det kan ikke gøres voldsomt meget mere effektivt, hvis
man har brug for et array med dynamisk størrelse der giver velspecificeret
performance og fejlhåndtering.
Hvis man ikke har brug for et array med dynamisk størrelse, men alligevel
bruger std::vector, så er det klart at man har et overhead.

Prøv at kigge på koden til std::find, og se om du kan lave en linær søgning
der er mere effektiv.

Det er den slags kode man skal kunne lave bedre selv, hvis man vælger ikke
at bruge det der allerede findes, er testet, standardiseret og vidt udbredt.
Dertil kommer at den måde som STL, og andre moderne template biblioteker,
kan være inspiration til hvordan man selv kan skrive meget effektiv kode.

Selvfølgelig kan man bruge STL ineffektivt.
Man kan også risikere at have problemer med sine værktøjer.

>
> > Den første anvendelse af STL var i HP laserprintere.
> > Da Alexander Stepanov udviklede STL arbejdede han hos HP.
> Til at skrive postcript fortolkere/rendere ?

Det ved jeg ikke.
Jeg kender heller ikke noget hvilken printer model(er) eller computerens
størrelse.

Jeg er blot temmelig sikker på at det blev brugt i HP laserprintere og at
det må have været omkring 1994.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
>>Hmm, tror du ikke en HP printer er en ret "stor" enbedded platform ? I
>>min lille hp6l sidder der en 68030 med 1M ram, det er da en hel PC
>
> Er det en stor embedded platform ?
> Det er naturligvis større end en 8051, men det lyder som lidt større end en
> Gameboy Advance, men mindre end en mobiltelefon.
>
> Embeddede systemer dække jo over en utrolig bred vifte af system størrelser,
> lige fra små 4 bit systemer til kæmpe systemer i f.eks. flyvemaskiner.
Enig enig, men ofte er der tale om en eller anden for for resource
begrænsning, den sidste jeg sad på var dog en lille hjemmebygget V25
(80186) platform, og her bliver man hurtig paranoid

> Hvis vi antager (uden at have konkret viden om det), at vector<???> findes i
> et system af den størrelse du nævner, så er det vel rimeligt at antage at
> det kun vil kunne tillades at den fylder en forsvindende del at det samlede
> system.
Enig.

> Prøv at kigge på koden og funktionaliteten i std::vector, og du vil
> formodentlig se at det kan ikke gøres voldsomt meget mere effektivt, hvis
> man har brug for et array med dynamisk størrelse der giver velspecificeret
> performance og fejlhåndtering.
Jeg kan ikke være mere enig.

> Hvis man ikke har brug for et array med dynamisk størrelse, men alligevel
> bruger std::vector, så er det klart at man har et overhead.
Det gælder jo stort set alting, i denne branche

> Prøv at kigge på koden til std::find, og se om du kan lave en linær søgning
> der er mere effektiv.
Det er svært, og den kan bruges til alle STL containere, så igen enig.

> Det er den slags kode man skal kunne lave bedre selv, hvis man vælger ikke
> at bruge det der allerede findes, er testet, standardiseret og vidt udbredt.
> Dertil kommer at den måde som STL, og andre moderne template biblioteker,
> kan være inspiration til hvordan man selv kan skrive meget effektiv kode.
Rolig rolig, jeg holder skam MEGET af STL, og vi er helt enige, jeg er
blot nervøs for om de platforme jeg ville bruge, også optimerede koden
sådan som det er tænkt. Hvis de ikke gør det vil den samme template,
bloate koden, ikke fordi den ikke er skrevet ordenligt, men fordi
linkeren ikke opdater der 117 andre 100% ens fætre.

> Selvfølgelig kan man bruge STL ineffektivt.
Der er ikke grænser for hvad jeg kan bruge ineffektivt, men det er
desværre bare ikke så interessant

> Man kan også risikere at have problemer med sine værktøjer.
Det er nok her jeg står.

> Jeg er blot temmelig sikker på at det blev brugt i HP laserprintere og at
> det må have været omkring 1994.
Du har sikkert ret, jeg betvivler det heller ikke.

/BL

---

"Bo Lorentsen" <bl@nospam.lue.dk> wrote in message
news:bu1rr9$2ljr$1@news.cybercity.dk...

[8<8<8<]
> Enig enig, men ofte er der tale om en eller anden for for resource
> begrænsning,

Jeps

> den sidste jeg sad på var dog en lille hjemmebygget V25
> (80186) platform, og her bliver man hurtig paranoid

Jeg kender godt NEC V25 (er der ikke også en V35, hvor forskellen svarer til
80186/80188 ?).
Jeg kan bl.a. huske at jeg har set den benyttet til at styre tandlægestole
med.

Det svarer i regnekraft til noget der minder en 8088 baseret PC-XT.
I 1991 programmerede jeg C++ under MS-DOS (640 Kbyte) på en 16 MHz PC med
anvendelse af objekt orienteret programmering.

Omkring den tid skrev jeg objekt orienterede tekst-baserede,
brugergrænseflader med vinduer, menuer og muse-understøttelse med anvendelse
af Borland Turbo Vision.

Man kunne godt bruge hukommelsen op, og det var rart da man fik
DOS-extendere.
Omvendt var der ikke noget til hinder for at bruge objekt orienteret
programmering til programmer der havde MS-DOS som target.

Turbo Pascal 5.5 tilføjede objektorienteret programmering i foråret 1989.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

>>den sidste jeg sad på var dog en lille hjemmebygget V25
>>(80186) platform, og her bliver man hurtig paranoid
>
>
> Jeg kender godt NEC V25 (er der ikke også en V35, hvor forskellen svarer til
> 80186/80188 ?).
Det anede mig, du er ikke helt ny i denne branche Jeg kan huske at
vi solgte V20 ho s Aage Nielsen da den var ca. 25% hurtigere end 8088
Mand hvor kan man føle sig gammel

> Jeg kan bl.a. huske at jeg har set den benyttet til at styre tandlægestole
> med.
Hmm, var det ikke en lidt stor platform til et par servo motorer ?

> Det svarer i regnekraft til noget der minder en 8088 baseret PC-XT.
Yeps, blot med mulighed for MEGET hurtig interrupt services, pga. de 8
register sæt (af det jeg kan huske), man hurtigt kunne skifte mellem.

> I 1991 programmerede jeg C++ under MS-DOS (640 Kbyte) på en 16 MHz PC med
> anvendelse af objekt orienteret programmering.
I msc 7 ?

> Omkring den tid skrev jeg objekt orienterede tekst-baserede,
> brugergrænseflader med vinduer, menuer og muse-understøttelse med anvendelse
> af Borland Turbo Vision.
I Pascal ? Det var får message dispachernes tid.

> Man kunne godt bruge hukommelsen op, og det var rart da man fik
> DOS-extendere.
Yesp, ellers var der jo altid overlay tekniken.

> Omvendt var der ikke noget til hinder for at bruge objekt orienteret
> programmering til programmer der havde MS-DOS som target.
Det var bare ikke så hot dengang, og C++ var på det stadie som Bjarne's
grå bog (har den stadig når jeg er i det hjørne). Så basalt set var der
kun mangling og vfunc tabeller der fyldte, og man linkede jo i bund så
symbol tabeller var ligegyldige.

> Turbo Pascal 5.5 tilføjede objektorienteret programmering i foråret 1989.
Har aldrig rigtig lært at holde af det sprog, C/C++ var og blive min
første kærlighed (mht. programmerings sprog, forstås .

/BL

---

"Bo Lorentsen" <bl@nospam.lue.dk> wrote:

[8<8<8<]
> > Jeg kan bl.a. huske at jeg har set den benyttet til at styre
tandlægestole
> > med.
> Hmm, var det ikke en lidt stor platform til et par servo motorer ?

Det ved jeg ikke - jeg fik ikke jobbet

Inden da havde jeg kig på den, som mulig afløser for vores 8051 løsninger.

[8<8<8<]
> > I 1991 programmerede jeg C++ under MS-DOS (640 Kbyte) på en 16 MHz PC
med
> > anvendelse af objekt orienteret programmering.
> I msc 7 ?

Nej (heldigvis ikke).
Den blev i øvrigt først frigivet i april 1992, og var ikke særlig god til
C++ i forhold til datatidens standard.
Den var i det hele taget ikke særlig god (bortset fra kvaliteten af den
genererede kode).
Selv internt i Microsoft viste man godt at produktet ikke ligefrem var
state-of-art.
Se bogen
Dynamics of Software Development
Jim McCarthy
ISBN 1-55615-823-8
som beskriver en del interessante forhold omkring software udvikling, bl.a.
med udgangspunkt i erfaringer fra udviklingen af Microsoft Visual C++ V1.0.
Herunder markedssituationen på det tidspunkt. Jim McCarthy var "director of
the Microsoft Visual C++ Program management Team", og altså een af
hovedkræfterne bag Visual C++ V1.0.

Jeg brugte Borland Turbo C++ V1.
Den første let tilgængelige C++ compiler på PC platformen

>
> > Omkring den tid skrev jeg objekt orienterede tekst-baserede,
> > brugergrænseflader med vinduer, menuer og muse-understøttelse med
anvendelse
> > af Borland Turbo Vision.
> I Pascal ? Det var får message dispachernes tid.

Nej - Turbo Vision med C++.

[8<8<8<]
> > Omvendt var der ikke noget til hinder for at bruge objekt orienteret
> > programmering til programmer der havde MS-DOS som target.
> Det var bare ikke så hot dengang, og C++ var på det stadie som Bjarne's
> grå bog (har den stadig når jeg er i det hjørne).

Jeg var med til at bruge C++ dengang (1991) til embeddede systemer.
Ja, vi havde Bjarne Stroustrup "The C++ Programming Language, Second
Edition" (den grå) stående på dengang.
Jeg har også første edition stående

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

>>Omend sprog som C og maskinkode er væsentlig mere udbredt da det ikke er
>> lige så resource-krævende.
>>
>
>
> Har du nogen form for troværdig opgørelse, der bakker dit udsagn op ?

Nej.

> Man kan også kigge på stillings annoncer, hvor man også ofte ser at der
> bliver søgt folk med erfaring i C++, Java, UML og objekt orienteret
> programmering til embeddede systemer.
> Se f.eks.
>
>
http://www.jobfinder.dk/shared/cv/source/cv_start.hts?nav_to=no_logon,search
> ,id,328474795
>
>
http://www.jobfinder.dk/shared/cv/source/cv_start.hts?nav_to=no_logon,search
> ,id,328474204
>
>
http://www.jobfinder.dk/shared/cv/source/cv_start.hts?nav_to=no_logon,search
> ,id,328474117
> for nogle aktuelle eksempler.


Nu skal du nok også passe på med at drage konklussioner på baggrund af
Danmark, jeg er ret sikker på at det sted i verden hvor der
produceres/anvendes flest embedded systemer er Asien.


> Mener du at objekt orienteret programmering i sig selv giver mere
resource
> krævende programmer ?

Ja, hvis du kigger på hvordan objekter almindeligvis bliver
allokeret/deallokeret versus asm/c-kode, så vil jeg give mig selv ret

Hvilket programmeringssprog vil du antage er anvendt i et
digitalt-armbåndsur der skal drives af et alm. ur-batteri? Hvilket
programmeringssprog vil du antage er anvendt i en fjernbetjning til dit
discount-tv?

Jeg er godt klar over danske producenter, som f.eks. B&O, er i gang med
noget java på embedded systemer (dvs. deres hifi-udstyr) men igen -- jeg
tror det er Asien man skal kigge nærmere på.

---

"Rasmus Christian Kaae" <rasmusTOPHAT@3kings.dk> wrote in message
news:bu0s39$1hbi$1@news.cybercity.dk...
> Mogens Hansen wrote:

[8<8<8<]
> Nu skal du nok også passe på med at drage konklussioner på baggrund af
> Danmark,

Netop.
Uden en seriøs undersøgelse er det nok vanskelligt at vide hvor udbredt
forskellige programmerings paradigmer er i forhold til hinanden.

> jeg er ret sikker på at det sted i verden hvor der
> produceres/anvendes flest embedded systemer er Asien.

Hvad har det med udbredelsen af objekt orienteret programmering af embeddede
systemer at gøre ?
Mener du at befolkningen i Asien er mindre egnet til at forstå objekt
orienteret programmering end befolkningen i Europa eller USA ?

Hvilken rolle spiller udbredelsen af objekt orienteret programmering i
embeddede systemer i Asien for en der ønsker at lave embeddede systemer og
samtidig bo i Danmark ?


> > Mener du at objekt orienteret programmering i sig selv giver mere
> resource
> > krævende programmer ?
>
> Ja, hvis du kigger på hvordan objekter almindeligvis bliver
> allokeret/deallokeret versus asm/c-kode, så vil jeg give mig selv ret

Tænker du på specifikke sprog, eller objekt orienteret programmering
generelt.

I C++ kan objekter allokeres præcist ligeså effektivt som du allokerer
strukturer i C.
Hvis du vælger at lade objektet have en konstruktor, som initialiserer
datamedlemmerne, vil det kunne ske præcist lige så effektivt som hvis du i C
allokerer strukturen og derefter tildeler de enkelte elementer.

>
> Hvilket programmeringssprog vil du antage er anvendt i et
> digitalt-armbåndsur der skal drives af et alm. ur-batteri?

Jeg vil tro at et almindeligt digitalur er lavet uden en generel
programmerbar CPU.
Jeg vil tro at det er en dedikeret, højt specialiseret hardware løsning.
VHDL kan i givet fald være et bud.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

[en masse]

Jeg tror bare jeg snipper det hele og stopper diskussionen fra min side.
Min pointe med at inddrage Asien var at størstedelen af al
elektronik bliver produceret der -- hvorfor sikkert en del af
styre-koden også udspringer derfra.

En umiddelbar tanke kan være at du med embedded systemer udelukkende
forstår større systemer som f.eks. en mobiltelefon eller anden
"højteknologisk enhed". Som jeg skrev så er der også embedded kode i en
række eksisterede digital ure -- og her er der ikke brug for en
kompliceret objektmodel i det producenterne nok hellere vil tage højde
for at uret kan virke i lang tid på en dosis batterier frem for at
programmører kan få lov til at udøve sit yndlingsprogrammerings paradigme.

---

"Rasmus Christian Kaae" <rasmusTOPHAT@3kings.dk> wrote:


> Jeg tror bare jeg snipper det hele og stopper diskussionen fra min side.

Ok.
Det forekommer mig dog at være lidt en slap holdning, hvis du oprindeligt
havde noget på hjertet, eller havde viden andre kunne have gavn af.
Forhold dig dog i det mindste til den konkrete tilbagevisning af din påstand
om at objekter er langsommere at allokere, end den tilsvarende handling i C.

> Min pointe med at inddrage Asien var at størstedelen af al
> elektronik bliver produceret der -- hvorfor sikkert en del af
> styre-koden også udspringer derfra.

Tænker du på nogle specielle produkter eller projekter som du kender til ?
Hvor store computere forestiller du dig at der sidder i moderne digital
kameraer, der sælges som konsum elektronik produceret og udviklet i østen.

Jeg er f.eks. ret sikker på at softwaren i Sony's robot legetøjs hund er
skrevet i C++.
I hvilken udstrækning det er objekt orienteret designet ved jeg til gengæld
ikke.

>
> En umiddelbar tanke kan være at du med embedded systemer udelukkende
> forstår større systemer som f.eks. en mobiltelefon eller anden
> "højteknologisk enhed".

Naturligvis.
Hvilken mening giver det f.eks. at diskutere om std::vector<???> kan bruges
til at simplificere håndteringen af dynamisk allokeret hukommelse på
applikations niveau, hvis target systemet er så lille at det end ikke har
nogen heap ?

Man må nødvendigvis snakke om hvad det koster at løse et problem med f.eks.
C og hvad det koster at løse det _tilsvarende_ problem med objekt orienteret
programmering (hvis det er en passende løsning på det konkrete problem) i et
givent sprog f.eks. C++.

> ... for at
> programmører kan få lov til at udøve sit yndlingsprogrammerings paradigme.

Det er jo indholdsløs snik snak.


Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
>>Jeg tror bare jeg snipper det hele og stopper diskussionen fra min side.
> Ok.
> Det forekommer mig dog at være lidt en slap holdning, hvis du oprindeligt
> havde noget på hjertet, eller havde viden andre kunne have gavn af.
> Forhold dig dog i det mindste til den konkrete tilbagevisning af din påstand
> om at objekter er langsommere at allokere, end den tilsvarende handling i C.

Nej, det er ikke en slap holdning -- du lyder bare lidt for selvsikker
og afviser de tilnærmelser der kommer fra anden side. Du har jo
tilsynedladende en forudtagelse, at de systemer du netop kender til
dækker det store verdensmarked - og jeg har en anden.

Det tager nødvendigvis længere tid at allokere en objekt-model vs. ikke
at allokere en. Hvis du f.eks. har et system med fixed-hukommelse på
måske et par kb's hvad vil du så helst benytte den til? Allokering af
strukturer m.m. eller opbevaring af reel data?

>
>> Min pointe med at inddrage Asien var at størstedelen af al
>>elektronik bliver produceret der -- hvorfor sikkert en del af
>>styre-koden også udspringer derfra.
>
>
> Tænker du på nogle specielle produkter eller projekter som du kender til ?
> Hvor store computere forestiller du dig at der sidder i moderne digital
> kameraer, der sælges som konsum elektronik produceret og udviklet i østen.
>
> Jeg er f.eks. ret sikker på at softwaren i Sony's robot legetøjs hund er
> skrevet i C++.
> I hvilken udstrækning det er objekt orienteret designet ved jeg til gengæld
> ikke.

Nu er Sony's robot-legetøjs-hund igen et større system indenfor embedded
software. Tænk igen på hvor små enheder der sidder i digitale ure, om du
kalder det for et enkelt kredsløb eller ej - så er det blevet
programmeret på et tidspunkt og det har IKKE været i et højniveau
objektorienteret sprog.

>>En umiddelbar tanke kan være at du med embedded systemer udelukkende
>>forstår større systemer som f.eks. en mobiltelefon eller anden
>>"højteknologisk enhed".
>
>
> Naturligvis.
> Hvilken mening giver det f.eks. at diskutere om std::vector<???> kan bruges
> til at simplificere håndteringen af dynamisk allokeret hukommelse på
> applikations niveau, hvis target systemet er så lille at det end ikke har
> nogen heap ?

Som igen refererer til at du definerer embedded systemer ved systemer på
størrelse med mobiltelefoner eller lign. En mobiltelefon har jo
efterhånden mere CPU-kraft end en Amiga 500 havde, er en Amiga så også
et embedded system?


> Man må nødvendigvis snakke om hvad det koster at løse et problem med f.eks.
> C og hvad det koster at løse det _tilsvarende_ problem med objekt orienteret
> programmering (hvis det er en passende løsning på det konkrete problem) i et
> givent sprog f.eks. C++.

Og hvad er pointen med den sætning?

>>... for at
>>programmører kan få lov til at udøve sit yndlingsprogrammerings paradigme.
> Det er jo indholdsløs snik snak.

Nej, for objektorientering giver dig da ikke større muligheder for at
løse en given opgave? Det gør det måske lettere.


-- Nåja, nu stoppede jeg ikke alligevel

---

"Rasmus Christian Kaae" <rasmusTOPHAT@3kings.dk> wrote:

[8<8<8<]
> du lyder bare lidt for selvsikker og afviser de tilnærmelser der kommer
fra anden side.

Jeg er ikke afvisende - jeg beder blot om uddybning af løse påstande, og
dokumentation for at det f.eks. er dyrere at allokere objekter end
tilsvarende handlinger i f.eks. C. Det er vel rimeligt nok ?

Du kan jo bare hoste op med konkret forklaring på hvad du mener, i stedet
for komme med løse, ufunderede generelle betragninger som ikke er rigtige.

> Du har jo
> tilsynedladende en forudtagelse, at de systemer du netop kender til
> dækker det store verdensmarked

Vrøvl.
Jeg har ikke udtalt mig om verdensmarked, eller hvor udbredt objekt
orienteret programmering er i forhold til andre programmerings paradigmer i
embeddede systemer.
Hvad har jeg skrevet der kan give dig det indtryk - vær præcis tak ?

Jeg har spurgt efter om du nogen steder havde belæg for at din på at om at
"sprog som C og maskinkode er væsentlig mere udbredt da det ikke er lige så
resource-krævende" - og det har vi fået svar på at du ikke havde.

Jeg har sagt at der ikke er en modsætning mellem brugen af objekt orienteret
programmering og embeddede systemer, og at objekt orienteret
programmering ikke er ualmindelig i embeddede systemer.
Dette er sket med henvisning til egen erfaring og konkrete aktuelle
stillingsannoncer i Danmark.

Grunden til at jeg tog emnet op er at der findes mange, ofte ubegrundede
fordomme om objekt orientereret programmering og performance.

>
> Det tager nødvendigvis længere tid at allokere en objekt-model vs. ikke
> at allokere en.

Og ... ?

Er det anderledes end at det tager længere tid at allokere og initialisere
datastrukturer i C eller assembler end at undlage at at gøre det ?
Hvis man har brug for nogle datastrukturer, så er der ikke noget overhead i
at oprette dem.
Hvis man ikke har brug for datastrukturerne, men alligevel opretter dem, så
er der naturligvis et overhead - og dermed plads til forbedring.

Det har blot ikke noget med objekt orienteret programmering i forhold til
f.eks. procedural programmering at gøre.

> Hvis du f.eks. har et system med fixed-hukommelse på
> måske et par kb's hvad vil du så helst benytte den til? Allokering af
> strukturer m.m. eller opbevaring af reel data?

Det er noget vrøvl du spørger om, set i relation til objekt orienteret
programmering vs. f.eks. procedural programmering.
Hvorfor kan objekter ikke indeholde reel data ?

Hvis du f.eks. laver en traditionel hægtet liste i assembler eller C, så går
der noget plads til pegere mellem elementerne. Altså information som man
kunne kalde struktur og ikke reel data. Præcis det samme er tilfældet hvis
du implementerer traditionel en hægtet liste objekt orienteret.
Man kan lave en hægtet liste med objekt orienteret programmering i C++, der
har præcis samme performance karakteristik som en tilsvarende hægtet liste
skrevet i C.
Hvis det problem man prøver at løse kræver (eller passer bedst til) en
hægtet liste, så er der ikke noget overhead.
Hvis problemet ikke løses bedst med en hægtet liste, så er der naturligvis
et overhead.

Det er ikke et spørgsmål om objekt orientering eller ej.
Det er et spørgsmål om at designe softwaren fornuftig i forhold til de krav
der er, inklusiv performance krav.

[8<8<8<]
> Tænk igen på hvor små enheder der sidder i digitale ure, om du
> kalder det for et enkelt kredsløb eller ej - så er det blevet
> programmeret på et tidspunkt og det har IKKE været i et højniveau
> objektorienteret sprog.

Er der nogen der har påstået det ?

Jeg har de sidste mere end 10 år siddet i nærheden af hardware ingeniører,
der har lavet integrerede kredsløb der i kompleksitet langt overstiger et
digital ur.
De ASIC's og FPGA'er er kodet med VHDL.
Det er blot noget helt andet vi så snakker om. Det er ikke assembler, C
eller C++ - og target er ikke noget der minder om en generel CPU. Target er
gates, registre etc.

Jeg mener, som sagt tidligere i tråden, at det er nærliggende at forestille
sig at et digital ur er kodet i VHDL eller noget tilsvarende, eventuelt
noget mere lavniveau.


[8<8<8<]
> > Man må nødvendigvis snakke om hvad det koster at løse et problem med
f.eks.
> > C og hvad det koster at løse det _tilsvarende_ problem med objekt
orienteret
> > programmering (hvis det er en passende løsning på det konkrete problem)
i et
> > givent sprog f.eks. C++.
>
> Og hvad er pointen med den sætning?


At gennerelle udsagn som at det tager længere tid at allokere objekter ikke
er særlig præcise eller verificerbare.
Man er nødt til at være mere præcis, og så kan man faktisk lave en vurdering
af om der er noget om snakken eller ej.
Du må kunne forklare hvorfra overheadet stammer, eller hvordan du har
oplevet at det er langsommere.

[8<8<8<]
> -- Nåja, nu stoppede jeg ikke alligevel



Venlig hilsen

Mogens Hansen

---

> Hvis du f.eks. laver en traditionel hægtet liste i assembler eller C, så går
> der noget plads til pegere mellem elementerne. Altså information som man
> kunne kalde struktur og ikke reel data. Præcis det samme er tilfældet hvis
> du implementerer traditionel en hægtet liste objekt orienteret.
> Man kan lave en hægtet liste med objekt orienteret programmering i C++, der
> har præcis samme performance karakteristik som en tilsvarende hægtet liste
> skrevet i C.
> Hvis det problem man prøver at løse kræver (eller passer bedst til) en
> hægtet liste, så er der ikke noget overhead.
> Hvis problemet ikke løses bedst med en hægtet liste, så er der naturligvis
> et overhead.

Hvis jeg arbejder med små systemer laver jeg ikke hægtede lister. Hvis
man har en meget begrænset hukommelse er dynamisk allokering da noget
af det dummeste der kan laves.
Hvis jeg vil udnytte f.eks. 4KByte data hukommelse bedst arbejder jeg
med 99% rene reelle data (dvs, ingen VMT, så få pointere som
overhovedet muligt).

> Det er ikke et spørgsmål om objekt orientering eller ej.
> Det er et spørgsmål om at designe softwaren fornuftig i forhold til de krav
> der er, inklusiv performance krav.

Prøv at forestille dig et "hello world" program i ren OOC. Hvor main()
kun laver output gennem et object. Sammenlign med et traditionelt
"hello world" program. Fjollet eksempel da end ikke den mest fanatiske
OOC person ville lave et objekt for at skrive "hello world" på skærmen
- MEN - det giver den information at for meget små programmer giver
objekt orientering dårligere performance end gammeldags kode. Og vi er
nok alle sammen enige om at objekt orientering er bedst for meget
store systemer, hvilket medfører at der nødvændigvis må være en
grænse, hvor OOC bliver "bedst" - nok en ret udefineret grænse, men
den må være der.

> > Tænk igen på hvor små enheder der sidder i digitale ure, om du
> > kalder det for et enkelt kredsløb eller ej - så er det blevet
> > programmeret på et tidspunkt og det har IKKE været i et højniveau
> > objektorienteret sprog.
>
> Er der nogen der har påstået det ?
>
> Jeg har de sidste mere end 10 år siddet i nærheden af hardware ingeniører,
> der har lavet integrerede kredsløb der i kompleksitet langt overstiger et
> digital ur.
> De ASIC's og FPGA'er er kodet med VHDL.

Kodet er et dårligt valgt ord... Jeg ville sige at "De ASICs og FPGAs
er _beskrevet_ med VHDL." Mine hardware ingeniør venner lyncher mig
ihvertfald når jeg kommer til at kalde dem programmører ;)

Der er nu ingen grund til at bringe logiske kredse ind i diskussionen.
Lad os starte med noget så simpelt som en stepmotor styring vha en
8051'er. Gammeldags C, OO C++, asm?
Så kan vi gå op og styre to stepmotorer med samme processor. C, OO
C++, eller asm?
Tre stepmotorer? Ti? 100?

Et eller andet sted her går vi fra C/asm til C++. Helt sikkert :)

Nå, det var så bare lige min mening om den sag :)

---

"Nicolai Hansen" <nic@aub.dk> wrote:
> > Hvis du f.eks. laver en traditionel hægtet liste i assembler eller C, så
går
> > der noget plads til pegere mellem elementerne. Altså information som man
> > kunne kalde struktur og ikke reel data. Præcis det samme er tilfældet
hvis
> > du implementerer traditionel en hægtet liste objekt orienteret.
> > Man kan lave en hægtet liste med objekt orienteret programmering i C++,
der
> > har præcis samme performance karakteristik som en tilsvarende hægtet
liste
> > skrevet i C.
> > Hvis det problem man prøver at løse kræver (eller passer bedst til) en
> > hægtet liste, så er der ikke noget overhead.
> > Hvis problemet ikke løses bedst med en hægtet liste, så er der
naturligvis
> > et overhead.
>
> Hvis jeg arbejder med små systemer laver jeg ikke hægtede lister. Hvis
> man har en meget begrænset hukommelse er dynamisk allokering da noget
> af det dummeste der kan laves.
> Hvis jeg vil udnytte f.eks. 4KByte data hukommelse bedst arbejder jeg
> med 99% rene reelle data (dvs, ingen VMT, så få pointere som
> overhovedet muligt).

Enig.

Det i denne sammenhæng væsentlige er, at din betragtning er fuldstændig
uafhængig af om programmet skrives proceduralt i assember, i C eller objekt
orienteret i C++ - du vil (helst) ikke lave hægtede lister.
Det er en konsekvens af problem- og løsnings-domainet.

>
> > Det er ikke et spørgsmål om objekt orientering eller ej.
> > Det er et spørgsmål om at designe softwaren fornuftig i forhold til de
krav
> > der er, inklusiv performance krav.
>
> Prøv at forestille dig et "hello world" program i ren OOC. Hvor main()
> kun laver output gennem et object. Sammenlign med et traditionelt
> "hello world" program. Fjollet eksempel da end ikke den mest fanatiske
> OOC person ville lave et objekt for at skrive "hello world" på skærmen

Lad os bare tage det eksempel - selvom vi er enige om at det er fjollet.
Det er måske også værd at bemærke at der findes sprog, som f.eks. Java og
C#, hvor Hello World _skal_ være objekt orienteret.

Lad mig også slå fuldstændigt fast, at jeg argumenterer ikke for at alle
problemer bedst løses med objekt orienteret programmering - tvært imod.


> - MEN - det giver den information at for meget små programmer giver
> objekt orientering dårligere performance end gammeldags kode.

Det giver _ikke_ dårligere performance.

Tag eksemplet:

<C++ kode>
#include <cstdio>

class base_application
{
public:
base_application(const char* greeting)
{ std::printf(greeting); }
};

class hello_world_application : public base_application
{
public:
hello_world_application() :
base_application("Hello World!") {}
};

int main(int argc, char* argv[])
{
hello_world_application hwa;
}
<C++ kode/>

Der er _ingen_ grund til at det skulle fylde een byte mere eller tage een
clock-cycle mere.
Der er _intet_ overhead med en bare nogenlunde compiler - jeg _har_ prøvet
det.

På en PC med Intel C++ under MS-Windows, bliver det til følgende assembler
kode
<asm listing>
int main(int argc, char* argv[])
{
hello_world_application hwa;
0040100C push offset string "Hello World!" (40A000h)
00401011 call printf (401020h)
00401016 xor eax,eax
00401018 pop ecx
00401019 mov esp,ebp
0040101B pop ebp
0040101C ret
</asm listing>

Hvor er den dårligere performance ?

Vi diskuterer _ikke_ om det er en bedre løsning og passende for problemet.

> Og vi er
> nok alle sammen enige om at objekt orientering er bedst for meget
> store systemer, hvilket medfører at der nødvændigvis må være en
> grænse, hvor OOC bliver "bedst" - nok en ret udefineret grænse, men
> den må være der.

Jeg mener ikke at der nødvendigvis er nogen nedre grænse.
Hvis det kan tillades at bruge C kan det også tillades at bruge objekt
orienteret programmering (hvis det er passende for løsningen) i C++.
Naturligvis kan man mangle tilstrækkelige værktøjer, eller være underlagt
firma eller projekt politik - men det er en anden snak.

Problem- og løsningsdomainet stiller naturligvis krav til hvad der er
passende.

[8<8<8<]
> Der er nu ingen grund til at bringe logiske kredse ind i diskussionen.

Nemlig

> Lad os starte med noget så simpelt som en stepmotor styring vha en
> 8051'er. Gammeldags C, OO C++, asm?

Langt bedre eksempel.

Bare for lige at slå et par ting fast:
Jeg har levet i over 3 år af at skrive 8051 assembler.
Der er almindeligvis begrænsninger med at skrive programmer i sprog der
baserer sig på stak overførsel af parametre som f.eks. C og C++ til 8051.
Det er f.eks. ikke ualmindeligt at rekursive kald er forbudt, simpelt hen på
grund af CPU arkitekturen understøtter det dårligt (i forhold til f.eks. en
8080).

Hvilken information hører typisk til en stepmotor ?
Noget med hvilket hardware interface (port A, B etc) den sidder på.
Den aktuelle position.

Om man gemmer de information i seperate variable, end datastruktur i C eller
et objekt i C++ spiller ingen performance mæssig rolle.
Hvis man vil drage fordel af at på compileringstidspunktet ved om det er
port A eller port B stepmotoren sidder på, er dermed fjerne en variabel, så
kan det tilsvarende gøres i C++ ved at lade klassen være en template klasse,
og porten være en template parameter.

Selve det at køre med motoren, og følge et hastighedsprofil vil være det
samme uanset om man skriver det i C eller C++.

Hvorfra skulle overheadet komme ?

> Så kan vi gå op og styre to stepmotorer med samme processor. C, OO
> C++, eller asm?
> Tre stepmotorer? Ti? 100?

Jeg tror egentlig ikke det spiller den store rolle.
Hvis man har flere forkellige typer kørselselsprofiler vil nok spille en
større rolle.

Venlig hilsen

Mogens Hansen

---

> Tag eksemplet:
>
> <C++ kode>
> #include <cstdio>
>
> class base_application
> {
> public:
> base_application(const char* greeting)
> { std::printf(greeting); }
> };

Her snyder du jo lidt og lader din constructor give dit output ;)
Hvis det nu skulle være sådan rigtigt ville du have en
base_application::greeting metode - og så ville vi have et anderledes asm
program i enden (ok, igen - en god compiler vil da måske nok kunne lave det
samme ud af det)

> Jeg mener ikke at der nødvendigvis er nogen nedre grænse.
> Hvis det kan tillades at bruge C kan det også tillades at bruge objekt
> orienteret programmering (hvis det er passende for løsningen) i C++.
> Naturligvis kan man mangle tilstrækkelige værktøjer, eller være underlagt
> firma eller projekt politik - men det er en anden snak.

Her glemte jeg nok at indføre et "her stopper jeg med at snakke
performance".

Det som jeg mente, også med 8051 diskussionen var at programmerne kan være
hurtigere at programmere, og mere overskuelige i C end i OO C++. Så længe de
er små.

> Langt bedre eksempel.

Tak

> Bare for lige at slå et par ting fast:
> Jeg har levet i over 3 år af at skrive 8051 assembler.
> Der er almindeligvis begrænsninger med at skrive programmer i sprog der
> baserer sig på stak overførsel af parametre som f.eks. C og C++ til 8051.
> Det er f.eks. ikke ualmindeligt at rekursive kald er forbudt, simpelt hen
på
> grund af CPU arkitekturen understøtter det dårligt (i forhold til f.eks.
en
> 8080).

Jer arbejder med dem idag (det var derfor lige den processor sprang frem ud
af skabet). Under tvang programmerer jeg dem i Pascal - og så slipper man jo
helt uden om stack problemet på en elefant måde.

> Hvilken information hører typisk til en stepmotor ?
> Noget med hvilket hardware interface (port A, B etc) den sidder på.
> Den aktuelle position.
>
> Om man gemmer de information i seperate variable, end datastruktur i C
eller
> et objekt i C++ spiller ingen performance mæssig rolle.

Nej - så længe man ikke begynder at bruge virtuelle metoder.

> Hvis man vil drage fordel af at på compileringstidspunktet ved om det er
> port A eller port B stepmotoren sidder på, er dermed fjerne en variabel,
så
> kan det tilsvarende gøres i C++ ved at lade klassen være en template
klasse,
> og porten være en template parameter.

Her kommer vi så ud i noget, godtnok smart, men mindre overskuelig kode.
Kan det gøres nemmere end

#include <hvaddernumåtteværebrugfor>

unsigned int position;
unsigned int steps;

void StepRight;
{
-kode-
position++;
}

void StepLeft;
{
-kode-
position--;
}

int main()
{
while not afslut
{
-styring-
}
return 0;
}

Den grimme del; "styring"; slipper du jo ikke for med objekt orientering.

> Selve det at køre med motoren, og følge et hastighedsprofil vil være det
> samme uanset om man skriver det i C eller C++.

Ja, men C ville være mere simpelt.

> > Så kan vi gå op og styre to stepmotorer med samme processor. C, OO
> > C++, eller asm?
> > Tre stepmotorer? Ti? 100?
>
> Jeg tror egentlig ikke det spiller den store rolle.
> Hvis man har flere forkellige typer kørselselsprofiler vil nok spille en
> større rolle.

Det jeg mente var, at med flere motorer ville man, i OO C++, kunne genbruge
sin step kode. Det ville man ikke kunne i det givne eksempel.
Jeg ville nok foretrække objekt læsningen allerede ved motor nr 2.

---

"Nicolai Hansen" <nic@aub.dk> wrote:
> > Tag eksemplet:
> >
> > <C++ kode>
> > #include <cstdio>
> >
> > class base_application
> > {
> > public:
> > base_application(const char* greeting)
> > { std::printf(greeting); }
> > };
>
> Her snyder du jo lidt og lader din constructor give dit output ;)

Hvorfor er det snyd ?
Hvordan syntes du at det skal se ud for at det ikke er snyd, men samtidig er
sammenligneligt med et traditionelt "Hello World" program (kan kun udskrive
een gang, ikke fleksibelt med hensyn til hvad der udskrives etc.) ?

Min første tanke fra en statisk member funktion i en klasse uden nedarvning:

class application
{
public:
static void greetings()
{ std::printf("Hello World");
};

men den ville jeg have forventet at den ville blive beskyldt for "snyd".
Der måtte gerne være lidt mere objekt orientering (nedarvning, indkapsling
og et instans) for at understrege pointen.
Det viste jeg så et eksempel på, hvor der _ingen_ overhead var.

> Hvis det nu skulle være sådan rigtigt ville du have en
> base_application::greeting metode - og så ville vi have et anderledes asm
> program i enden

Ok - lad os prøve.

> (ok, igen - en god compiler vil da måske nok kunne lave det
> samme ud af det)

Naturligvis - og det er ikke overraskende.
Det kræver ikke en specielt avanceret compiler, for at få nul eller nær nul
overhead.

Tag eksemplet

<C++ kode>
#include <cstdio>

template <typename T>
class base_application
{
public:
void greeting() const
{ std::printf(static_cast<const T*>(this)->greeting_text()); }
};

class hello_world_application : public
base_application<hello_world_application>
{
public:
const char* greeting_text() const
{ return "Hello World"; }
};

int main(int argc, char* argv[])
{
hello_world_application hwa;
hwa.greeting();
}
</C++ kode>

som måske er tættere på hvad du ønskede:
En basis klasse, der i source-koden ikke kender den afledte, men alligevel
kræver at få teksten der skal skrives ved at kalde en funktion i den afledte
klasse.
Basis klassen _kræver_ at den afledte klasse har en const metode
"greeting_text" der ikke tager nogen parametre og som returnere en "const
char*".

Det er et eksempel compile-time polymorphy (det er velkendt - f.eks. er det
beskrevet i februar 1995) - i modsætning til run-time polymorphy (typisk
virtuelle metoder).
Bemærk at de static_cast der bruges er ufarligt - hvis kravet til nedarvning
ikke er overhold, vil det give en compile-time fejl.

Der er igen _ingen_ grund overhovedet til at der skulle kræve een byte mere
eller een clock cycle mere end det helt banale "Hello world" program.
En test på en PC viser da også:
<ASM listing>
int main(int argc, char* argv[])
{
hello_world_application hwa;
hwa.greeting();
0040100C push offset string "Hello World" (40A000h)
00401011 call printf (401020h)
00401016 xor eax,eax
00401018 pop ecx
00401019 mov esp,ebp
0040101B pop ebp
0040101C ret
</ASM listing>

Der er _ikke_ noget at komme efter med hensyn til performance.

Det klassiske eksempel på betydning af compile-time polymorphi er en
sammenligning af quick-sort implementeringer i C funktionen "qsort" og C++
funktionen "sort<T>".
Idet qsort skal kunne sortere alle typer, og C ikke har compile-time
polymorphi opererer den med en peger til en call-back funktion og
type-usikkert med "void*".
Da C++ har compile-time polymorphi, kan dele af "sort<T>" vente med at blive
bundet til T er kendt. Der er derfor ikke nogen grund til at arbejde
type-usikkert og sammenlignings funktion (som typisk er simpel i forhold til
sorterings algoritmen) kan blive inlinet direkte i "sort<T>" funktionen.
Konsekvensen er at "sort<T>" er _hurtigere_ end "qsort", såfremt de bruger
samme quick-sort algoritme og med compilere med samme evne til optimering.
Det har ikke noget med objekt orientering at gøre, men derimod med bindings
tidspunktet.

>
> > Jeg mener ikke at der nødvendigvis er nogen nedre grænse.
> > Hvis det kan tillades at bruge C kan det også tillades at bruge objekt
> > orienteret programmering (hvis det er passende for løsningen) i C++.
> > Naturligvis kan man mangle tilstrækkelige værktøjer, eller være
underlagt
> > firma eller projekt politik - men det er en anden snak.
>
> Her glemte jeg nok at indføre et "her stopper jeg med at snakke
> performance".

Betyder det at vi nu, i modsætning til dit tidligere udsagn, er enige om at
performance ikke er en hindring for at anvende objekt orienteret
programmering i små embeddede computere ?

Der findes mange gode grunde til ikke at anvende C++ og objekt orienteret
programmering:
* Problemet løses ikke bedst objekt orienteret (som "Hello World")
* Der findes ikke værktøjer (compiler, debugger etc.) der understøtter
target godt
* Organisationen har standardiseret på et andet værktøjsæt (du nævner at
du _skal_ bruge Pascal)
* Kunden kræver anvendelse af et andet værktøjsæt
* Organisationen er ikke i besiddelse af tilstrækkelig viden om C++ og
objekt orienteret programmering (selvom den viden findes i litteraturen)

>
> Det som jeg mente, også med 8051 diskussionen var at programmerne kan være
> hurtigere at programmere, og mere overskuelige i C end i OO C++. Så længe
de
> er små.

Hvorfor ?
Kan du være mere specifik.

F.eks. er RAII idiomet i C++ _meget_ nyttigt også til embedded brug.

Et klassisk eksempel er låsning af en mutex i et multi-trådet embedded
system.
Problemet er at huske at frigive låsen igen - altid!

Med procedural programmering i C vil man f.eks. skrive (ikke compileret
kode)

int foo()
{
int foo_result = 0; // success
lock_mutex(mutex);

resource_handle_1 rh1 = aquire_resource_1();
if(rh1) {
resource_handle_2 rh2 = aquire_resource_2();
if(rh2) {
resource_handle_3 rh3 = aquire_resource_3();
if(rh3) {
// .. do the processing foo is supposed to do
release_resource_3(rh3);
}
else
foo_result = 3;
release_resource_2(rh2);
}
else
foo_result = 2;
release_resource_1(rh1);
}
else
foo_result = 1;

unlock_mutex(mutex);
return foo_result;
}

i forhold til

int foo()
{
mutex_locker ml(mutex); // constructor lock/destructor unlocks
resource_type_1 rt1;
if(!rt1)
return 1;
resource_type_2 rt2;
if(!rt2)
return 2;
resource_type_3 rt3;
if(!rt3)
return 3;

// do the processing foo is supposed to do
return 0;
}

Igen påstår jeg at der er _ingen_ grund til at der er forskel i performance.
Hvad syntes du er mest overskueligt ?
Det vil iøvrigt være nærliggende at constructoren til resource_type_x smider
en exception, hvis den fejler, selvom det _kan_ have performance overhead -
især når exceptionen bliver smidt. Overskueligheden øges, og muligheden for
at overse en fejl formindskes.

Det er klart at hvis man kender C godt og ikke kender objekt orienteret
programmering med C++, så vil en C løsning forkomme mere overskuelig.
Det rigtige værktøj kan ikke findes alene ud fra opgaven, uden hensyntagen
til den organisation og de mennesker der skal bruge det.

Personligt oplever jeg dansk som langt mere forståeligt end kinesisk - men
jeg ved også at over 1 milliard mennesker er uenig med mig

[8<8<8<]
> Jer arbejder med dem idag (det var derfor lige den processor sprang frem
ud
> af skabet). Under tvang programmerer jeg dem i Pascal - og så slipper man
jo
> helt uden om stack problemet på en elefant måde.

Pascal vil da også gerne overføre parametre på stakken, ligesom C.
Hvordan håndterer compileren det at 8051 ikke er god til det ?
Har den en separat stak til kalde parametre, som så er langsom at tilgå ?
Har den fast allokerede (globale) variable for alle parametre til alle
funktioner ?
Er der f.eks. begrænsning på ikke at tillade recursive kald ?

[8<8<8<]
> > Om man gemmer de information i seperate variable, end datastruktur i C
> eller
> > et objekt i C++ spiller ingen performance mæssig rolle.
>
> Nej - så længe man ikke begynder at bruge virtuelle metoder.

Det er _ikke_ et rimeligt udsagn.

Hvis man har brug for at håndtere flere forskellige _typer_ stepmotor
ensartet har man brug for run-time polymorphi - f.eks. virtuelle metoder
eller pointer til funktioner. I så fald giver virtuelle metoder (typisk) den
bedst mulige performance (den samme som pegere til funktioner).

Hvis man ikke har brug for run-time polymorphi, men bruger det alligevel, så
for man et performance overhead.
Er det overraskende ?

Hvis man skal skrive programmer der er tæt på det optimale med hensyn til
pladsforbrug og kørselstid, skal man lade være med at lave ting som man ikke
har brug for - man skal tænke sig mere grundigt om end hvis man kan svine
med resourcerne.
Er det overraskende ?

Jeg må atter henvise til bogen
Multi-Paradigm DESIGN for C++
James O. Coplien
ISBN 0-201-82467-1
for en grundig og interessant gemmengang af bl.a. hvordan de forskellige
bindingsformer (statisk, compile-time polymorfisk, run-time polymorfisk)
relaterer sig til hinanden, og hvornår det er passende at bruge hvad.

>
> > Hvis man vil drage fordel af at på compileringstidspunktet ved om det er
> > port A eller port B stepmotoren sidder på, er dermed fjerne en variabel,
> så
> > kan det tilsvarende gøres i C++ ved at lade klassen være en template
> klasse,
> > og porten være en template parameter.
>
> Her kommer vi så ud i noget, godtnok smart, men mindre overskuelig kode.

Hvor er det mindre overskueligt ?
Fordi man ikke er vant til templates ?
Igen kommer det an på ens baggrund - dansk vs. kinesisk.

Der er andre krav til koden (optimal performance, parametrisk angivelse af
porten), så den kommer til at se anderledes ud.
Er det overraskende ?

[8<8<8<]
> Den grimme del; "styring"; slipper du jo ikke for med objekt orientering.

Netop.

>
> > Selve det at køre med motoren, og følge et hastighedsprofil vil være det
> > samme uanset om man skriver det i C eller C++.
>
> Ja, men C ville være mere simpelt.

Jeg forstår ikke hvad du mener.
Hvorfor (vær konkret) ?

[8<8<8<]
> Det jeg mente var, at med flere motorer ville man, i OO C++, kunne
genbruge
> sin step kode. Det ville man ikke kunne i det givne eksempel.
> Jeg ville nok foretrække objekt læsningen allerede ved motor nr 2.

I C vil man formodentlig lave en datastruktur der indeholder
stepmotorens adresse og position, og så allokere sådan en struktur for hver
stepmotor.

Venlig hilsen

Mogens Hansen

---

> > > Jeg mener ikke at der nødvendigvis er nogen nedre grænse.
> > > Hvis det kan tillades at bruge C kan det også tillades at bruge objekt
> > > orienteret programmering (hvis det er passende for løsningen) i C++.
> > > Naturligvis kan man mangle tilstrækkelige værktøjer, eller være
> underlagt
> > > firma eller projekt politik - men det er en anden snak.
> >
> > Her glemte jeg nok at indføre et "her stopper jeg med at snakke
> > performance".
>
> Betyder det at vi nu, i modsætning til dit tidligere udsagn, er enige om
at
> performance ikke er en hindring for at anvende objekt orienteret
> programmering i små embeddede computere ?

Performance kommer mere an på compileren end på valg af programmerings
sprog.
Det var heller ikke så meget performance jeg ønskede at kommentere med mit
indlæg.

> Der findes mange gode grunde til ikke at anvende C++ og objekt orienteret
> programmering:
> * Problemet løses ikke bedst objekt orienteret (som "Hello World")

Dette er min pointe - jeg er glad for vi er enige.

> * Der findes ikke værktøjer (compiler, debugger etc.) der understøtter
> target godt
> * Organisationen har standardiseret på et andet værktøjsæt (du nævner at
> du _skal_ bruge Pascal)

Ja, min chef kan ikke forstå C kode :)

> * Kunden kræver anvendelse af et andet værktøjsæt
> * Organisationen er ikke i besiddelse af tilstrækkelig viden om C++ og
> objekt orienteret programmering (selvom den viden findes i litteraturen)

Litteratur er ikke nødvændigvis viden. Der findes også masser af god
litteratur om molekylær elektronik - derfor ser jeg det ikke som en
nødvændighed at min omverden ved noget som helst om dette.

> > Det som jeg mente, også med 8051 diskussionen var at programmerne kan
være
> > hurtigere at programmere, og mere overskuelige i C end i OO C++. Så
længe
> de
> > er små.
>
> Hvorfor ?
> Kan du være mere specifik.

Se det givne eksempel - kan du gøre det nemmere, hurtigere, mere
overskueligt i C++?

> Igen påstår jeg at der er _ingen_ grund til at der er forskel i
performance.
> Hvad syntes du er mest overskueligt ?

Du laver jo lidt om ...

int foo()
{
int foo_result = 0; // success
lock_mutex(mutex);

resource_handle_1 rh1 = aquire_resource_1();
if(!rh1)
{
release_resource_1(rh1);
return 1;
}

etc. der skal sikkert være noget unlocking inden return 1. Så er vi ligeså
overskuelige som i C++.

> Det vil iøvrigt være nærliggende at constructoren til resource_type_x
smider
> en exception, hvis den fejler, selvom det _kan_ have performance
overhead -
> især når exceptionen bliver smidt. Overskueligheden øges, og muligheden
for
> at overse en fejl formindskes.

et integer svar fra metoden kan jo gøre det samme i C metoden.

resource_handle_1 hl1;
if (aquire_resource(hl1)!=0)
{
---
}

> > Jer arbejder med dem idag (det var derfor lige den processor sprang frem
> ud
> > af skabet). Under tvang programmerer jeg dem i Pascal - og så slipper
man
> jo
> > helt uden om stack problemet på en elefant måde.
>
> Pascal vil da også gerne overføre parametre på stakken, ligesom C.
> Hvordan håndterer compileren det at 8051 ikke er god til det ?

Vores 8051 Pascal bruger hukommelses adressering. Det mener jeg nu også at
de fleste "gamle" Pascal compilere gør. Dette er så vidt jeg husker en del
af Pascal ISO'en. Det er også derfor at Pascal overfører structs, ikke
pointere til structs. (rekursion i Pascal var noget som vistnok kom senere;
extended pascal standard eller noget i den dur)

> Har den en separat stak til kalde parametre, som så er langsom at tilgå ?
> Har den fast allokerede (globale) variable for alle parametre til alle
> funktioner ?

Næsten, ja.

> Er der f.eks. begrænsning på ikke at tillade recursive kald ?

Ja; rekursion er nok ikke det aller smarteste at lave på en 8051'er ;)

*snip en masse kode og eksempler*

Du siger jo selv tidligere at valget "objekt C++" ikke er det rigtige for et
"hello world" program.

Det er min mening om dette her - man skal væge sit programmerings sprog
efter opgaven. Dette er ikke nødvændigvis OO C++, nogle gange er C eller asm
at foretrække (eller Pascal, eller Java eller eller eller). Hvert sprog har
sine styrker, OG svagheder. Jeg vil gerne medgive at C++ ikke har mange
svagheder, men de findes :)
Og, nej, jeg gider ikke sidde og remse op :)

---

"Nicolai Hansen" <nic@aub.dk> wrote:

[8<8<8<]
> Performance kommer mere an på compileren end på valg af programmerings
> sprog.

Nej - begge dele er væsentlige.
Sproget skal være designet med performance for øje for at kunne hamle op med
sprog som C og FORTRAN.
Dertil kommer at compileren skal være af en ordentlig kvalitet, for at man
får indfriet forventningerne.

Man vil formodentlig aldrig kunne lave en compiler til f.eks. Python, der
kan generere lige så effektiv kode som C - og det har heller aldrig være
meningen.

> Det var heller ikke så meget performance jeg ønskede at kommentere med mit
> indlæg.

Kig lige tilbage i tråden.
Din oprindelige påstand var at et objekt orienteret "Hello World" program
vil give dårligere performance end den tilsvarende funktionalitet
implementeret med procedural programmering.
Denne påstand er blevet tilbagevist.

[8<8<8<]
> int foo()
> {
> int foo_result = 0; // success
> lock_mutex(mutex);
>
> resource_handle_1 rh1 = aquire_resource_1();
> if(!rh1)
> {
> release_resource_1(rh1);
> return 1;
> }
>
> etc. der skal sikkert være noget unlocking inden return 1.

Nemlig - ellers virker programmet ikke.
Det er den unlocking der sker automatisk og garanteret med anvendelse af
RAII i C++. Der er simpelt hen ikke nogen _mulighed_ for at glemme det.

> Så er vi ligeså
> overskuelige som i C++.

Den køber jeg ikke.
Skriv først hele koden, svarende til hvad jeg vist, så den vil virke:

int foo()
{
int foo_result = 0; // success
lock_mutex(mutex);

resource_handle_1 rh1 = aquire_resource_1();
if(!rh1) {
unloc_mutex(mutex);
return 1;
}

resource_handle_2 rh2 = aquire_resource_2();
if(!rh2) {
release_resource_1(rh1);
unloc_mutex(mutex);
return 2;
}

resource_handle_3 rh3 = aquire_resource_3();
if(!rh3) {
release_resource_2(rh2);
release_resource_1(rh1);
unlock_mutex(mutex);
return 3;
}

// .. do the processing foo is supposed to do
release_resource_3(rh3);
release_resource_2(rh2);
release_resource_1(rh1);
unlock_mutex(mutex);
return 0;
}

og kig så på den igen.


Venlig hilsen

Mogens Hansen

---

> > Performance kommer mere an på compileren end på valg af programmerings
> > sprog.
>
> Nej - begge dele er væsentlige.
> Sproget skal være designet med performance for øje for at kunne hamle op
med
> sprog som C og FORTRAN.
> Dertil kommer at compileren skal være af en ordentlig kvalitet, for at man
> får indfriet forventningerne.
>
> Man vil formodentlig aldrig kunne lave en compiler til f.eks. Python, der
> kan generere lige så effektiv kode som C - og det har heller aldrig være
> meningen.

Ja, ok; her diskuterede vi nu C og C++.

> > int foo()
> > {
> > int foo_result = 0; // success
> > lock_mutex(mutex);
> >
> > resource_handle_1 rh1 = aquire_resource_1();
> > if(!rh1)
> > {
> > release_resource_1(rh1);
> > return 1;
> > }
> >
> > etc. der skal sikkert være noget unlocking inden return 1.
>
> Den køber jeg ikke.
> Skriv først hele koden, svarende til hvad jeg vist, så den vil virke:
>
> int foo()
> {
> int foo_result = 0; // success
> lock_mutex(mutex);
>
> resource_handle_1 rh1 = aquire_resource_1();
> if(!rh1) {
> unloc_mutex(mutex);
> return 1;
> }
>
> resource_handle_2 rh2 = aquire_resource_2();
> if(!rh2) {
> release_resource_1(rh1);
> unloc_mutex(mutex);
> return 2;
> }
>
> resource_handle_3 rh3 = aquire_resource_3();
> if(!rh3) {
> release_resource_2(rh2);
> release_resource_1(rh1);
> unlock_mutex(mutex);
> return 3;
> }
>
> // .. do the processing foo is supposed to do
> release_resource_3(rh3);
> release_resource_2(rh2);
> release_resource_1(rh1);
> unlock_mutex(mutex);
> return 0;
> }
>
> og kig så på den igen.

Man kunne også lave noget smartere;

int foo()
{
int foo_result = 1;
lock_mutex(mutex);

resource_handle_1 rh1 = aquire_resource_1();
resource_handle_2 rh2 = aquire_resource_2();
resource_handle_3 rh2 = aquire_resource_3();
resource_handle_4 rh2 = aquire_resource_4();

if ((rh1 && foo_result++) && (rh2 && foo_result++) && (rh3 &&
foo_result++) && (rh4 && foo_result++))
{
lav_ting;
foo_result=0;
}

unlock/release;

return foo_result;
}

Noget i den dur

Den C++ kode du gav oprindeligt; vil den ikke lave en masse objekter på
stack'en?

---

"Nicolai Hansen" <nic@aub.dk> wrote:

[8<8<8<]
> Man kunne også lave noget smartere;
>
> int foo()
> {
> int foo_result = 1;
> lock_mutex(mutex);
>
> resource_handle_1 rh1 = aquire_resource_1();
> resource_handle_2 rh2 = aquire_resource_2();
> resource_handle_3 rh2 = aquire_resource_3();
> resource_handle_4 rh2 = aquire_resource_4();
>
> if ((rh1 && foo_result++) && (rh2 && foo_result++) && (rh3 &&
> foo_result++) && (rh4 && foo_result++))
> {
> lav_ting;
> foo_result=0;
> }
>
> unlock/release;
>
> return foo_result;
> }
>
> Noget i den dur

Du mangler at frigøre resource igen, afhængigt af hvormange der lykkedes at
få fat på

>
> Den C++ kode du gav oprindeligt; vil den ikke lave en masse objekter på
> stack'en?

Jo - 5 (mutex låsen og de 4 resourcer).
De 4 resource, vil fylde det samme som "resource_handle_x".
Mutex låse-objektet vil principielt fylde minimum 1 byte og måske mere
afhængig af alignment.
Men hvis man ikke tager adressen af objektet (som _skal_ være unik), vil en
rimelig compiler kunne optimere det væk - som jeg viste i de "objekt
orienteret hello world" eksempler.

Venlig hilsen

Mogens Hansen

---

> Du mangler at frigøre resource igen, afhængigt af hvormange der lykkedes
at
> få fat på

Ah - det var nu meningen som en del af unlock/release. Og jeg ville lave
alle release metoderne til selv at tjekke om der var en låst resource eller
ej

> > Den C++ kode du gav oprindeligt; vil den ikke lave en masse objekter på
> > stack'en?
>
> Jo - 5 (mutex låsen og de 4 resourcer).
> De 4 resource, vil fylde det samme som "resource_handle_x".

Jo... men her har vi så problemet. De fire globale resource_handle_x fylder
en fast mængde hukommelse som vi kender på forhånd, og som compileren er
bekendt med når den laver vores program.
De fire resources som du laver bliver dannet på stacken, og der er ingen
måde hvorpå hverken du eller dit program "på forhånd" kan vide hvormeget
hukommelse du optager. Dette er jo ret skidt på små systemer (hellere
reservere 4K bytes, end at reservere noget dynamisk som kan fylder OP TIL
4K, da man i det sidstnævnte tilfælde først vil finde ud af at man er løbet
tør for hukommelse når programmet opfører sig underligt).
Nu ka jeg så ikke huske hvilket et system snakken startede med, så måske er
det ligegyldigt :)

> Mutex låse-objektet vil principielt fylde minimum 1 byte og måske mere
> afhængig af alignment.

"Måske mere" lyder ikke som rare ord - men forklaringen er god nok :) Jeg
vil gætte på at vi igen er oppe og snakke 80x86 processorer :)

---

On Mon, 19 Jan 2004 16:50:38 +0100, Nicolai Hansen <nic@aub.dk> wrote:

>> Mutex låse-objektet vil principielt fylde minimum 1 byte og måske mere
>> afhængig af alignment.
>
> "Måske mere" lyder ikke som rare ord - men forklaringen er god nok :) Jeg
> vil gætte på at vi igen er oppe og snakke 80x86 processorer :)

Det skal nok naermere vaere: ''Mutex laase vil altid fylde til
naermeste alignment''. Ihvertfald paa alle moderne arkitekturer (hvor
80x86 IMO ikke er medlem).


--
Jesper

---

"Nicolai Hansen" <nic@aub.dk> wrote:
> > Du mangler at frigøre resource igen, afhængigt af hvormange der lykkedes
> at
> > få fat på
>
> Ah - det var nu meningen som en del af unlock/release. Og jeg ville lave
> alle release metoderne til selv at tjekke om der var en låst resource
eller
> ej

Men din funktion har stadig ikke samme opførsel.
Hvad hvis resource_2 er en forudsætning for at man må prøve at få resource_3
?

>
> > > Den C++ kode du gav oprindeligt; vil den ikke lave en masse objekter
på
> > > stack'en?
> >
> > Jo - 5 (mutex låsen og de 4 resourcer).
> > De 4 resource, vil fylde det samme som "resource_handle_x".
>
> Jo... men her har vi så problemet. De fire globale resource_handle_x

Øhh - de var ikke globale i dine eksempler.
De var også allokeret på stakken (automatiske variable).

[8<8<8<]
> > Mutex låse-objektet vil principielt fylde minimum 1 byte og måske mere
> > afhængig af alignment.
>
> "Måske mere" lyder ikke som rare ord - men forklaringen er god nok :) Jeg
> vil gætte på at vi igen er oppe og snakke 80x86 processorer :)

Det er jo ikke anderledes end at man ikke kan vide hvor stor en struktur

struct foo
{
char c;
int i;
};

alene ved at kigge på den, selv hvis man kender størrelsen af de enkelte.
Hardwaren kan nemt sætte begrænsninger på alignment. At tilgå en integer på
en ulige adresse vil på nogen typer hardware give "bus error" og processoren
stoppe.

Venlig hilsen

Mogens Hansen

---

> > > > Den C++ kode du gav oprindeligt; vil den ikke lave en masse objekter
> på
> > > > stack'en?
> > >
> > > Jo - 5 (mutex låsen og de 4 resourcer).
> > > De 4 resource, vil fylde det samme som "resource_handle_x".
> >
> > Jo... men her har vi så problemet. De fire globale resource_handle_x
>
> Øhh - de var ikke globale i dine eksempler.
> De var også allokeret på stakken (automatiske variable).

Øhh - det har du ret i. Jeg ka ikke huske hvad jeg selv laver. Ikke at der
er noget nyt i det.

> Det er jo ikke anderledes end at man ikke kan vide hvor stor en struktur
>
> struct foo
> {
> char c;
> int i;
> };
>
> alene ved at kigge på den, selv hvis man kender størrelsen af de enkelte.
> Hardwaren kan nemt sætte begrænsninger på alignment. At tilgå en integer
på
> en ulige adresse vil på nogen typer hardware give "bus error" og
processoren
> stoppe.

Nej, det var heller ikke alignment på mutex'en jeg tænkte på. Mere på de
stack allokerede variable. Men min pointe faldt lidt til jorden fordi jeg
selv brugte samme metode i mit eksempel :)

---

---

Jonas Meyer wrote:
>
> Hvorfor skulle de blive inlinet? Det burde de vel kun blive
> hvis man giver den hint til det(enten ved 'inline' eller
> ved at putte definition af funktionen i klasse definitionen)??
Øhh, de er en at finde i en header fil, og hver fil der includerer dem
får en instance af functionen.

Jeg er ret sikker på at :

template<typename N> N template_adding( N a, N b) { return a + b; }

bliver inlinet, men jeg kan jo tage fejl

/BL

---

"Bo Lorentsen" <bl@nospam.lue.dk> wrote:

[8<8<8<]
> Jeg er ret sikker på at :
>
> template<typename N> N template_adding( N a, N b) { return a + b; }

Ikke mere end

int int_add(int a, int b) { return a+b; }

hvilket vil sige, at normalt vil man ikke forvente at den er inlinet.
Omvendt er der ikke noget til hinder for at en kompiler kan finde på at
inline den - og der er nogen som sikkert kan finde på det, også på tværs af
compilation units!



Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> hvilket vil sige, at normalt vil man ikke forvente at den er inlinet.
Nu når du nævner det, tror jeg faktisk linkeren vil klage over en double
implimentation.

Det er functioner der er implimenteret i en classe defination der er
implicit inline.

> Omvendt er der ikke noget til hinder for at en kompiler kan finde på at
> inline den - og der er nogen som sikkert kan finde på det, også på tværs af
> compilation units!
Jeg kan ikke huske andet end reglen om classe def. func., mht implicit
inline, men jeg tvivler på at det er noget man gør andre steder, men
templates kunne være et oplagt sted

/BL

---

"Bo Lorentsen" <bl@nospam.lue.dk> wrote:
> Mogens Hansen wrote:

[8<8<8<]
> > Omvendt er der ikke noget til hinder for at en kompiler kan finde på at
> > inline den - og der er nogen som sikkert kan finde på det, også på tværs
af
> > compilation units!
> Jeg kan ikke huske andet end reglen om classe def. func., mht implicit
> inline, men jeg tvivler på at det er noget man gør andre steder, men
> templates kunne være et oplagt sted

Det er rigtigt.
Men det jeg mente var at i sidste ende er det compilerens beslutning hvilke
funktioner der skal inlines.
Når man skriver inline, er det blot en høflig forespørgsel til compileren om
at inline den. Compileren behøver ikke at gøre det.
Omvendt mener jeg ikke at der er noget formelt (i forhold til C++
standarden) i vejen for at en funktion faktisk bliver inlinet, selvom man
ikke har skrevet den som en inline funktion.

Venlig hilsen

Mogens Hansen

---

Bo Lorentsen <bl@nospam.lue.dk> writes:

> Nu når du nævner det, tror jeg faktisk linkeren vil klage over en
> double implimentation.

GCC og Borland C++ markerer den slags funktioner som "må gerne optræde
flere gange" i objektfilerne, og linkeren for de to systemer vil så
bare vælge en tilfældig af de (forhåbentlig ens) implementationer.

Sun (og gcc -repo) placerer den slags i et særlig repository, så
compileren holder styr på at de kun bliver genereret en gang.

> Jeg kan ikke huske andet end reglen om classe def. func., mht implicit
> inline, men jeg tvivler på at det er noget man gør andre steder, men
> templates kunne være et oplagt sted

GCC gør altid funktioner inline når den syntes det er en god ide. Og
ignorerer inline når den syntes det er en dårlig ide, eller ikke kan
finde ud af det. Det tror jeg egentlig også de øvrige compilere gør.

---

Per Abrahamsen wrote:

> GCC og Borland C++ markerer den slags funktioner som "må gerne optræde
> flere gange" i objektfilerne, og linkeren for de to systemer vil så
> bare vælge en tilfældig af de (forhåbentlig ens) implementationer.
Det må jeg lege lidt med en dag i nær fremtid, lyder som den rigtige ide.

> Sun (og gcc -repo) placerer den slags i et særlig repository, så
> compileren holder styr på at de kun bliver genereret en gang.
Åhh, ja det er ikke det letteste at danse med, men det er da til at
forstå. Det er heldigvis to år siden jeg skulle bruge den compiler.

/bl

---

Bo Lorentsen <bl@nospam.lue.dk> writes:

> Mogens Hansen wrote:
>
>> Men det betyder _ikke_ at der kommer assembler kode til 2 foo<int>() i det
>> endelige program.
>
> Hmm, well --- kun hvis det er inline functioner ?

Hvis de er inline vil der måske være spor af assemblerkoden til
foo<int>() de steder den bliver kaldt. Når jeg skriver "spor af"
skyldes det at koden vil være optimeret til de enkelte steder
funktionen bliver brugt, og nogen steder måske helt optimeret væk.
Den slags optimering er faktisk den egentlige fordel ved inline
funktioner, selve funktionskaldet er normalt en biting.

Hvis de ikke er inline vil funktionen være implementeret præcis en
gang i det endelige program, og der vil være et funktionskald de
steder den bliver brugt.

Det kan sagtens kombineres, så nogen steder er funktionen gjort
inline, og andre er den implementeret som et kald i maskinkode.

> Det ville være et rimeligt sted, jeg har blot ikke overblik over hvem
> der kan det for tiden. Jeg bruger selv gcc og derved collect2, og jeg
> har antaget (på bases af kode størrelse) at den ikke finder
> doubletter, men jeg ved det faktisk ikke.

GNU ld finder dupleter når den genererer ELF kode. ELF er et
objektformat der bruges på de fleste moderne systemer som SunOS, Linux
og FreeBSD. MS Windows bruger COFF (et ældre Unix format), og MacOS X
bruger vistnok Mach-O som er sin helt egen ting.

Gamle versioner af GCC og muligvis GCC til visse ikke-ELF maskiner
finder ikke dupletter. Så vidt jeg husker bruger de nogen fæle
heuristiker eller hints til at vælge en objekt fil at generere koden
i.

---

Hej Mogens

> De fleste elektroingeniør uddannelser vil formodentlig kunne tilbude noget
> sådant.

Så ville jeg nok nærmere foretrække elektronikingeniør elektro er så
"beskidt" hehe

> Så vidt jeg husker har (havde) Ingeniør Højskolen i Århus og Århus
> Universitet et samarbejde om at uddanne dataloger (cand. scient.),
specielt
> med henblik på den embeddede verden, som så spændende og fornuftigt ud.

Ok

> Hvor ser du en modsætning mellem objekt orienteret programmering og
embedded
> elektronik ?

Fordi alle de embedded projekter jeg har arbejdet med aldrig ville tillade
et objekt orienteret miljø
(det ville simpelthen være totalt overkill)

F.eks. har jeg lavet en DC motor styring i en processor med 512 BYTE program
memory og 64 BYTE ram
i den processor er det lige før at alm. C er "overkill" man når lige at
initializere processoren så er man "out of memory"

men normalt arbejder jeg under følgende forhold:

32KB Ram og 127 KB program hukommelse og er vant til at skrive i Assembler
eller C.
heldigvis er compileren jeg bruger (CodeVisionAVR) bedre til at optimere fra
C til assembler end jeg selv er
i de fleste tilfælde så her er C "dejligt".

når du siger C++ så tænker jeg på "windows programmer" f.eks. vil man have
en knap smider man en "button" ind i på sin
main form osv.. hvis ellers jeg har forstået det rigtigt er C++ en slags
"LEGO programmering" hvor man trækker de ting man
vil have ind på en form og så compiler ... lidt ala noget PLC agtigt
software hvor man trækker gates ind på et ark og så
skriver den koden uden man ser hvad der sker bagved ...

Jeg skriver jo selv alle drivere lige fra display til keyboard, seriel
kommunikation osv.. så man har 100% styr på hvad der foregår eller ikke
foregår hehe
så jeg kan slet ikke se C++ for mig på en embedded platform uden et
styresystem som f.eks. windows CE eller noget i den stil og et styre system
er alt for overkill i de processorere jeg arbejder med og jeg vil også mene
at i 99.9% af alle industrielle problemstillinger bør/skal man ikke anvende
et operativ system
da koden kan skrives smartere uden.

Måske er jeg afspret fra virkeligheden ?

M.v.h.
Lasse Madsen








>
> Objektet orienteret programmering bliver brugt til mange embeddede
systemer.
>
>
> Venlig hilsen
>
> Mogens Hansen
>
>

---

"Lasse Madsen" <Lasse.madsen@elektronik.dk> wrote in message
news:buc7rv$1e8v$1@news.cybercity.dk...

> når du siger C++ så tænker jeg på "windows programmer" f.eks. vil man have
> en knap smider man en "button" ind i på sin
> main form osv.. hvis ellers jeg har forstået det rigtigt er C++ en slags
> "LEGO programmering" hvor man trækker de ting man
> vil have ind på en form og så compiler ... lidt ala noget PLC agtigt
> software hvor man trækker gates ind på et ark og så
> skriver den koden uden man ser hvad der sker bagved ...


> Måske er jeg afspret fra virkeligheden ?

Du er totalt afsporet, C++ har ikke noget med "LEGO programmering" at gøre,
men stiller nogle gode muligheder tilrådighed.

Når man først har brugt nogle af mulighederne i C++, er det meget svært at
nøjes med C.

Men du kan sagtens lave kæmpe programmer med få linier kode, hvis du
misbruger nogle af mulighederne i C++.

---

>Når man først har brugt nogle af mulighederne i C++, er det meget svært at
>nøjes med C.

Kan du give mig et eksempel i C++ som jeg ikke kan gøre med alm. C ?

m.v.h.
Lasse

---

"Lasse Madsen" <Lasse.madsen@elektronik.dk> wrote in message
news:buc9eg$1gia$1@news.cybercity.dk...
> >Når man først har brugt nogle af mulighederne i C++, er det meget svært
at
> >nøjes med C.
>
> Kan du give mig et eksempel i C++ som jeg ikke kan gøre med alm. C ?

Du kan gøre alt i C eller Basic eller Assembler, men måde at gøre det på er
meget forskelligt.

En ting, jeg er meget glad for, er hele klasse og arv begrebet, så slipper
jeg bl.a. for alle de åndsvage switch/case statements, som er en pest hvis
du skal udvide programmet senere, med klasser hægter du bare en ny nedarvet
klasse på.

Operator overloading er også rart sommetider.

Men som jeg skrev i starten, alt kan gøres i C (nogle af de første C++
compilere, laverede faktisk C kode, som så blv kørt igennem en C compiler),
men måden at skreve det på kan være meget forskellig (Du kan også skrive
almindelig C i C++ (næsten)).

---

"Lasse Madsen" <Lasse.madsen@elektronik.dk> wrote:

> >Når man først har brugt nogle af mulighederne i C++, er det meget svært
at
> >nøjes med C.
>
> Kan du give mig et eksempel i C++ som jeg ikke kan gøre med alm. C ?

Kan du give eet eksempel på hvad du kan i C som du ikke kan i assembler
(bortset fra at blive færdig på samme tid og skrive kode der er lige så nemt
at vedligeholde) ?

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:
>
> Kan du give eet eksempel på hvad du kan i C som du ikke kan i assembler
> (bortset fra at blive færdig på samme tid og skrive kode der er lige så nemt
> at vedligeholde) ?

Skrive et program som køres på mange forskellige hardware-platforme
efter oversættelse?

---

"Byrial Jensen" <bjensen@nospam.dk> wrote in message
news:400A37F8.4000408@nospam.dk...
> > Kan du give eet eksempel på hvad du kan i C som du ikke kan i assembler
> > (bortset fra at blive færdig på samme tid og skrive kode der er lige så
nemt
> > at vedligeholde) ?
>
> Skrive et program som køres på mange forskellige hardware-platforme
> efter oversættelse?

Det er så et udsagn med en del forbehold, når du programmere embedded kan
der være rimelig meget hardware specifikt i koden og så er det svært at
flytte den.
Men hvis hovedparten af programmet er algorithmer og den hardware specifikke
del er placeret i et interface modul, så kan det være ret let at flytte.

Men det vil altid være lette at flytte et højsprog, end et assembler
program, til en anden processor.

---

> når du siger C++ så tænker jeg på "windows programmer" f.eks. vil man have
> en knap smider man en "button" ind i på sin
> main form osv.. hvis ellers jeg har forstået det rigtigt er C++ en slags
> "LEGO programmering" hvor man trækker de ting man
> vil have ind på en form og så compiler ... lidt ala noget PLC agtigt
> software hvor man trækker gates ind på et ark og så
> skriver den koden uden man ser hvad der sker bagved ...

Hehe, det er nu ikke C++. Det er MFC og den slags, som er noget tilbehør til
MS Visual C. C++ er nu meget som C, bortset fra at du kan lave objekt
orienteret programmering, og har nogle ekstra muligheder som f.eks.
templates og operator overloads.

> Jeg skriver jo selv alle drivere lige fra display til keyboard, seriel
> kommunikation osv.. så man har 100% styr på hvad der foregår eller ikke
> foregår hehe
> så jeg kan slet ikke se C++ for mig på en embedded platform uden et
> styresystem som f.eks. windows CE eller noget i den stil og et styre
system
> er alt for overkill i de processorere jeg arbejder med og jeg vil også
mene
> at i 99.9% af alle industrielle problemstillinger bør/skal man ikke
anvende
> et operativ system
> da koden kan skrives smartere uden.

Helt enig - et OS kan være rart i nogle henseender, men en klods om benet i
andre.

> Måske er jeg afspret fra virkeligheden ?

Der er ingen sammenhæng mellem C++ og noget som helst operativ system.

Når det er sagt foretrækker jeg også personligt C/Pascal/asm frem for
C++/XPascal/OPascal til små systemer. Blot med den begrundelse at jeg ikke
ser nogen som helst anvendelighed i C++/X/OPascal udvidelserne til det jeg
skal programmere.

---

"Lasse Madsen" <Lasse.madsen@elektronik.dk> wrote:

[8<8<8<]
> > De fleste elektroingeniør uddannelser vil formodentlig kunne tilbude
noget
> > sådant.
>
> Så ville jeg nok nærmere foretrække elektronikingeniør elektro er så
> "beskidt" hehe

Der står ordet "elektroingeniør" på mit diplom.
Så det er formodentlig en anerkendt betegnelse.

[8<8<8<]
> > Hvor ser du en modsætning mellem objekt orienteret programmering og
> embedded
> > elektronik ?
>
> Fordi alle de embedded projekter jeg har arbejdet med aldrig ville tillade
> et objekt orienteret miljø
> (det ville simpelthen være totalt overkill)

Hvorfor ?
Og lad nu være med at sige performance, inden du har læst hele denne tråd
(på dk.edb.programmering) igennem

>
> F.eks. har jeg lavet en DC motor styring i en processor med 512 BYTE
program
> memory og 64 BYTE ram
> i den processor er det lige før at alm. C er "overkill" man når lige at
> initializere processoren så er man "out of memory"

Hvis man hvis man ikke har råd til til at bruge C har man helle ikke råd
til at bruge C++.
Hvis du har råd til at bruge C har du også råd til bruge C++ performance
mæssigt (hvis man bærer sig fornuftigt ad).
Men hvis programmet er så lille som du beskriver, er det formodentlig også
til at overskue.

>
> men normalt arbejder jeg under følgende forhold:
>
> 32KB Ram og 127 KB program hukommelse og er vant til at skrive i Assembler
> eller C.
> heldigvis er compileren jeg bruger (CodeVisionAVR) bedre til at optimere
fra
> C til assembler end jeg selv er
> i de fleste tilfælde så her er C "dejligt".

Ja, det er svært konsistent at hamle op med en god compiler - ikke mindst på
moderne CPU arkitekturer med deres cache, pipelines etc.
Det samme gælder for C++.

Der er ikke noget performance problem i at anvende objekt orienteret
programmering (hvis man finder det passende) med C++ på en platform af den
størrelse.

>
> når du siger C++ så tænker jeg på "windows programmer" f.eks. vil man have
> en knap smider man en "button" ind i på sin
> main form osv.. hvis ellers jeg har forstået det rigtigt er C++ en slags
> "LEGO programmering" hvor man trækker de ting man
> vil have ind på en form og så compiler ... lidt ala noget PLC agtigt
> software hvor man trækker gates ind på et ark og så
> skriver den koden uden man ser hvad der sker bagved ...

Det var en lidt underligt opfattelse af C++.
Sådanne systemer findes naturligvis - men C++ er bestemt _meget_ andet.

>
> Jeg skriver jo selv alle drivere lige fra display til keyboard, seriel
> kommunikation osv.. så man har 100% styr på hvad der foregår eller ikke
> foregår hehe
> så jeg kan slet ikke se C++ for mig på en embedded platform uden et
> styresystem

Hvis du kan forestille dig et embedded system med C, kan jeg forestille mig
det samme system kan bruge C++.

> som f.eks. windows CE eller noget i den stil og et styre system
> er alt for overkill i de processorere jeg arbejder med og jeg vil også
mene
> at i 99.9% af alle industrielle problemstillinger bør/skal man ikke
anvende
> et operativ system
> da koden kan skrives smartere uden.

Jeg har aldrig været med til, eller været ansat i et firma der ikke brugte
et operativ-system til deres embeddede produkter.

Operativsystemer findes i mange størrelser.
Jeg brugte et for over 10 år siden et in-house udviklet operativ system (der
blev genbrugt på tværs af mange forskellige applikationer) til 8051
programmering i assembler - det var en stor hjælp. Det var systemer med af
størrelses ordenen 2-32 kbyte RAM og ROM.
Operativ systemer bliver brugt i utroligt mange embeddede applikationer,
lige fra små hjemme strikkede til store real-time operativsystemer som
wxWorks og QNX.

Venlig hilsen

Mogens Hansen

---

Det kan kun være Datateknik på aalborg uni du leder efter:
http://www.control.auc.dk/~jan/D-info/Præsentation%20af%20Data%203-5%20semester.html
og
http://www.esn.auc.dk

hilsen Mikkel

"Lasse Madsen" <Lasse.madsen@elektronik.dk> skrev i en meddelelse
news:btpeal$qoq$1@news.cybercity.dk...
> Hej ...
>
> Jeg har nu igennem hele min læretid som elektronikfagtekniker udviklet
> software til embedded løsninger i både C og assembler og har store planer
om
> at søge ind på NOEA til august som elektronik teknolog jeg er vild med
> hardware (mere digital end analog ihvertfald) især når den kombineres med
> software jeg har kigget lidt rundt på nettet men ikke rigtigt funden det
jeg
> søger ...
>
> Findes der nogle uddannelser her i landet, der er programmerings
orienteret
> inden for embedded verden ? her tænker jeg meget på C jeg er ikke så
> interesseret i alt sådan noget windows programmerings "fis" selvfølgelig
er
> C det samme men vil egentligt helst undgå objekt orienteret programmering
da
> det er embedded elektronik jeg interessere mig for og ønsker at arbejde
med
> frem for PC platforme osv.man lærer selvfølgelig nye programmerings
"tricks"
> i C hele tiden og bliver bedre og bedre men jeg syntes at jeg mangler
noget
> bevis på kompetancen altså noget papir af en art ... det hjælper jo ikke
at
> man selv syntes man er en mester hvis man bliver sorteret fra i bunken
over
> CV'er fordi man ikke har noget papir på ens kunnen bortset fra udtalelser
> osv... og man kan vel altid lære noget nyt
>
> M.v.h.
> Lasse Madsen
>
>

---

Jeg siger tak for de utroligt mange forslag !

det er sørme noget at kigge på, mere end jeg lige regnede med men det jo kun
godt :)


Ingeniør tvilver jeg på at jeg har faglig kompetance til at komme ind på
efter som jeg på det tidspunkt det ville være aktuelt "kun, forhåbentligt"
er elektronik fagtekniker og elektronik teknolog (2årig påbygning til
elektronik fagtekniker/mekaniker udd.) jeg har ingen HF eller andre
suppleringer så mit matematiske niveau ligger på E sammen med de andre fag
dansk engelsk osv....

så skal jeg nok være heldig der findes noget kvote 2000 til den tid hvor alt
med en puls bliver optaget hehe

Tak for hjælpen

M.v.h.
Lasse Madsen

---

On Mon, 12 Jan 2004 20:36:16 +0100, Lasse Madsen wrote:

> Ingeniør tvilver jeg på at jeg har faglig kompetance til at komme ind
> på efter som jeg på det tidspunkt det ville være aktuelt "kun,
> forhåbentligt" er elektronik fagtekniker og elektronik teknolog (2årig
> påbygning til elektronik fagtekniker/mekaniker udd.) jeg har ingen HF
> eller andre suppleringer så mit matematiske niveau ligger på E sammen
> med de andre fag dansk engelsk osv....

Der har Aalborg Universitet et år der hedder Adgangskursus, hvor du som
faguddannet kan supplere op med kurser svarende til en gymnasie. Du kan
vælge at bruge et år eller halvandet år. Det halvandet år fokuserer mere
på projektarbejde, men indeholder ellers alt hvad det et-årige kursus
indeholder.
Jeg har selv taget et et-årig Adgangskursus (AK), og føler mig absolut
lige så godt rustet som dem der kommer fra gymnasiet. Gymnasiefolk har,
efter min erfaring, en bedre almen viden, som også er meget nyttig som
ingeniør.

>
> så skal jeg nok være heldig der findes noget kvote 2000 til den tid hvor
> alt med en puls bliver optaget hehe

Tja, der er ingen adgangskrav til AK udover en faguddannelse eller
relevant erhvervserfaring. Og i Aalborg er der ikke optagelseskvote på
svagstrøms-retningen, så det burde ikke være et problem...

Nu ved jeg ikke hvor du bor, men du kunne undersøge om andre fakulteter
har lignende ordning hvis Aalborg er udelukket.

/Mike
--
My mailserver uses TMDA. (http://tmda.net)
Therefore if you mail me you need to reply to my autogenerated message
to be put in my whitelist. Then I will be able to receive your mail.

---

>
> Nu ved jeg ikke hvor du bor, men du kunne undersøge om andre
> fakulteter har lignende ordning hvis Aalborg er udelukket.
>

Jeg er ret sikker på det forholder sig på samme måde i Odense, se evt:

www.iot.dk

Frederik