Nye C++-funktioner finder vej til seneste aftapning af GCC-compileren

GNU-projektets compiler har drejet versionsnummeret en tak og kan nu byde på eksperimentiel understøttelse af C++0x, den kommende udgave af C++.

GCC-compileren, der omskaber kode til nuller og ettaller, er nedkommet i en ny version 4.5.

Compileren kan nu levere eksperimentiel understøttelse af visse funktioner i den kommende udgave af C++, som går under navnet C++0x.

Det er blandt andet såkaldte "raw strings," som er strenge, der kan indehold specielle tegn, uden at udvikleren behøver at benytte indkodning, også kendt som escaping. Lambda-udtryk, hvor en funktion kan skrives på en enkelt linje, er en anden nyhed, samt operatorer til typekonvertering.

Blandt andre forbedringer er en række fejlrettelser samt understøttelse af de nye ARM-processorer Cortex-M0 og Cortex-A5 samt ARM-arkitekturen v7E-M. Til gengæld er det slut med understøttelse af gamle udgaver af Tru64 Unix, Irix og Solaris 7.

Læs mere om GCC 4.5 under fanebladet Eksterne links.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#4 Peter Mogensen

Jeg har ikke fulgt C++0x særlig meget, da jeg ikke koder så meget i C++ mere, men jeg kiggede lige på listen over nye "features" hos GCC og undrede mig meget over nytte af "automatisk typede variable" i et sprog som C++. Jeg kan kun komme på nogle enkelte tilfælde, hvor det ville spare noget omskrivning hvis man ændrer prototyper på funktioner, men det ville jo være på bekostning af noget klarhed.

Er Bjarne og venner ikke ved at trække den for langt?

  • 0
  • 0
#5 Klaus Skelbæk Madsen

Det nye auto keyword er beskrevet her:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf

Jeg tror at den primære drivkraft bag, er at kunne erstatte:

[code=cpp] std::vector<std::pair<std::string, std::list > >::const_iterator i = vector.begin() [/code]

med:

[code=cpp] auto i = vector.begin() [/code]

Du mister naturligvis informationen om at det er en vektor af par af strenge og lister af strenge, men i et tilfælde som det ovenfor ville man nok alligevel lave en typedef, også er man jo lige langt.

  • 0
  • 0
#6 Peter Mogensen

Ja ok... for sådan en iterator, hvor man alligevel bare vil lave ++ indtil slut, så er det jo nok klarere kode ikke at skulle remse hele typen op. Gætter nu på man en dag kommer til at slå C++ elever i hovedet med ikke at misbruge auto.

  • 0
  • 0
#7 Torben Mogensen Blogger

Gætter nu på man en dag kommer til at slå C++ elever i hovedet med ikke at misbruge auto.

Jeg tror nærmere, at lærerne vil få grå hår på hovedet af, at eleverne hele tiden spørger "Hvorfor kan man ikke bruge auto her?", når de forsøger at bruge det til funktionsparametre og lignende.

  • 0
  • 0
#8 Klaus Skelbæk Madsen

Gætter nu på man en dag kommer til at slå C++ elever i hovedet med ikke at misbruge auto.

Formentlig ja... Lige som man også skal forklare dem at de skal holde snitterne fra conversion operators, at de ikke skal bruge C-style casts, og skal passe på med multibel arv.

Er det ikke meget generelt for alle programmerings-sprog at man ikke skal misbruge deres features?

  • 0
  • 0
#9 Torben Mogensen Blogger

Er det ikke meget generelt for alle programmerings-sprog at man ikke skal misbruge deres features?

Jo, helt bestemt. Men jeg tror, at det er sjældent, at brug af auto kan betragtes som misbrug. Den kontekst, der afgør typen, er ret lille (initialiseringsudtrykket), og oversætteren checker, at man bruger variablen konsistent med den infererede type. Nogle sprog (ML, Haskell, ...) kan inferere typen af alle variable, inklusive funktionsparametre og -resultater, og der er sjældent problemer med det. Det er langt værre med dynamisk typede sprog -- her erklærer man heller ikke typen af sine variable, men det er først på køretid, at man opdager, hvis noget går galt.

  • 0
  • 0
Log ind eller Opret konto for at kommentere