mboost-dp1
Alting der er galt med C++
https://stackoverflow.com/a/56827906/95309
Se hvor meget diskussion der er for et simpelt svar. De kan ikke engang blive enige om hvordan man finder stoerrelsen paa en fil.
Se hvor meget diskussion der er for et simpelt svar. De kan ikke engang blive enige om hvordan man finder stoerrelsen paa en fil.
#1
C og C++ folket har altid været nitpickere / language lawyers.
Og C++ har en tendens til meget komplicerede løsninger.
Den SO tråd er efter min mening ikke ret praktisk anvendelig. En løsning som kræver C++ 17 support kan ikke bruges af de fleste. Og da problemet har kunnet løses med *stat funktionerne siden for evigt, så ...
C og C++ folket har altid været nitpickere / language lawyers.
Og C++ har en tendens til meget komplicerede løsninger.
Den SO tråd er efter min mening ikke ret praktisk anvendelig. En løsning som kræver C++ 17 support kan ikke bruges af de fleste. Og da problemet har kunnet løses med *stat funktionerne siden for evigt, så ...
Nu spørger jeg måske dumt, men er også kun novice ... Men hvad skal man så bruge i stedet for C++? Er det C#?
Personligt foretrækker jeg Delphi og C#... Men kunne godt fristes af Rust
på den anden side vil jeg hellere bruge ASP, c eller c++ end hhv java, visual basic, perl, ASP eller javascript
heldigvis laver jeg meget lidt web relateret, så jeg slipper i stor omfang for javascript, ASP og PHP
på den anden side vil jeg hellere bruge ASP, c eller c++ end hhv java, visual basic, perl, ASP eller javascript
heldigvis laver jeg meget lidt web relateret, så jeg slipper i stor omfang for javascript, ASP og PHP
PHP-Ekspert Thoroughbreed (3) skrev:
Nu spørger jeg måske dumt, men er også kun novice ... Men hvad skal man så bruge i stedet for C++? Er det C#?
Det er faktisk et rigtigt godt spørgsmål.
Jeg tror at svaret vil afhænge meget af applikations typen.
Mit gæt:
business application backend kode => C#, Java
platform software code => Rust, Go
fat client Windows desktop => C#
critical embedded real-time system => Ada
PHP-Ekspert Thoroughbreed (3) skrev:Nu spørger jeg måske dumt, men er også kun novice ... Men hvad skal man så bruge i stedet for C++? Er det C#?
Kommer i høj grad an på hvad du vil. Driverudvikling? Så vil jeg sige at god gammeldags C klarer ærterne. Linux er skrevet i C f.eks.
C++ har stadig sin berettigelse som en slags high-level sprog hvor man stadig kan bevare følingen med hvad der sker helt nede på low-level. Men som det kan ses, så kan det nemt stikke helt af og blive enormt kompliceret hvis man ikke passer på..
arne_v (6) skrev:CBM (4) skrev:
på den anden side vil jeg hellere bruge ASP, c eller c++ end hhv java, visual basic, perl, ASP eller javascript
Hmmm....
på den anden side vil jeg hellere bruge PHP, c eller c++ end hhv java, visual basic, perl, ASP eller javascript
arne_v (5) skrev:platform software code => Rust, Go
Jeg afprøvede kortvarigt Go på vores embedded Linux platform. Det var ekstremt nemt at cross compile, men en hello world applikation fyldte en megabyte -ish.
Nogle af vores programmer skal gerne kunne starte op hurtigt, og der har jeg altså mere tiltro til en 50 KB binary compilet fra C, end en 1 MB Go moppedreng. Dertil er hele Linux imaget kun ca. 30 MB zippet lige nu. For mig at se skal der være en god grund til at ofre det overhead for at køre Go. Vi afprøvede dog ikke Rust.
.. så vi kører C til lowlevel hardware interfacing og Python scripts til highlevel logic på platformen.
C++ kunne bestemt også have leveret varen, men vi har ikke brug for de ekstra features og kompleksiteten der følger med. C er så dejlig ligetil og man kan godt lave simpel objektorientering i C med structs og pointere efter behov.
arne_v (15) skrev:#14
Men er forskellen i størrelse p.g.a. faktisk genereret kode eller p.g.a. noget statisk linking?
Ja, det er pga. statisk linket kode, runtime environment osv. https://stackoverflow.com/questions/28576173/reaso...
Fordelen er så at executables kan køre fuldstændig standalone uden afhængigheder.
øøøhhh Er vi ikke tilbage til det samme problem som MS havde da de skulle liste deres omsætning i Cent. ?
Jeg mener ok så du kan ikke få størrelsen i Byte men det er vel ok hvis du kan få den i KByte eller MByte Eller GByte hvis det skulle være ?
Ja det er ikke den helt nøjagtige værdie der er listet ned til 1 byte, men 720 MB er vel også ok og har man så bruge for denne i Byte skriver man den vel bare ud i ulong, har ikke kikket på koden endnu men C++ er jo Bedstefaren af Programmering sammen med Pascal og Asm, og der skal vel meget til at sige at der er noget galt med dette.
Jeg ville ihvertfald være meget forsigtig med at komme ud med sådanne en udtalelse.
Bare ses hvordan det gik ,lille kylling da han sage "Himlen falder.."
Jeg mener ok så du kan ikke få størrelsen i Byte men det er vel ok hvis du kan få den i KByte eller MByte Eller GByte hvis det skulle være ?
Ja det er ikke den helt nøjagtige værdie der er listet ned til 1 byte, men 720 MB er vel også ok og har man så bruge for denne i Byte skriver man den vel bare ud i ulong, har ikke kikket på koden endnu men C++ er jo Bedstefaren af Programmering sammen med Pascal og Asm, og der skal vel meget til at sige at der er noget galt med dette.
Jeg ville ihvertfald være meget forsigtig med at komme ud med sådanne en udtalelse.
Bare ses hvordan det gik ,lille kylling da han sage "Himlen falder.."
crashoverride (17) skrev:
men C++ er jo Bedstefaren af Programmering sammen med Pascal og Asm, og der skal vel meget til at sige at der er noget galt med dette.
Hmmm. C++ er faktisk ret nyt.
Fortran : 1957
Lisp : 1958
Algol : 1958
Cobol : 1959
Basic : 1964
Pascal : 1970
C : 1972
Ada : 1980
C++ : 1985
Java : 1995
JavaScript : 1995
C# : 2000
Mange her kender nok også COMAL som er fra 1973 så det er næsten lige så gammelt som C. Har ikke selv prøvet det i nyere tid men har dårlige minder om det fra folkeskolen. :-)
En noget underlig diskussion, de plejer ellers at være fornuftige nok på stackoverflow. Den har faktisk har meget lidt at gøre med C eller C++, returnering af file størrelser mm. er noget der kun kan gøres af Operativsystemet, som så har en række implementeringer alt efter programmeringssprog.
Hvis man synes at C eller C++ er specielt kompliceret er det fordi man er blevet vant til at blive holdt i hånden af andre programmeringssprog som gemmer de grimme detaljer på hvor en computer rent faktisk virker. Hvis man ikke har behov for at lave high performance/effektiv kode, hardware nær udviklingen eller andre har leveret et API, så er C#, Node.JS og tilsvarende fint nok. (Java tæller jeg ikke med her, da det har udlevet sin plads i datalogien efter min mening)
Hvad angår syntax er C og C++ blandt de bedste, der er en grund til at de fleste moderne sprog læner sig kraftigt op af C og C++. Man kan naturligvis have en lang diskussion omkring objektorienteret vs functional programming mm. men det har meget lidt med sproget at gøre.
Angående sikkerhed af code lavet i C/C++ så er det jo stort set i hænderne på programmøren, hvis man benytter testede biblioteker er det det blandt de sikreste, hvis man laver alt selv uden at vide hvad man gør, så er det ikke.
Hvis man synes at C eller C++ er specielt kompliceret er det fordi man er blevet vant til at blive holdt i hånden af andre programmeringssprog som gemmer de grimme detaljer på hvor en computer rent faktisk virker. Hvis man ikke har behov for at lave high performance/effektiv kode, hardware nær udviklingen eller andre har leveret et API, så er C#, Node.JS og tilsvarende fint nok. (Java tæller jeg ikke med her, da det har udlevet sin plads i datalogien efter min mening)
Hvad angår syntax er C og C++ blandt de bedste, der er en grund til at de fleste moderne sprog læner sig kraftigt op af C og C++. Man kan naturligvis have en lang diskussion omkring objektorienteret vs functional programming mm. men det har meget lidt med sproget at gøre.
Angående sikkerhed af code lavet i C/C++ så er det jo stort set i hænderne på programmøren, hvis man benytter testede biblioteker er det det blandt de sikreste, hvis man laver alt selv uden at vide hvad man gør, så er det ikke.
arne_v (21) skrev:Men så vidt jeg ved var COMAL primært en dansk ting.
COMAL er udviklet af et par danskere ja, men det er blevet brugt en del i flere andre lande også, både resten af skandinavien samt UK og US, primært til undervisningsbrug.
Septi (23) skrev:Hvis man synes at C eller C++ er specielt kompliceret er det fordi man er blevet vant til at blive holdt i hånden af andre programmeringssprog som gemmer de grimme detaljer på hvor en computer rent faktisk virker.
(...)
Hvad angår syntax er C og C++ blandt de bedste, der er en grund til at de fleste moderne sprog læner sig kraftigt op af C og C++.
C++ er et UHYRE kompliceret sprog, og her tænker jeg på alle de features der er mht. objektorienteret programmering. C++ template metaprogrammering er turing complete, hvilket er bizart i sig selv og hele template showet er med til at C++ kan tage ekstremt lang tid at kompilere. C++ har faldgruber på faldgruber når det kommer til objekt orienteret design, læs f.eks. om rule of 3 og rule of 5, og C++ understøtter adskillige programmeringsparadigmer. Ja, man kan lave pæn og fornuftig C++ kode, ingen tvivl om det, og ingen tvivl om at det er et yderst potent sprog. Men man kan dælme også komme galt af sted.
C er det primitive brute force sprog der kan klare alt lowlevel, men det er altså heller ikke særlig kønt, og der er ærligtalt et par features man savner, f.eks. fuld kontrol over bytes i structs (C indsætter padding), deklarering af Little / Big endian, bedre styr på bits i felter, måder at gange f.eks. 32 x 32 bit til 64 bit resultat, uden at skulle lave en 64 x 64 bit = 64 bit operation. Den slags må man hoppe i assembler for at gøre. Og der kunne godt være lidt mere ensartethed mht. deklarationer. Se bare alle de måder man kan lave structs på f.eks.
... bare for at sige at C og C++ ikke er rosenrøde. De er gamle støvede sprog der har overlevet fordi de er så udbredte, de er ikke perfekte.
larsp (25) skrev:der er ærligtalt et par features man savner, f.eks. fuld kontrol over bytes i structs (C indsætter padding)
Nu er det ganske vist compiler-specifikt, men padding er vel ret universelt understøttet gennem compiler-direktiver?
Septi (23) skrev:
En noget underlig diskussion, de plejer ellers at være fornuftige nok på stackoverflow. Den har faktisk har meget lidt at gøre med C eller C++, returnering af file størrelser mm. er noget der kun kan gøres af Operativsystemet, som så har en række implementeringer alt efter programmeringssprog.
Øh.
Det har vel udelukkende med C og C++ at gøre.
Styre systemet har en måde at finde størrelsen af en fil på. Det er givet. Men det er jo ikke emnet de diskueterer.
Diskussion drejer sig om C og C++ bibliotekernes funktioner til at hente den information og den retur type de er erklæret med.
Septi (23) skrev:
Hvad angår syntax er C og C++ blandt de bedste, der er en grund til at de fleste moderne sprog læner sig kraftigt op af C og C++.
Sprog fra 1990-2005 kopierede meget C/C++ syntax.
Men idag skifter man et større eller mindre omfang til andre syntaxer.
Septi (23) skrev:
Man kan naturligvis have en lang diskussion omkring objektorienteret vs functional programming mm. men det har meget lidt med sproget at gøre.
Det har vel alt at gøre med sproget. Både OO og FP ligger mest i sproget og kun begrænset i library/runtime.
Septi (23) skrev:
Angående sikkerhed af code lavet i C/C++ så er det jo stort set i hænderne på programmøren, hvis man benytter testede biblioteker er det det blandt de sikreste, hvis man laver alt selv uden at vide hvad man gør, så er det ikke.
Der findes stadig buffer overflow fejl og andre fejl i testede biblioteker.
Arne
demolition (26) skrev:larsp (25) skrev:
der er ærligtalt et par features man savner, f.eks. fuld kontrol over bytes i structs (C indsætter padding)
Nu er det ganske vist compiler-specifikt, men padding er vel ret universelt understøttet gennem compiler-direktiver?
Det er meget normalt at kunne bestemme alignment/padding for en compilation unit via compiler switches.
Der er muligvis også C/C++ compilere som kan gøre det per type omend jeg ikke kan komme i tanke om et eksempel.
Men andre sprog har det ihvertfald.
C#
[StructLayout(LayoutKind.Explicit)]
public class Foobar
{
[FieldOffset(0)] public int A;
[FieldOffset(4)] public int A;
}
VMS Pascal
type
foobar = record
a : [POS(0)] integer;
b : [POS(32)] integer;
end;
Begge eksempler er indtastet her og utestet!!
C++ med smart pointers er vel nu ogsaa rimelig sikkert nu om dage. Men problemet er vel mere at folk skriver kode som ikke bruger C++'s sikkerheds features fordi at de vil have lidt super-duper-ekstra-performance.
Der var ogsaa rigtig mange tidligere C++ udviklere som aldrig rigtig gad laere det nye i C++11 (som f.eks. std::move). Og det er ikke ligefrem unormalt at udviklere som har arbejdet med det samme programmeringssprog i 10-20 aar ikke rigtig gider laere alt det nye. Saa det har jo absolut en paavirkning.
Der var ogsaa rigtig mange tidligere C++ udviklere som aldrig rigtig gad laere det nye i C++11 (som f.eks. std::move). Og det er ikke ligefrem unormalt at udviklere som har arbejdet med det samme programmeringssprog i 10-20 aar ikke rigtig gider laere alt det nye. Saa det har jo absolut en paavirkning.
arne_v (27) skrev:
Der findes stadig buffer overflow fejl og andre fejl i testede biblioteker.
MS har lige udgivet et research paper:
https://www.microsoft.com/en-us/research/uploads/p...
larsp (25) skrev:
C++ er et UHYRE kompliceret sprog, og her tænker jeg på alle de features der er mht. objektorienteret programmering. C++ template metaprogrammering er turing complete, hvilket er bizart i sig selv og hele template showet er med til at C++ kan tage ekstremt lang tid at kompilere. C++ har faldgruber på faldgruber når det kommer til objekt orienteret design, læs f.eks. om rule of 3 og rule of 5, og C++ understøtter adskillige programmeringsparadigmer. Ja, man kan lave pæn og fornuftig C++ kode, ingen tvivl om det, og ingen tvivl om at det er et yderst potent sprog. Men man kan dælme også komme galt af sted.
C++ eller C er som sprog ikke mere kompliceret end C# eller Java. Hvis du vil se et kompliceret sprog så kig på Object-C. Det er korrekt at C++ er meget stort i forhold til features og tilgængelige biblioteker. Det åbner op for du kan stort set hvad du vil, inklusive rent faktisk at udvide sprogets muligheder med templates, som næsten er en videnskab i sig selv.
Det betyder jo også, at det ikke er sproget men de benyttede biblioteker som er kompliceret, STL, er ikke nemt at overskue. Men programmøren er jo sidste ende den som beslutter sig for hvor kompliceret, han vil gøre det. Men det er lidt prisen man må betale hvis man skal lave kode hvor maksimal kontrol over eksekveringen af koden er nødvendig, og assembler er overkill.
Men jeg er enig i at de mange paradigmer som kan understøttes kan være udfordrende, da mange valg ikke er taget for dig. Det er op til udviklerne at vælge hvad der er bedst for dem. Men jo, man kan komme galt afsted, især med de mere avancerede OOP dele, man kan diskutere om OOP delen i C++ reelt ikke er mere avanceret er godt er. Men igen, ingen tvinger dig til at bruge det. i C# er mange af disse valg taget for dig, med de begrænsninger de så giver.
C er det primitive brute force sprog der kan klare alt lowlevel, men det er altså heller ikke særlig kønt, og der er ærligtalt et par features man savner, f.eks. fuld kontrol over bytes i structs (C indsætter padding), deklarering af Little / Big endian, bedre styr på bits i felter, måder at gange f.eks. 32 x 32 bit til 64 bit resultat, uden at skulle lave en 64 x 64 bit = 64 bit operation. Den slags må man hoppe i assembler for at gøre. Og der kunne godt være lidt mere ensartethed mht. deklarationer. Se bare alle de måder man kan lave structs på f.eks.
... bare for at sige at C og C++ ikke er rosenrøde. De er gamle støvede sprog der har overlevet fordi de er så udbredte, de er ikke perfekte.
Angående padding af structs er ikke et problem, du kan benytte "__attribute__((__packed__)) " til at "pakke" din struct. Little/Big Endian er system specifik, så den implementering du laver burde kunne portes til andre systemer. Men jo hvis man får data fra andre systemer direkte som benytter en anden Endian, så skal man lave det selv, men det skal man også i andre sprog. Hvis har behov hvor en bestemt optimering f.eks i forbindelse med gange eller division så skal man i assembler. Men du kan gøre det hvis du skal, inline, det er der ikke mange andre sprog der tilbyder.
Ja, C og C++ er samlet set i forhold til hvornår de er udviklet, og nej bestemt ikke perfekte, det er der nok intet der er. Men i rigtig mange tilfælde er C/C++ det bedste værktøj. Software udvikling er big business, og hvis der kom andre sprog som var bedre/hurtigere en C/C++ til hvad det gør, så ville de fleste meget hurtigt skifte.
arne_v (27) skrev:
Øh.
Det har vel udelukkende med C og C++ at gøre.
Styre systemet har en måde at finde størrelsen af en fil på. Det er givet. Men det er jo ikke emnet de diskueterer.
Diskussion drejer sig om C og C++ bibliotekernes funktioner til at hente den information og den retur type de er erklæret med.
Min pointe er at hvis man udvikler kompliceret kode, bør man benytte styresystemets API til at finde den type information, jo det er måske nemmere at bruge en pæn template, men du mister meget kontrol, hvilket de jo klager over.
Sprog fra 1990-2005 kopierede meget C/C++ syntax.
Men idag skifter man et større eller mindre omfang til andre syntaxer.
Hvis du kigger på de top 10 mest brugte sprog er 9/10 baseret på C Syntax, de nyeste er fra 2014. Hvorfor skulle man også ændre det, det virker. "If it ain't broken..."
Det har vel alt at gøre med sproget. Både OO og FP ligger mest i sproget og kun begrænset i library/runtime.
FP er et paradigme, har intet med sprog, biblioteker eller runtime at gøre. De biblioteker og API'er du benytter har ikke indflydelse på hvorvidt du overholde reglerne for FP i din kode. Eneste forskel er at nogen sprog kun understøtter FP, og tvinger dig til det. Jeg kan lave helt det samme kode i C/C++ som jeg kan i Scala.
Der findes stadig buffer overflow fejl og andre fejl i testede biblioteker.
Ja, helt enig, det gør der i alle sprog, systemer mm. I sidste ende er alt maskinkode på en CPU. Man kan lave alle de sanity checks man vil, men du kan aldrig vide dig sikker. Uanset sprog.
#32
Jeg vil argumentere for at uden closures så har man ikke mulighed for funktionelt programmering.
Og meget funktionelt programmering er også bygget op omkring et bestemt API set (map/reduce) som ikke findes i alle sprog. F.eks. fik C++ først std::reduce i C++17.
Jeg vil argumentere for at uden closures så har man ikke mulighed for funktionelt programmering.
Og meget funktionelt programmering er også bygget op omkring et bestemt API set (map/reduce) som ikke findes i alle sprog. F.eks. fik C++ først std::reduce i C++17.
Septi (31) skrev:
Angående padding af structs er ikke et problem, du kan benytte "__attribute__((__packed__)) " til at "pakke" din struct.
Bemærk at det ikke er en standard feature, men en feature i visse implementationer.
Septi (31) skrev:
Little/Big Endian er system specifik, så den implementering du laver burde kunne portes til andre systemer. Men jo hvis man får data fra andre systemer direkte som benytter en anden Endian, så skal man lave det selv, men det skal man også i andre sprog.
Nej.
Både i Java og .NET får man det med.
Septi (32) skrev:arne_v (27) skrev:
Øh.
Det har vel udelukkende med C og C++ at gøre.
Styre systemet har en måde at finde størrelsen af en fil på. Det er givet. Men det er jo ikke emnet de diskueterer.
Diskussion drejer sig om C og C++ bibliotekernes funktioner til at hente den information og den retur type de er erklæret med.
Min pointe er at hvis man udvikler kompliceret kode, bør man benytte styresystemets API til at finde den type information,
Stort set alle sprog kommer med den funktionalitet: Java, .NET, C, PHP, nu C++.
Så nej man bruger ikke altid OS API til det.
Nogen sætter pris på portabilitet.
Septi (32) skrev:
jo det er måske nemmere at bruge en pæn template, men du mister meget kontrol, hvilket de jo klager over.
Som jeg læser det så klager de mest over de valgte retur type. Det har ikke noget me dkontrol at gøre. Men dækker over C og C++ meget vide rammer for implementationer som gør livet hårdt for de gode udviklere i disse sprog.
Septi (32) skrev:
Sprog fra 1990-2005 kopierede meget C/C++ syntax.
Men idag skifter man et større eller mindre omfang til andre syntaxer.
Hvis du kigger på de top 10 mest brugte sprog er 9/10 baseret på C Syntax, de nyeste er fra 2014. Hvorfor skulle man også ændre det, det virker. "If it ain't broken..."
Sådan ser det ud hvis man kun kigger på curly brackets.
Men går man lidt dybere ser man at ?:, switch etc. bliver erstattet eller suppleret med andre konstruktioner.
Septi (32) skrev:
Det har vel alt at gøre med sproget. Både OO og FP ligger mest i sproget og kun begrænset i library/runtime.
FP er et paradigme, har intet med sprog, biblioteker eller runtime at gøre. De biblioteker og API'er du benytter har ikke indflydelse på hvorvidt du overholde reglerne for FP i din kode. Eneste forskel er at nogen sprog kun understøtter FP, og tvinger dig til det. Jeg kan lave helt det samme kode i C/C++ som jeg kan i Scala.
Det er umuligt at lave FP i et sprog som ikke har data typer til at indeholder funktioner.
Det er meget besværligt at lave FP i et sprog som ikke har mulighed for lamda/anonyme funktioner med capture af kontekst.
Du kan i C++ er fordi C++ har FP support i sproget.
C har function pointer men mangler resten.
Septi (32) skrev:
Der findes stadig buffer overflow fejl og andre fejl i testede biblioteker.
Ja, helt enig, det gør der i alle sprog, systemer mm. I sidste ende er alt maskinkode på en CPU. Man kan lave alle de sanity checks man vil, men du kan aldrig vide dig sikker. Uanset sprog.
Korrekt.
Men nogen sprog fanger fejl tidligere/nemmere end andre.
Compile time fejl er bedre end runtime fejl hvor problemet findes.
Runtime fejl hvor problemet findes er bedre end runtime fejl på et andet sted senere.
C og C++ er sprog som giver den sidste type fejl oftere end stort set alle andre sprog (assembler ikke inklusive).
Claus Jørgensen (33) skrev:#32
Jeg vil argumentere for at uden closures så har man ikke mulighed for funktionelt programmering.
Og meget funktionelt programmering er også bygget op omkring et bestemt API set (map/reduce) som ikke findes i alle sprog. F.eks. fik C++ først std::reduce i C++17.
Det er vigtigt ikke at blande C/C++ sammen med de standard biblioteker som er med, hvilket er system specifikt. Du kan godt lave ordentlig FP i C/C++, det er ikke nødvendigvis kønt, men det er fordi at C og C++ er meget hardware nært. Når vi snakker FP, rykker vi også meget langt væk fra hardware, og over i det meget akademiske. Uagtet findes der faktisk mange gode biblioteker som understøtter FP i C++ hvis man gerne vil det fungere faktisk rigtig godt, og er på højde med sprog som grundlæggende er FP orienteret.
Jeg kan anbefale at kigge på https://www.researchgate.net/publication/220177604...
Men igen, C/C++ er et værktøj til at løse problemer, som alt andre er. Hvis du har et problem hvor den primære udfordringer er at det skal løses med FP, vil jeg aldrig kigge på C/C++.
arne_v (35) skrev:
Bemærk at det ikke er en standard feature, men en feature i visse implementationer.
Alle C/C++ kompilere understøtter packed strukture, med forskellige keywords (mit eksempel var fra GCC), det er brugt utroligt meget i driver udvikling og netværks programmering. Hvordan den enkelte kompilere skal sættes op, kan variere, men er ikke nogen større udfordring.
arne_v (35) skrev:
Nej.
Både i Java og .NET får man det med.
Så må du gerne demonstreret hvordan java eller .Net kan vurdere om 4 tilfældige bytes i et word er Big eller Little Endian? før eller siden skal du fortælle systemet hvordan disse data skal fortolkes, er det et word, eller et array på 4 bytes etc. Data er i sidste ende jo bare bytes i hukommelsen, det er udvikleres (eller kompileres om) job at fortælle computere hvordan de skal fortolkes.
#41
Jeg er uenig. Standard biblioteker er vigtige. Vores arbejde som software udviklere at løse problemer effektivt og kosteffektivt. Sprog med gode standard biblioteker gør os mere effektive. Og når vi siger C++ mener vi ikke "sproget C++ og intet mere" men "sproget C++ and the standard library".
Funktionalitet som map, reduce og andre higher-order functions tillader dig at skrive kode med mindre fejl, mindre muligheder for fejl (side-effects), og imo. kode som nemmere at læse og forstå.
Jeg er uenig. Standard biblioteker er vigtige. Vores arbejde som software udviklere at løse problemer effektivt og kosteffektivt. Sprog med gode standard biblioteker gør os mere effektive. Og når vi siger C++ mener vi ikke "sproget C++ og intet mere" men "sproget C++ and the standard library".
Hvis du har et problem hvor den primære udfordringer er at det skal løses med FP, vil jeg aldrig kigge på C/C++.Jeg tror ikke rigtig du forstår hvordan FP bliver brugt i moderne sprog som C#, Swift og Javascript.
Funktionalitet som map, reduce og andre higher-order functions tillader dig at skrive kode med mindre fejl, mindre muligheder for fejl (side-effects), og imo. kode som nemmere at læse og forstå.
arne_v (37) skrev:
Stort set alle sprog kommer med den funktionalitet: Java, .NET, C, PHP, nu C++.
Så nej man bruger ikke altid OS API til det.
Nogen sætter pris på portabilitet.
Nej, det har disse sprog ikke, de har en standard syntax (bibliotek eller indbygget) som kalder operativsystems API på dine vegne. Det er efter min mening ikke særlig smart da et API kan ændres, eller returnere forskellige strukturer af data alt efter operativsystemet som så skal fortolkes. Det er betydeligt nemmere at kun at holde styr på om et operativ systems API ændre sig. Men det er jo smag og behag.
arne_v (38) skrev:
Sådan ser det ud hvis man kun kigger på curly brackets.
Men går man lidt dybere ser man at ?:, switch etc. bliver erstattet eller suppleret med andre konstruktioner.
Det kan jo blive en lang diskussion hvis man skal ned og vurder hvor meget de har lånt af C/C++. Nogle meget, andre mindre.
Det er umuligt at lave FP i et sprog som ikke har data typer til at indeholder funktioner.
Det er meget besværligt at lave FP i et sprog som ikke har mulighed for lamda/anonyme funktioner med capture af kontekst.
Du kan i C++ er fordi C++ har FP support i sproget.
C har function pointer men mangler resten.
Jeg er enig i at C er begrænset da det ikke har de udvidelsesmuligheder som der er i C++ , ihvertfald ikke i samme grad. Men de biblioteker og det research jeg har læst omkring FP i C++, er minimum på højde med sprog som er dedikeret til formålet.
arne_v (39) skrev:
Korrekt.
Men nogen sprog fanger fejl tidligere/nemmere end andre.
Compile time fejl er bedre end runtime fejl hvor problemet findes.
Runtime fejl hvor problemet findes er bedre end runtime fejl på et andet sted senere.
C og C++ er sprog som giver den sidste type fejl oftere end stort set alle andre sprog (assembler ikke inklusive).
Det lyder mere som du diskutere managed vs. unmanaged kode? Enig i at det er bedre at "Fail Fast". Men i alle unmanaged sprog sidder du med de samme udfordringer, blandt unmanaged sprog er C/C++ klart det bedste.
Claus Jørgensen (43) skrev:#41
Jeg er uenig. Standard biblioteker er vigtige. Vores arbejde som software udviklere at løse problemer effektivt og kosteffektivt. Sprog med gode standard biblioteker gør os mere effektive. Og når vi siger C++ mener vi ikke "sproget C++ og intet mere" men "sproget C++ and the standard library".Hvis du har et problem hvor den primære udfordringer er at det skal løses med FP, vil jeg aldrig kigge på C/C++.Jeg tror ikke rigtig du forstår hvordan FP bliver brugt i moderne sprog som C#, Swift og Javascript.
Funktionalitet som map, reduce og andre higher-order functions tillader dig at skrive kode med mindre fejl, mindre muligheder for fejl (side-effects), og imo. kode som nemmere at læse og forstå.
Helt enig angående C++ og STL. Jeg burde have formuleret mig mere klart, og blot skrevet biblioteker som kan benyttes med C++. Jeg mente ikke standard biblioteker som i STL.
Angående FP, så er jeg fuldt på højde med paradigmet går ud på, blandt andet er der ingen af de sprog du nævner som tvinger "Pure Functional programming". Jeg mener det er et paradigme fordi det intet har med den måde en CPU virker på.
Jo, det kan være super elegant, men det er ikke en universel løsning på alle problemer vi har i softwareudvikling, så langt fra. Ja det har mange fordele som du blandt andet nævner, samt parallelisering af kode, da du har frakoblet data fra kode. Som så mange andre udviklings paradigmer har det helt klart sine fordele og ulemper.
Men hverken Scala, Haskell eller andre FP sprog gør noget magiske, andet end at holde dig inden for paradigmet. Hvis du så rent faktisk kompilere Haskell bliver det jo lige lavet til C kode først.
Igen handler det om at vælge det rigtig værktøj til jobbet, og lade vær med at stirre sig blind på kun en måde at gøre tingene på. Det kommer der sjældent noget godt ud af.
Vi kan så diskutere hvornår det bør benyttes. For mig handler det om nemt at kunne paralleliserer sin kode i forbindelse med f.eks Big Data analyse eller i forsknings brug, hvor det er kunne regne sig frem og bevise en systems tilstand er mere vigtigt en effektivitet.
Septi (42) skrev:arne_v (35) skrev:
Bemærk at det ikke er en standard feature, men en feature i visse implementationer.
Alle C/C++ kompilere understøtter packed strukture, med forskellige keywords (mit eksempel var fra GCC), det er brugt utroligt meget i driver udvikling og netværks programmering. Hvordan den enkelte kompilere skal sættes op, kan variere, men er ikke nogen større udfordring.
Det ender med et stort antal ifdef'er hvis ens kode skal bruges på flere platforme.
Septi (42) skrev:arne_v (35) skrev:
Nej.
Både i Java og .NET får man det med.
Så må du gerne demonstreret hvordan java eller .Net kan vurdere om 4 tilfældige bytes i et word er Big eller Little Endian? før eller siden skal du fortælle systemet hvordan disse data skal fortolkes, er det et word, eller et array på 4 bytes etc. Data er i sidste ende jo bare bytes i hukommelsen, det er udvikleres (eller kompileres om) job at fortælle computere hvordan de skal fortolkes.
Spørgsmålet var ikke om man skulle vide om det er big eller little endian spørgsmålet er om man selv skal kode efter det.
Du glemte citatet af dig:
Septi (31) skrev:
Little/Big Endian er system specifik, så den implementering du laver burde kunne portes til andre systemer. Men jo hvis man får data fra andre systemer direkte som benytter en anden Endian, så skal man lave det selv, men det skal man også i andre sprog.
Fed skrift er tilføjet af mig.
Man skal selv tilføje en del kode i C og C++.
I Java sætter man bare order på sin java.nio.ByteBuffer. Det er transparent for alle metoder og fuldt portabelt.
Og så må jeg tilstå at jeg kan ikke finde den mulighed i .NET + jeg mener at jeg gar set det, men jeg kan ikek finde det, så må tager jeg fejl med det.
Septi (41) skrev:Claus Jørgensen (33) skrev:#32
Jeg vil argumentere for at uden closures så har man ikke mulighed for funktionelt programmering.
Og meget funktionelt programmering er også bygget op omkring et bestemt API set (map/reduce) som ikke findes i alle sprog. F.eks. fik C++ først std::reduce i C++17.
Det er vigtigt ikke at blande C/C++ sammen med de standard biblioteker som er med, hvilket er system specifikt.
????
Definitionen på et standard bibliotek er at det ikke er system specifikt men defineret i sprogets standard og derfor findes på alle systemer.
C++ standarden definerer en række biblioteker som skal være der. For C++ 11 er det kapitlerne 18-30.
Septi (44) skrev:arne_v (37) skrev:
Stort set alle sprog kommer med den funktionalitet: Java, .NET, C, PHP, nu C++.
Så nej man bruger ikke altid OS API til det.
Nogen sætter pris på portabilitet.
Nej, det har disse sprog ikke, de har en standard syntax (bibliotek eller indbygget) som kalder operativsystems API på dine vegne.
Det betyder at de sprog tilbyder funktionalitet til udvikleren. Det kan i sagens natur ikke implementeres uden at kaldet noget i styresystemet.
Septi (44) skrev:
Det er efter min mening ikke særlig smart da et API kan ændres, eller returnere forskellige strukturer af data alt efter operativsystemet som så skal fortolkes. Det er betydeligt nemmere at kun at holde styr på om et operativ systems API ændre sig. Men det er jo smag og behag.
Det er rigtigt smart.
Der er hundredetusinder af eksempler på at man har porteret applikationer mellem OS.
Jeg tror at der er nul eksempler på at styresystemet har ødelagt sprog bibliotek ved at ændre API for filstørrelse.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund