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

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
jdjespers.. 500
kyllekylle 500
Bech_bb 500
scootergr.. 300
gibson 300
molokyle 287
10  strarup 270
'Par' i C++
Fra : SørenKJ


Dato : 05-12-01 18:17

I funktionsprogrammeringssprog som Standard ML, kan man lave 'par'
(to-par,tre-par,fire-par, osv) af f.eks. heltal. Sådanne par kan man give
som parametre til funktioner og man kan returnere dem fra funktioner.

Jeg synes at C++ lidt mangler en sådan facilitet. Eller gør det? Jeg synes
det er lidt klodset, at skulle lave en hel klasse (eller 'struct'), hver
gang, man gerne vil returnere et eller andet par. Og arrays synes jeg heller
ikke er smarte i den sammenhæng. Er der noget andet man kan gøre?

vh Søren



 
 
Mogens Hansen (05-12-2001)
Kommentar
Fra : Mogens Hansen


Dato : 05-12-01 19:29


"SørenKJ" <soekija@teliamail.dk> wrote in message
>
> Jeg synes at C++ lidt mangler en sådan facilitet. Eller gør det? Jeg synes
> det er lidt klodset, at skulle lave en hel klasse (eller 'struct'), hver
> gang, man gerne vil returnere et eller andet par. Og arrays synes jeg
heller
> ikke er smarte i den sammenhæng. Er der noget andet man kan gøre?

brug std::pair

Venlig hilsen

Mogens Hansen



Claus Rasmussen (05-12-2001)
Kommentar
Fra : Claus Rasmussen


Dato : 05-12-01 23:34

Mogens Hansen wrote:

> brug std::pair

Sammen med make_pair:

#include <pair.h>

using namespace std;

pair<int, char> f() {
return make_pair(3, 'a');
}

MVH
-Claus


Jonas Meyer Rasmusse~ (05-12-2001)
Kommentar
Fra : Jonas Meyer Rasmusse~


Dato : 05-12-01 21:02

"SørenKJ" <soekija@teliamail.dk> wrote in message
news:3c0e6554$0$10800$d40e179e@nntp03.dk.telia.net...
> I funktionsprogrammeringssprog som Standard ML, kan man lave 'par'
> (to-par,tre-par,fire-par, osv) af f.eks. heltal. Sådanne par kan man give
> som parametre til funktioner og man kan returnere dem fra funktioner.

Også kendt som tupler.
C/C++ users journal havde en artikel om emnet i August, hvor der
blev var en som havde lavet nogle snilde ting med templates således at det
kan lade sig
gøre.
du kan se artiklerne på
http://www.tucs.abo.fi/publications/techreports/TR.cgi?year=1999 (nr
249/267), og du kan hente koden fra www.cuj.com/code

Men.. det som der i virkeligheden sker bagved din ryg er det samme som når
du bruger std::pair, der bliver lavet en klasse til at indeholde det i.. så
det er nok nemmest for dig at følge Mogens' råd og
holde dig til den.

Så det kan lade sig gøre, spørgsmålet er bare om du virkelig har brug for
det .)

Mvh Jonas




Per Abrahamsen (06-12-2001)
Kommentar
Fra : Per Abrahamsen


Dato : 06-12-01 13:54

"Jonas Meyer Rasmussen" <meyerGoTTaReMoVE_Dis@diku.dk> writes:

> Så det kan lade sig gøre, spørgsmålet er bare om du virkelig har brug for
> det .)

Der er enkelte gange (mest i forbindelse med template-programmering)
hvor std::pair er det rigtige, men i de fleste andre tilfælde er
enten:

1. De to hører naturligt sammen: Lav en struct.

2. De to har intet med hinanden at gøre: Overfør dem som separate
parametre.

Hvis du skal returnere flere værdier er der ingen grund til at skamme
sig over at bruge ikke-konstante referenceparametre til det, det er
hvad de er beregnet til.

C++ er ikke SML, og der er ingen grund til at lade som om det var
tilfældet. SML er en meget bedre SML end C++ nogen sinde vil blive.

Jonas Meyer Rasmusse~ (07-12-2001)
Kommentar
Fra : Jonas Meyer Rasmusse~


Dato : 07-12-01 00:59


"Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
news:rju1v4qzk8.fsf@ssv2.dina.kvl.dk...
> Der er enkelte gange (mest i forbindelse med template-programmering)
> hvor std::pair er det rigtige, men i de fleste andre tilfælde er
> enten:
>
> 1. De to hører naturligt sammen: Lav en struct.

