Hmmmm
Sigurd Stenersen
int x[10] = { 0 };
{
for (int i = 0; i < 9;)
{
x[i] = ++i;
}
}
{
for (int i = 0; i < 10; i++)
{
printf("%d ", x[i]);
}
}
...
Sigurd
Helge Selstř
23:05:25 +0200:
Og hmmen betyr?
Den teller vel fint, gjør den ikke?
--
Helge Selstø
Igor V. Rafienko
[ ... ]
> for (int i = 0; i < 9;)
> {
> x[i] = ++i;
Denne konstruksjonen var aldri lovlig, så resultatet deretter kan
bli hva som helst. Akkurat dette eksempelet er beskrevet i kapittel 5,
§ 4 i ISO/IEC 14882:1998(E).
ivr
--
<+Kaptein-Dah> igorr: for få parenteser
<+Kaptein-Dah> igorr: parenteser virker som lubrication under iterasjon
<+Kaptein-Dah> igorr: velkjent
Sigurd Stenersen
>> int x[10] = { 0 };
>> {
>> for (int i = 0; i < 9;)
>> {
>> x[i] = ++i;
>> }
>> }
>> {
>> for (int i = 0; i < 10; i++)
>> {
>> printf("%d ", x[i]);
>> }
>> }
>>...
>
> Og hmmen betyr?
> Den teller vel fint, gjør den ikke?
Det er ikke tellingen som er problemet her. Problemet er at forskjellige
kompilatorer genererer programmer som ikke gir samme output.
Sigurd
Sigurd Stenersen
>[ Sigurd Stenersen ]
>
>> for (int i = 0; i < 9;)
>> {
>> x[i] = ++i;
>
> Denne konstruksjonen var aldri lovlig, så resultatet deretter kan
> bli hva som helst. Akkurat dette eksempelet er beskrevet i kapittel 5,
> § 4 i ISO/IEC 14882:1998(E).
Greit nok, det er sikkert like greit å gjøre slik kode "ulovlig".
Men hvorfor gir da ingen av de tre kompilatorene jeg har prøvd dette på en
feilmelding, når det har skjedd et alvorlig lovbrudd - som attpåtil er
beskrevet i en standard ?
Sigurd
Lars Christian Jensen
Konstruksjonen er ikke ulovlig, den har bare ikke noen definert oppførsel
så kompilatoren kan ikke hindre deg i å skrive det. Ser at g++ gir
warning: foo.cpp:9: warning: operation on 'i' may be undefined
Bruk java i stedet, så slipper du sånne tullete problemer ;-)
--
Lars Christian Jensen
Helge Selstř
12:45:04 +0200:
>"Helge Selstø" <helges.ne...@chello.no> skrev
>> Og hmmen betyr?
>> Den teller vel fint, gjør den ikke?
>
>Det er ikke tellingen som er problemet her. Problemet er at forskjellige
>kompilatorer genererer programmer som ikke gir samme output.
Det blir noe helt annet, men kan ikke kompilatorene instrueres til å
gi det forventede svaret(output) når programmet skal kjøres?
--
Helge Selstø
Sigurd Stenersen
> On Wed, 22 Aug 2007, Sigurd Stenersen wrote:
>
>> "Igor V. Rafienko" <ig...@ifi.uio.no> skrev
>>> [ Sigurd Stenersen ]
>>>
>>>> for (int i = 0; i < 9;)
>>>> {
>>>> x[i] = ++i;
>>>
>>> Denne konstruksjonen var aldri lovlig, så resultatet deretter kan
>>> bli hva som helst. Akkurat dette eksempelet er beskrevet i kapittel 5,
>>> § 4 i ISO/IEC 14882:1998(E).
>>
>> Greit nok, det er sikkert like greit å gjøre slik kode "ulovlig".
>>
>> Men hvorfor gir da ingen av de tre kompilatorene jeg har prøvd dette på
>> en feilmelding, når det har skjedd et alvorlig lovbrudd - som attpåtil er
>> beskrevet i en standard ?
>
> Konstruksjonen er ikke ulovlig, den har bare ikke noen definert oppførsel
> så kompilatoren kan ikke hindre deg i å skrive det.
Kompilatoren *kan* nekte å generere kode som pr definisjon er udefinert. I
det minste kunne den gi en advarsel.
> Ser at g++ gir warning: foo.cpp:9: warning: operation on 'i' may be
> undefined
Nå er det faktisk slik at g++ ikke gir noen advarsel i dette tilfellet. Det
kan kanskje komme av at jeg bruker en eldre versjon enn du, eller at man må
aktivere flere advarsler enn det som er default.
Men ikke nok med det - g++ genererer programmer med forskjellig output ut
fra valg av optimalisering (-oN)...
> Bruk java i stedet, så slipper du sånne tullete problemer ;-)
Det er ikke en aktuell "løsning" i dette tilfellet.
Sigurd
Sigurd Stenersen
>>> Og hmmen betyr?
>>> Den teller vel fint, gjør den ikke?
>>
>>Det er ikke tellingen som er problemet her. Problemet er at forskjellige
>>kompilatorer genererer programmer som ikke gir samme output.
>
> Det blir noe helt annet, men kan ikke kompilatorene instrueres til å
> gi det forventede svaret(output) når programmet skal kjøres?
Poenget er vel snarere at man bør unngå å lage slik kode, og at kompilatoren
i det minste kunne hinte om dette ?
Sigurd
Helge Selstř
>Poenget er vel snarere at man bør unngå å lage slik kode, og at kompilatoren
>i det minste kunne hinte om dette ?
Jo, helt enig, testet det i VS 6.0 og fikk 0 feilmeldinger, og
kjørbart program. Er vel liten vits å teste i VS 2005 siden
kompilatoren der er omtrent lik den gamle for C++.
--
Helge Selstø
Thore B. Karlsen
<helges.ne...@chello.no> wrote:
>>Poenget er vel snarere at man bør unngå å lage slik kode, og at kompilatoren
>>i det minste kunne hinte om dette ?
>Jo, helt enig, testet det i VS 6.0 og fikk 0 feilmeldinger, og
>kjørbart program. Er vel liten vits å teste i VS 2005 siden
>kompilatoren der er omtrent lik den gamle for C++.
Omtrent lik den gamle? Den har gått fra å være en skikkelig
middelmådig kompilator til å være en av de beste. Den er definitivt
ikke "omtrent lik den gamle".
--
Be seeing you.
Lars Christian Jensen
On Wed, 22 Aug 2007, Sigurd Stenersen wrote:
> "Lars Christian Jensen" <lars...@pvv.ntnu.no> skrev
>
>> Konstruksjonen er ikke ulovlig, den har bare ikke noen definert
>> oppførsel så kompilatoren kan ikke hindre deg i å skrive det.
>
> Kompilatoren *kan* nekte å generere kode som pr definisjon er udefinert.
> I det minste kunne den gi en advarsel.
Jeg tviler på at kompilatoren *kan* nekte i henhold til standarden
ettersom koden er gyldig c++.
>> Ser at g++ gir warning: foo.cpp:9: warning: operation on 'i' may be
>> undefined
>
> Nå er det faktisk slik at g++ ikke gir noen advarsel i dette tilfellet. Det
> kan kanskje komme av at jeg bruker en eldre versjon enn du, eller at man må
> aktivere flere advarsler enn det som er default.
Du har rett. Jeg kjører alltid g++ med -Wall.
> Men ikke nok med det - g++ genererer programmer med forskjellig output
> ut fra valg av optimalisering (-oN)...
Hvorfor ikke...
--
Lars Christian
Helge Selstř
Hmm, da må jeg sette igang å teste den snart da. Jeg var overbevist om
at den ikke hadde noen særlige forbedringer, men der tok jeg skikkelig
feil altså. Er det noen som vet om trenden fortsetter i neste versjon
av VS også?
--
Helge Selstø
Sigurd Stenersen
Sigurd Stenersen
>
> On Wed, 22 Aug 2007, Sigurd Stenersen wrote:
>
>> "Lars Christian Jensen" <lars...@pvv.ntnu.no> skrev
>>
>>> Konstruksjonen er ikke ulovlig, den har bare ikke noen definert
>>> oppførsel så kompilatoren kan ikke hindre deg i å skrive det.
>>
>> Kompilatoren *kan* nekte å generere kode som pr definisjon er udefinert.
>> I det minste kunne den gi en advarsel.
>
> Jeg tviler på at kompilatoren *kan* nekte i henhold til standarden
> ettersom koden er gyldig c++.
Selvfølgelig *kan* den nekte.
Og uansett - i det minste kunne den gi en advarsel.
>>> Ser at g++ gir warning: foo.cpp:9: warning: operation on 'i' may be
>>> undefined
>>
>> Nå er det faktisk slik at g++ ikke gir noen advarsel i dette tilfellet.
>> Det
>> kan kanskje komme av at jeg bruker en eldre versjon enn du, eller at man
>> må
>> aktivere flere advarsler enn det som er default.
>
> Du har rett. Jeg kjører alltid g++ med -Wall.
Jeg prøvde med -Wall og den gir fortsatt ikke noen advarsel. Men dette er
3.4.0 så da er det jo tydeligvis andre som har slitt med det samme i
mellomtiden...
(Jeg har også prøvd det samme med Intel C++ 9.1, og den gir heller ingen
advarsel. Kanskje versjon 10 gjør det ?)
Sigurd
Thore B. Karlsen
<sig...@utvikling.com> wrote:
>>>>Poenget er vel snarere at man bør unngå å lage slik kode, og at
>>>>kompilatoren
>>>>i det minste kunne hinte om dette ?
>>>Jo, helt enig, testet det i VS 6.0 og fikk 0 feilmeldinger, og
>>>kjørbart program. Er vel liten vits å teste i VS 2005 siden
>>>kompilatoren der er omtrent lik den gamle for C++.
>> Omtrent lik den gamle? Den har gått fra å være en skikkelig
>> middelmådig kompilator til å være en av de beste. Den er definitivt
>> ikke "omtrent lik den gamle".
>Men gir den advarsel på den aktuelle koden ?
Nope. :/
--
Be seeing you.
Thore B. Karlsen
<helges.ne...@chello.no> wrote:
>>>Er vel liten vits å teste i VS 2005 siden
>>>kompilatoren der er omtrent lik den gamle for C++.
>>Omtrent lik den gamle? Den har gått fra å være en skikkelig
>>middelmådig kompilator til å være en av de beste. Den er definitivt
>>ikke "omtrent lik den gamle".
>Hmm, da må jeg sette igang å teste den snart da. Jeg var overbevist om
>at den ikke hadde noen særlige forbedringer, men der tok jeg skikkelig
>feil altså. Er det noen som vet om trenden fortsetter i neste versjon
>av VS også?
Jeg husker ikke helt hvilke forbedringer den har, men Microsoft satser
veldig på C++ i disse dager. De investerer veldig mye tid og penger på
å gjøre kompilatoren og programmeringsmiljøet bedre for de av oss som
bruker C++.
--
Be seeing you.
Steinar H. Gunderson
> Hmm, da må jeg sette igang å teste den snart da. Jeg var overbevist om
> at den ikke hadde noen særlige forbedringer, men der tok jeg skikkelig
> feil altså. Er det noen som vet om trenden fortsetter i neste versjon
> av VS også?
Man får håpe. Med litt flaks blir det mulig å bruke C++0x-features i
kryssplattform-kode før 2030 :-)
/* Steinar */
--
Homepage: http://www.sesse.net/
Jørgen Hovland
Du har ikke initalisert hele arrayet ditt, og som forventet gav dette
warning..
# c++ -Wall -o k k.c
k.c: In function 'int main()':
k.c:10: warning: operation on 'i' may be undefined
"Sigurd Stenersen" <sig...@utvikling.com> wrote in message
news:nvadnQru364...@telenor.com...
Jørgen Hovland
lenge siden :-)
Jørgen Hovland
# c++ --version
c++ (GCC) 4.2.1
"Jørgen Hovland" <jørg...@hovland.cx> wrote in message
news:13dvupf...@corp.supernews.com...
Alf P. Steinbach
> "Sigurd Stenersen" <sig...@utvikling.com> wrote in message
> news:nvadnQru364...@telenor.com...
>> ...
>> int x[10] = { 0 };
>> {
>> for (int i = 0; i < 9;)
>> {
>> x[i] = ++i;
>> }
>> }
>> {
>> for (int i = 0; i < 10; i++)
>> {
>> printf("%d ", x[i]);
>> }
>> }
>> ...
>
> Du har ikke initalisert hele arrayet ditt, og som forventet gav dette
> warning..
>
> # c++ -Wall -o k k.c
> k.c: In function 'int main()':
> k.c:10: warning: operation on 'i' may be undefined
>
Hele arrayet er initialisert, til nullere.
Problemet er at verdien til "i" brukes i et uttrykk som modifiserer "i",
x[i] = ++i;
og resultatet er formelt Udefinert Oppførsel.
Kompilator 1 kan evaluere det som
int* __p = &x + i;
++i;
*__p = i;
Kompilator 2 kan evaluere det som
++i;
int* __p = &x + i;
*__p = i;
Kompilator 3 kan evaluere det som
__issueUndefinedBehaviorDiagnostic();
Og så videre, alt innenfor standarden.
- Alf
Dag-Erling Smørgrav
> Hele arrayet er initialisert, til nullere.
Overhodet ikke. Arrayets tilstand etter den første løkken er udefinert.
DES
--
Dag-Erling Smørgrav - d...@des.no
Alf P. Steinbach
> "Alf P. Steinbach" <al...@start.no> writes:
>> Hele arrayet er initialisert, til nullere.
>
> Overhodet ikke.
Beklager, du tar feil der.
int x[10] = { 0 };
initialiserer hele arrayet, når man ser bort fra påfølgende UB (som gir
hele programmet UB).
> Arrayets tilstand etter den første løkken er udefinert.
Det er korrekt.
Hdh.,
- Alf
Alf P. Steinbach
> * Dag-Erling Smørgrav:
>> "Alf P. Steinbach" <al...@start.no> writes:
>>> Hele arrayet er initialisert, til nullere.
>>
>> Overhodet ikke.
>
> Beklager, du tar feil der.
>
> int x[10] = { 0 };
>
> initialiserer hele arrayet, når man ser bort fra påfølgende UB (som gir
> hele programmet UB).
Glemte å ta med, hvorfor x[i]=++i er Undefined Behavior (hva som helst
kan skje) og ikke bare Unspecified Behavior (et eller annet spesifikt
"normalt" resultat som må dokumenteres av kompilatoren-leverandøren).
I både 1999-standarden og 2003 TC1 var den normative ordlyden Undefined
Behavior, mens de ikke normative eksemplene var Unspecified Behavior,
det vil si at det trolig var litt sprik mellom intensjon og faktisk
ordlyd, og intern inkonsistens i standarden.
Andrew Koenig, som jeg mistenker var den som opprinnelig førte dette i
pennen, sendte det inn som defektrapport i 2002[1], det ble resolvert
som Undefined Behavior (den normative ordlyden) i 2003, og tatt inn i
arbeidsutkastet til ny standard, det vil si, i C++0x blir eksemplene
omskrevet til å si "Undefined Behavior".
>> Arrayets tilstand etter den første løkken er udefinert.
>
> Det er korrekt.
>
> Hdh.,
>
> - Alf
Noter:
[1] <url: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#351>.
Jørgen Hovland
Jørgen Hovland
int x[10] = { };
setter alt til 0 og.