Bruk av const
HL
Husker jeg feil vedr. bruk av const?
Har følgende:
class Foo
{
const int MAX;
int a[MAX]; // <-- Denne feiler!
};
--- cpp-fila------------
Foo::Foo() :
MAX(5)
{
}
----------------------------------
Burde ikke kompilatoren finne ut at MAX er def. til 5 i
ctor og klare å benytte denne verdien i def. av arrayet a?
Om MAX def. i klassen ved
static int MAX = 5;
funker det som forventet, men jeg trodde at def. av MAX i ctor også
burde funke, eller husker jeg feil?
________
HL
Alf P. Steinbach
> Husker jeg feil vedr. bruk av const?
>
Ja.
> Har følgende:
>
> class Foo
> {
> const int MAX;
>
> int a[MAX]; // <-- Denne feiler!
> };
Spørs hva du prøver å oppnå.
Du kan
struct Foo
{
Foo( int size ): a(size) {}
std::vector<int> a;
};
eller du kan
struct Foo
{
static int const max = 10;
int a[max];
};
eller
struct Foo
{
enum{ max = 10 };
int a[max];
};
De to siste eksemplene er omtrent like, men det siste fungerer med flere
(eldre) kompilatorer og er problemfritt mhp. endringer i standarden.
Men selv i de to siste eksemplene, der du har en kompileringstid
konstant for hånden (verdien må være kjent for kompilatoren i denne
kompileringsenheten) og dermed /kan/ deklarere et innebygd array, er det
generelt en fordel å bruke std::vector.
Tips når det gjelder navnet MAX, som er en Javaisme: <url:
http://www.research.att.com/~bs/bs_faq2.html#Hungarian>.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
HL
>* HL:
>> Husker jeg feil vedr. bruk av const?
>>
>
>Ja.
>
Takker.
________
HL
Ben Hetland
> Tips når det gjelder navnet MAX, som er en Javaisme: <url:
> http://www.research.att.com/~bs/bs_faq2.html#Hungarian>.
Nei, dette er vel heller ein gamal konvensjon frå C, der (enkelt
fortalt) alt som er #define'rt blir skrive med store bokstavar for å
kanskje minna om preprosessorens mange feller. Akkurat dét synest eg
framleis ofte er på sin plass, men ikkje når ein bruker eit betre eller
meir moderne alternativ som t.d. ein inline-funksjon i staden for ein makro.
Lenka di refererer vel heller til noko heilt anna, nemleg det som
kanskje er misforstått "ungarsk notasjon", eller som det òg er kalla,
"Anti-Hungarian Notation". Sjå t.d. her:
<url: http://blogs.msdn.com/rick_schaut/archive/2004/02/14/73108.aspx>
Så ungararen Simonyi hadde vel kanskje meir i tankane å oppnå det som er
omtala t.d. i "Making Wrong Code Look Wrong":
<url: http://www.joelonsoftware.com/articles/Wrong.html>
--
-+-Ben-+-
Alf P. Steinbach
> Alf P. Steinbach wrote:
>> Tips når det gjelder navnet MAX, som er en Javaisme: <url:
>> http://www.research.att.com/~bs/bs_faq2.html#Hungarian>.
>
> Nei, dette er vel heller ein gamal konvensjon frå C, der (enkelt
> fortalt) alt som er #define'rt blir skrive med store bokstavar for å
> kanskje minna om preprosessorens mange feller. Akkurat dét synest eg
> framleis ofte er på sin plass, men ikkje når ein bruker eit betre eller
> meir moderne alternativ som t.d. ein inline-funksjon i staden for ein makro.
Nei, Javaismen er å bruke versalnavn for konstanter.
Og ja, Java fikk den konvensjonen fra C sin konvensjon om makroer.
Opprinnelig C hadde ikke const og måtte bruke makroer til det.
Og ja, i tilfelle du skulle nevne det også, Brian Kernighan hadde en
unik stil som ikke er den gamle C-konvensjonen for versalnavn.
> Lenka di refererer vel heller til noko heilt anna, nemleg det som
> kanskje er misforstått "ungarsk notasjon", eller som det òg er kalla,
> "Anti-Hungarian Notation".
Nei. Lenken[1] refererte til det som står der om versalnavn og makroer.
- Alf
Noter:
[1] <url: http://www.research.att.com/~bs/bs_faq2.html#Hungarian>.
Ben Hetland
> Nei. Lenken[1] refererte til det som står der om versalnavn og makroer.
> [1] <url: http://www.research.att.com/~bs/bs_faq2.html#Hungarian>.
Aha, du siktar vel til "Never use names with all capital letter (e.g.,
BEGIN_TRANSACTION) because that's conventionally reserved for macros."
Det var vel ikkje akkurat det mest sentrale i det han skriv, men ok... :-)
Han hevdar forresten òg:
"The C++ language and standard library don't use capital letters, so
it's int rather than Int and string rather than String."
Skulle ikkje tru han hadde deklarert "FILE *fp;" nokon gong, men det er
jo heller ikkje "idealet" å gjera det på den måten i moderne C++.
Muligens sikta han vel berre til C++-delen av standardbiblioteket ;-)
Sjølv er eg derimot ofte i tvil om det har noko for seg å bruka static
saman med const, dvs. å skriva
static const int everything = 42;
i staden for
const int everything = 42;
Når det ikkje opptrer som formelt argument i ein funksjon, burde vel så
vidt eg kan skjøna all bruk av 'everything' (utanom uttrykket
'&everything') i koden vera ekvivalent med berre å skriva talet 42 over
alt, og ein normalt vettug optimaliserar vil produsera det same uansett.
Eller tek eg feil? Muligens skal standarden tolkast slik at
lagringsområde for variablen skal setjast av *uansett* for tilfelle med
'static' (sjølv om den ikkje er brukt ein gong), men kan elles eliminerast.
Hmmm... eller kanskje noko slikt som "const volatile int ioaddr = 1;"
kunne brukast for å oppnå ein eller annan sær effekt :-)
--
-+-Ben-+-
Steinar H. Gunderson
> Sjølv er eg derimot ofte i tvil om det har noko for seg å bruka static
> saman med const, dvs. å skriva
> static const int everything = 42;
> i staden for
> const int everything = 42;
>
> Når det ikkje opptrer som formelt argument i ein funksjon, burde vel så
> vidt eg kan skjøna all bruk av 'everything' (utanom uttrykket
> '&everything') i koden vera ekvivalent med berre å skriva talet 42 over
> alt, og ein normalt vettug optimaliserar vil produsera det same uansett.
Det stemmer nok, men i det sistnevnte tilfellet vil objektfilen din faktisk
inneholde en variabel "everything" (som kan ta plass, hvis du regner det som
et problem), ettersom den må være tilgjengelig fra andre objektfiler. Om du
ønsker det eller ikke er selvsagt opp til deg.
/* Steinar */
--
Homepage: http://www.sesse.net/
Alf P. Steinbach
Vel, nei.
Hvis deklarasjonene er utenfor noen funksjon eller klasse så betyr de
nøyaktig det samme: en 'const' har intern linking per default.
Hvis deklarasjonene er i en funksjon er de marginalt forskjellige. Med
en steike dum kompilator kan den første da være ineffektiv fordi en slik
deklarasjon generelt (men ikke for int) trenger sjekking av om
konstanten allerede er initialisert, mens fremdeles med en steike dum
kompilator den andre deklarasjonen kan gi initialisering hver eneste
gang. Med en normal kompilator, og jeg vet ikke om noen kompilator som
er så steike dum som skissert her, er det dog ingen forskjell.
Hvis deklarasjonene er av medlemsvariabler i en klasse er det stor
forskjell. Den første er tillatt for heltallstyper men hvis adressen
til konstanten blir brukt så trengs det også en definisjon utenom
klassen (og her er det opp/ned på hva som syntaktisk regnes som ren
deklarasjon og definisjon, bare for å forvirre folk). Den andre er ikke
tillatt i denne sammenhengen.
Ikke i noen tilfeller er det forskjell på om objektfilen vil inneholde
en variabel som kan ta opp plass.
Selv velger jeg deklarasjonsform for å ha en konsistent kodestil uansett
type.
Det vil si at jeg ville valgt det som passet for en generell klasse i
stedet for int.
Steinar H. Gunderson
> Hvis deklarasjonene er utenfor noen funksjon eller klasse så betyr de
> nøyaktig det samme: en 'const' har intern linking per default.
Jaggu. Mea culpa.