Det handler om en bekvemmelighed.
Det er absolut ikke noget at kimse af at kunne returnere flere værdier på en
gang.
Og ja, du kan gøre det med en struct, men hele ideen er at det skal være
nemmere for
dig som programmør.
Så handler det vel bare om, om de templates jeg referede til giver en
ordentlig og letlæselig kode
....således at det netop bliver nemmere at læse... OG forstå.

> 2. De to har intet med hinanden at gøre: Overfør dem som separate
> parametre.
>
> Hvis du skal returnere flere værdier er der ingen grund til at skamme
> sig over at bruge ikke-konstante referenceparametre til det, det er
> hvad de er beregnet til.

Næe jeg vil nu påstå det er en smagsag.
Touplerne har helt sikkert den fordel at der på ingen måde kan være tvivl om
hvad
der er input og hvad der er output til funktionerne.

Med referencer bliver det tvetydigt, og man bliver nødt til at angive hvad
argumenterne skal bruges til.

> C++ er ikke SML, og der er ingen grund til at lade som om det var
> tilfældet. SML er en meget bedre SML end C++ nogen sinde vil blive.

Jae det har du helt ret i, men jeg kan ikke helt forstå hvorfor du skriver
det?
Det er der da ingen der har påstået?
Spørgsmålet gik på om C++ havde mulighed for toupler, og jeg prøvede at
besvare det, ikke på om C++
var SML ???

Jonas



Per Abrahamsen (07-12-2001)
Kommentar
Fra : Per Abrahamsen


Dato : 07-12-01 12:08

"Jonas Meyer Rasmussen" <meyerGoTTaReMoVE_Dis@diku.dk> writes:

> "Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
> news:rju1v4qzk8.fsf@ssv2.dina.kvl.dk...
>> Der er enkelte gange (mest i forbindelse med template-programmering)
>> hvor std::pair er det rigtige, men i de fleste andre tilfælde er
>> enten:
>>
>> 1. De to hører naturligt sammen: Lav en struct.
>
> Det handler om en bekvemmelighed.

Nej, det handler om abstraktion. Hvis to værdier hører naturligt
sammen, er det også naturligt at give dem et fælles navn.

> Og ja, du kan gøre det med en struct, men hele ideen er at det skal
> være nemmere for dig som programmør.

Hvis det virkelig er _hele_ ideen bør man overveje om ikke Visual
Basic eller ligende er et mere velegnet sprog.

>> 2. De to har intet med hinanden at gøre: Overfør dem som separate
>> parametre.
>>
>> Hvis du skal returnere flere værdier er der ingen grund til at skamme
>> sig over at bruge ikke-konstante referenceparametre til det, det er
>> hvad de er beregnet til.
>
> Næe jeg vil nu påstå det er en smagsag.

Det er også et spørgsmål om hvilket sprog man bruger, jeg mener ikke
der kommer noget godt ud af at prøve at programmere til en anden stil
end sproget lægger op til.

> Med referencer bliver det tvetydigt, og man bliver nødt til at angive hvad
> argumenterne skal bruges til.

const referencer er input, ikke-const referencer er output.

Jonas Meyer Rasmusse~ (07-12-2001)
Kommentar
Fra : Jonas Meyer Rasmusse~


Dato : 07-12-01 14:37


"Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
news:rjpu5rcmpx.fsf@ssv2.dina.kvl.dk...
> Nej, det handler om abstraktion. Hvis to værdier hører naturligt
> sammen, er det også naturligt at give dem et fælles navn.

Jeg tror ikke jeg er enig, jeg syntes ikke det er svært at forestille sig et
tilfælde
hvor man skal returnere to/flere værdier, der ikke har noget tilknytning til
hinanden
ellers. Der vil det være en fordel, da man slipper for at lave en klasse som
man selv skal finde på et sigende navn til.

> > Og ja, du kan gøre det med en struct, men hele ideen er at det skal
> > være nemmere for dig som programmør.
>
> Hvis det virkelig er _hele_ ideen bør man overveje om ikke Visual
> Basic eller ligende er et mere velegnet sprog.

Så firkantet er verdenen jo heller ikke. Selvom vi arbejder med et sprog
hvor performance
er sat kringlet syntaks, så behøver man ikke fravælge ting der kan gøre
livet lettere..


> >> 2. De to har intet med hinanden at gøre: Overfør dem som separate
> >> parametre.
> >>
> >> Hvis du skal returnere flere værdier er der ingen grund til at skamme
> >> sig over at bruge ikke-konstante referenceparametre til det, det er
> >> hvad de er beregnet til.
> >
> > Næe jeg vil nu påstå det er en smagsag.
>
> Det er også et spørgsmål om hvilket sprog man bruger, jeg mener ikke
> der kommer noget godt ud af at prøve at programmere til en anden stil
> end sproget lægger op til.

