ISO C bliver mere og mere idiotisk

Jeg gider ikke gentage mig selv, så I bliver nødt til at læse det her på engelsk:

The Tools We Work With

phk

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Baldur Norddahl

Hvis jeg skulle forsøge forbedre på C (jeg er ikke overbevist om at man bør...) så ville jeg nok tænke noget mere i stil med Cyclone: http://cyclone.thelanguage.org/

Desværre virker det ikke som Cyclone er et levende projekt. Jeg har aldrig prøvet at arbejde med sproget, så jeg ved ikke om det er 100% C kompatibelt, men det vil naturligvis være et krav.

  • 1
  • 0
#3 Poul-Henning Kamp Blogger

Jeg har svært ved at se at vi kan gøre ret meget.

ISO-C er et krav i alle mulige sammenhænge og ISO's standardisering er tydeligvis kørt helt i grøften.

Et af problemerne med bare at lave et nyt "real-C" sprog, er at alle mulige værktøjer, fra Emacs over lint til coverity, graver rundt i syntaxen.

  • 4
  • 0
#4 Henning Makholm

<stdnoreturn.h> ser ud til at være et forsøg på at udvide sproget med nye nøgleord uden at gøre eksisterende C99-tro kode uoversættelig. Idet navne der starter med understregning efterfulgt af et stort bogstav altid har været reserverede, kan kode der bliver generet af at "_Noreturn" nu er et nøgleord, pr. definition ikke omfattet af C99. Ny kode der bruger det nye nøgleord kan så skaffe det ind i et menneskevenligt navnerum ved at inkludere den relevante header.

Set udfra et snævert standardmæssigt synspunkt er det nok den eleganteste (eller rettere mindst uelegante) måde at udvikle sproget uden at kaste kompatibilitet med eksisterende kode over styr.

Set fra et mindre snævert praksissyspunkt giver det ikke nær så megen mening, fordi (a) ingen alligevel har taget _A.._Z reservationen alvorligt, (b) de fleste _Noreturn kommer til at stå i headerfiler der ikke kan tillade sig at antage at <stdnoreturn.h> er inkluderet, og (c) al kode der gør sig nogensomhelst anstalt af at være portabelt, skal alligevel autotools-makroficere den slags annoteringer fordi der kommer til at gå årtier før (om nogensinde) alle relevante platforme understøtter C1x.

Tråd-apiet har jeg ikke noget forsvar for.

  • 2
  • 0
#6 Lars Fischer

Man mindes C.A.R. Hoare's gamle regel "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." Anledningen var vist i sin tid Ada, som CARH mente tydeligvis var kørt af sporet med en specificikation på over 500 sider.

Desværre har IT-verdenen altid været forhippet på at gentage gamle fadæser. Hvad blev der iøvrigt af trigraphs ;-)

  • 5
  • 0
#7 Poul-Henning Kamp Blogger

<stdnoreturn.h> ser ud til at være et forsøg på at udvide sproget med nye nøgleord uden at gøre eksisterende C99-tro kode uoversættelig.

Hvis din kode er C99 kode, så skal du give din compiler en -kompiler-c99 option indtil du har checket at din kildetekst er kompatibel med nyere versioner af sproget.

At plastre sproget til med ornamentation der bare skaber flere fejl er direkte dumt.

Overvej hvad der sker i en kodebase på nogle millioner linier hvis noget af koden laver "#include <stdbool.h>" og noget af den laver "#define bool char"

Hint: Compileren siger ikke til dig at du har problemer.

  • 0
  • 0
#8 Torben Mogensen Blogger

C var oprindeligt et ret enkelt sprog (dog med visse vorter), der var designet til at skrive maskinnær kode såsom operativsystemskerner, drivere, virtuelle maskiner, osv. Og det løste det problem rimeligt godt.

Men efterfølgende er C blevet brugt til en hel masse, som det ikke var beregnet til, og det har medført en masse udvidelser, der har gjort sproget mere kompliceret uden (efter min mening) at gøre sproget rigtig egnet til disse ting.

ISO-standardisering hjælper heller ikke. Det betyder blot, at et større antal leverandører sætter sig ned og kæmper for at få hver deres indbyrdes inkompatible løjerlige udvidelser med, så sproget bliver et kludetæppe med 117 konstruktioner, der gør næsten det samme. Bedre bliver det ikke, når standarden revideres. Da man ikke vil bryde bagudkompatibilitet, bliver sproget i hvert fald ikke enklere. Tværtimod slås leverandørerne igen for at få tilføjet de nye, inbyrdes inkompatible løjerligheder, de hver især har tilføjet siden sidste standarddokument (eller som de ikke fik med i sidste omgang). Og så ruller møllen.

Her er et udmærket blogindlæg, der argumenterer, at denne tendens betyder, at gamle sprog stagnerer mens brugerne flytter til nyere, slankere sprog, der ikke bærer på så meget bagage.

  • 1
  • 0
#9 Poul-Henning Kamp Blogger

denne tendens betyder, at gamle sprog stagnerer mens brugerne flytter til nyere, slankere sprog, der ikke bærer på så meget bagage.

Jeg er generelt enig, i den forstand at vi skal altid prøve at finde det programmeringssprog der bedste udtrykker vores intention når vi skriver programmer.

Men jeg mener der er to forskellige klasser af programmeringssprog, som vi for nemhedens skyld kan kalde "konkrete" og "abstrakte".

Assembler og C er de eneste to sprog jeg pt. vil kalde konkrete: De prøver at give fuld adgang til hardwaren, på hardwarens præmisser, hvilket er nødvendigt for at kunne skrive operativsystemer og anden system-ware, herunder, runtimes for de abstrakte sprog. Ada kan næsten klemmes ind i denne kategori, men ikke helt.

Stort set alle andre sprog er abstrakte, forstået på den måde at de gør alt hvad de kan for at den faktiske hardware ikke "lægger igennem" til programmeringsmiljøet.

Abstrakte sprog vinder stort i portabilitet, klarer sig ofte hæderligt i performance og tilbyder meget virkningsfulde og programmørvenlige abstratkioner på højt niveau.

Ingen ved deres fulde fem bør prøve at skrive et bogføringssystem i C aller Assembler idag, men ligeledes ville det være idioti at skrive et operativsystem i Ruby eller Erlang.

Jeg tror ikke vi nogen sinde ser en realistisk C-replacement, men det er ikke det samme som at vi ikke burde barbere alt ISO-flommen af sproget, så vi igen får det klare, simple og præcise sprog der er grunden til at C er en success.

  • 3
  • 0
#10 Kenn Nielsen

....burde barbere alt ISO-flommen af sproget, så vi igen får det klare, simple og præcise sprog der er grunden til at C er en success.

Bruger ikke selv C, - men det lyder da som om man burde barbere det ned, og beskrive basic-udgaven i en RFC, - og så kalde det RF-C. Så kunne man udvide compileroptions med --RCFyzxi-[A-z] hvis der var specifikke ting man ønskede udover basic-funktionalitet.

K

  • 1
  • 0
#11 Lars Tørnes Hansen

ISO måtte for min skyld gerne holde snitterne fra C. C som beskrevet i K&R bogen er god nok. Derudover er jeg ikke glad for Autotools, og make. Jeg ender altid med at lave et (bash shell) script der passer til styresystemet (32-bit Linux) og de konkrete libs og værktøjer jeg bruger - skrøbeligt ja, men jeg kan ikke udstå autotools og make.

Hvad gør man egentlig for at blive gode venner med make? Der er noget der hedder cmake, men jeg ved ikke om det er meget bedre.

@PH-K: Af konkrete sprog ville jeg have Assembler, C og Ada. I Ada kan man meget præcis beskrive bits i et hardwareregister[1]. Skulle jeg lave noget hardwarenær programmering i Ada ville jeg nok undgå at bruge objekt orienteret programmering, fordi det er mindre KISS.

[1]: http://www.infres.enst.fr/~pautet/Ada95/e_c32_p2.ada

  • 0
  • 0
#12 Søren Løvborg

Hvis din kode er C99 kode, så skal du give din compiler en -kompiler-c99 option indtil du har checket at din kildetekst er kompatibel med nyere versioner af sproget.

GCC antager vist stadig C89 medmindre andet eksplicit angives, hvilket eliminerer problemer med bagudkompatibilitet lige der. Ved ikke om andre compilere gør det samme, men det lyder som om ISO gør meget ud af at løse et ikke-eksisterende problem.

De eneste seriøse bud på erstatninger for C (altså sprog man fx kunne skrive et OS i) jeg kender, er C++ og D. D mangler desværre i den grad "mindshare", og C++ ville jeg personligt ikke røre med en ildtang.

  • 0
  • 0
#13 Keld Simonsen

Jeg har forhørt mig lidt omkring om PHKs kritik.

Kritikken omkring navnekonventioner: Det var kun navnekonventioner, og de af PHK omtalte garantier blev fjernet i C90 - og er ikke noget nyt i C11.

API med tråde: Dette er en lægtvægts API, og er designet så den kan spille sammen med POSIX pthreads. Der er defor ikke nogen konflikt.

Nogen siger at det da kan være godt med yderligere mutex funktionalitet og API'er, og det gælder så både C og POSIX. Og der er altid mulighed for forbedring af standarderne, så smøg ærmerne op og skriv et forslag.

Om defineret størrelse på stakken: det vurderes om ikke-portabelt. I nogen arkitekturer ar der 2 stakke per tråd, hvilken én af dem er det, størrelsen gælder for?

Simpel objektorientering: Vi har diskuteret det i WG14 og det blev ikke til noget.

C11 er nu en offentliggjort ISO/IEC standard. Hvad der er frit offentligt tilgængeligt er dog kun et draft - N1548.

Alt i alt ser det ud til at der ikke er meget kød på PHK's kritik. Men man kan da god overveje nogen nye API-er til tråde og noget nyt omkring objektorientering.

Heldigvis er WG14 en rimelig åben organisation som er modtagelig over for nye forslag. Selv jeg har i flere omgange kunnet få nogen ting med i standarden:-)

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