Det at returnere toupler har da absolut ikke noget at gøre med at
programmere i en anden stil.
funktionsprogrammering er _meget_ mere en toupler.

Der findes desuden flere imperative sprog med understøttelse for toupler...
Emerald og Python har det ved jeg.
Dette i sig selv burde da bekræfte at toupler også har en nyttig anvendelse
i den imperative verden.

> > Med referencer bliver det tvetydigt, og man bliver nødt til at angive
hvad
> > argumenterne skal bruges til.
>
> const referencer er input, ikke-const referencer er output.

Hvad så med data der skal modificeres i funktionen? de må være ikke-const
referencer, men hvordan skiller vi
dem fra de referencer som er output?

Mvh Jonas



Per Abrahamsen (10-12-2001)
Kommentar
Fra : Per Abrahamsen


Dato : 10-12-01 12:40

"Jonas Meyer Rasmussen" <meyerGoTTaReMoVE_Dis@diku.dk> writes:

> "Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
> news:rjpu5rcmpx.fsf@ssv2.dina.kvl.dk...
>> Nej, det handler om abstraktion. Hvis to værdier hører naturligt
>> sammen, er det også naturligt at give dem et fælles navn.
>
> Jeg tror ikke jeg er enig, jeg syntes ikke det er svært at
> forestille sig et tilfælde hvor man skal returnere to/flere værdier,
> der ikke har noget tilknytning til hinanden ellers.

Selvfølgelig ikke, men det tilfælde jeg taler om er hvor de hører
naturligt sammen.

> Der vil det være en fordel, da man slipper for at lave en klasse som
> man selv skal finde på et sigende navn til.

I det tilfælde foreslår jeg stadig at man bruger referenceparametre.

> Så firkantet er verdenen jo heller ikke. Selvom vi arbejder med et
> sprog hvor performance er sat kringlet syntaks, så behøver man ikke
> fravælge ting der kan gøre livet lettere..

På lidt længere sigt bliver livet lettere af at bruge de konventioner
der hører til det sprog man programmerer i, i stedet for de
konventioner der hører til det sprog man helst ville programmere i.

> Det at returnere toupler har da absolut ikke noget at gøre med at
> programmere i en anden stil.

Jo, når nu den konventionelle løsning er at bruge

> funktionsprogrammering er _meget_ mere en toupler.

Og stil dækker over meget mere end blot paradigme. Det kan også være
hvor man sætter sine slutparanteser. Hvis man bruger Lisp stil I C++
kan det se sådan her ud:

int fak (int x)
{ int result = x;
for (int i = 2; i < x; i++)
{ result *= i; }
return result; }

Det gør ikke koden til funktionsprogrammering, bare svær at læse fordi
man ikke bruger de konventioner der hører til sproget.

Det samme gælder i øvrigt de folk der sætter slutparanteser i Lisp som
om der var tale om C eller Pascal:

(
defun fak (x)
(
cond (
(< x 2)
1
)
(
t
(* x (fak (- x 1)))
)
)
)

Brrr... det er faktisk værre en C/C++ kodeeksemplet ovenfor.

> Hvad så med data der skal modificeres i funktionen? de må være ikke-const
> referencer, men hvordan skiller vi
> dem fra de referencer som er output?

God pointe. Data der skal modificeres er både input og output. C++
har ikke en konvention der adskille dem fra rene output, som
f.eks. Ada der har både in, out og "inout" parametre.

Jonas Meyer Rasmusse~ (11-12-2001)
Kommentar
Fra : Jonas Meyer Rasmusse~


Dato : 11-12-01 17:50

Hejsa.

Jeg kan fint følge din argumentation om stil, men jeg er ikke sikker på at
jeg
syntes det at parentessætningen er helt det samme.
Det handler i bund og grund om konventioner.. du mener at
det er god kotume at give dem som ikke const referencer,
Jeg foreslog at det kunne være nemmere at putte dem i toupler.. hvorved
man kunne frigøre de ikke konstante referencer til data som bliver
modificeret i
funktionen.

Vi kommer nok aldrig til nogen konklusion, men
jeg vil da lige slutte af med, at siden jeg nævnte touple koden, har jeg
fundet ud
af at det er en del af boost's(www.boost.org) omfattende bibliotek, hvilket
burde bekræfte at
mine påstande om de er nyttige ikke er helt idiotisk ;)

mvh Jonas



Søg
Reklame
Statistik
Spørgsmål : 177500
Tips : 31968
Nyheder : 719565
Indlæg : 6408518
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste