Ik ben altijd een embedded software engineer geweest, maar meestal op laag 3 of 2 van de OSI-stack. Ik ben niet echt een hardware man. Ik heb over het algemeen altijd telecomproducten gemaakt, meestal met de hand/mobiele telefoons, wat over het algemeen zoiets als een ARM 7-processor betekent.
Nu bevind ik me in een meer generieke embedded wereld, in een kleine start-up, waar ik misschien overstap naar “niet zo krachtige” processors (er is het subjectieve deel) – ik kan niet voorspellen welke.
Ik heb nogal wat gelezen over het debat over het gebruik van STL in C++ in embedded systemen en er is geen duidelijk antwoord. Er zijn wat kleine zorgen over draagbaarheid, en een paar over codegrootte of runtime, maar ik heb twee grote zorgen:
1 – uitzonderingsbehandeling; Ik weet nog steeds niet zeker of ik het moet gebruiken (zie Embedded C++: om exceptions of niet?)
2 – Ik heb een hekel aan dynamische geheugentoewijzing in embedded systemen, vanwege de problemen die het kan veroorzaken. Ik heb over het algemeen een bufferpool die statisch wordt toegewezen tijdens het compileren en die alleen buffers met een vaste grootte bedient (indien geen buffers, systeemreset). De STL doet natuurlijk veel dynamische toewijzing.
Nu moet ik de beslissing nemen om de STL te gebruiken of af te zien – voor het hele bedrijf, voor altijd (het gaat in een zeer kern-s/w).
Op welke manier spring ik? Superveilig & veel verliezen van wat C++ is (imo, het is meer dan alleen de taaldefinitie) en misschien later in de problemen komen of veel exception handling moeten toevoegen & misschien nu een andere code?
Ik kom in de verleiding om gewoon met Boostte gaan, maar 1) ik weet niet zeker of het naar elke embedded processor die ik zou willen gebruiken en 2) op hun website, ze zeggen dat ze bepaalde delen ervan niet garanderen/aanbevelen voor embedded systemen (vooral FSM’s, wat raar lijkt). Als ik voor Boost & we vinden later een probleem ….
Antwoord 1, autoriteit 100%
Ik werk elke dag aan realtime embedded systemen. Natuurlijk kan mijn definitie van embedded systeem anders zijn dan die van jou. Maar we maken volop gebruik van de STL en uitzonderingen en ondervinden geen onhandelbare problemen. We maken ook gebruik van dynamisch geheugen (met een zeer hoge snelheid; veel pakketten per seconde toewijzen, enz.) en hebben nog geen toevlucht hoeven nemen tot aangepaste toewijzingen of geheugenpools. We hebben zelfs C++ gebruikt in interrupt-handlers. We gebruiken geen boost, maar alleen omdat een bepaalde overheidsinstantie dat niet toelaat.
Het is onze ervaring dat je inderdaad veel moderne C++-functies in een embedded omgeving kunt gebruiken, zolang je je hoofd gebruikt en je eigen benchmarks uitvoert. Ik raad je ten zeerste aan om Scott Meyer’s Effective C++3e editie te gebruiken, evenals de C++ Coding Standardsvan Sutter en Alexandrescu om je te helpen bij het gebruik van C++ met een verstandige programmeerstijl.
Bewerken: nadat ik hier 2 jaar later een positieve stem over heb gekregen, wil ik graag een update plaatsen. We zijn veel verder in onze ontwikkeling en we hebben eindelijk plekken in onze code bereikt waar de standaard bibliotheekcontainers te traag zijn onder hoge prestatieomstandigheden. Hier hebben we inderdaad onze toevlucht genomen tot aangepaste algoritmen, geheugenpools en vereenvoudigde containers. Dat is echter het mooie van C++, je kunt de standaardbibliotheek gebruiken en alle goede dingen krijgen die het biedt voor 90% van je gebruiksscenario’s. Je gooit niet alles weg als je problemen tegenkomt, je optimaliseert de probleemplekken gewoon met de hand.
Antwoord 2, autoriteit 71%
Superveilig & veel verliezen van wat
vormt C++ (imo, het is meer dan
alleen de taaldefinitie) en
misschien later in de problemen komen of hebben
om veel uitzonderingsbehandeling toe te voegen &
misschien nu een andere code?
We hebben een soortgelijk debat in de gamewereld en mensen komen van beide kanten. Wat betreft het geciteerde deel, waarom zou u zich zorgen maken over het verlies van “veel van wat C++ is”? Als het niet pragmatisch is, gebruik het dan niet. Het zou niet moeten uitmaken of het “C++” is of niet.
Voer een aantal tests uit. Kunt u het geheugenbeheer van STL omzeilen op een manier die u tevreden stelt? Zo ja, was het de moeite? Veel problemen die STL en boost zijn ontworpen om op te lossen, komen gewoon niet naar voren als u ontwerpt om lukrake dynamische geheugentoewijzing te voorkomen… lost STL een specifiek probleem op waarmee u wordt geconfronteerd?
Veel mensen hebben STL aangepakt in krappe omgevingen en waren er blij mee. Veel mensen vermijden het gewoon. Sommige mensen stellen geheel nieuwe normenvoor. Ik denk niet dat er één goed antwoord is.
Antwoord 3, autoriteit 49%
De andere berichten hebben betrekking op de belangrijke problemen van dynamische geheugentoewijzing, uitzonderingen en mogelijke code-bloat. Ik wil alleen toevoegen: vergeet <algorithm>niet! Ongeacht of u STL-vectoren of gewone C-arrays en pointers gebruikt, u kunt nog steeds sort(), binary_search(), random_shuffle()gebruiken , de functies voor het bouwen en beheren van hopen, enz. Deze routines zullen vrijwel zeker sneller en minder buggy zijn dan versies die u zelf bouwt.
Voorbeeld: tenzij je er goed over nadenkt, een shuffle-algoritme dat je zelf bouwt zal waarschijnlijk scheve verdelingen produceren; random_shuffle()niet.
Antwoord 4, autoriteit 37%
Paul Pedriana van Electronic Arts schreef in 2007 een lange verhandelingover waarom de STL niet geschikt was voor de ontwikkeling van embedded consoles en waarom ze er zelf een moesten schrijven. Het is een gedetailleerd artikel, maar de belangrijkste redenen waren:
- STL-toewijzers zijn traag, opgeblazen,
en inefficiënt - Compilers zijn eigenlijk niet zo goed in het inlijnen van al die diepe functieaanroepen
- STL-toewijzers ondersteunen geen expliciete uitlijning
- De STL-algoritmen die bij GCC en de STL van MSVC worden geleverd, presteren niet erg goed, omdat ze erg platformonafhankelijk zijn en daardoor veel micro-optimalisaties missen die een groot verschil kunnen maken.
Enkele jaren geleden heeft ons bedrijf de beslissing genomen om de STL helemaal niet te gebruiken, maar in plaats daarvan ons eigen systeem van containers te implementeren die maximaal presteren, gemakkelijker te debuggen en behoudender van geheugen. Het was veel werk, maar het heeft zich al vele malen terugverdiend. Maar de onze is een ruimte waarin producten concurreren op hoeveel ze in 16,6 ms kunnen proppen met een bepaalde CPU en geheugengrootte.
Wat betreft uitzonderingen: ze zijn traagop consoles, en iedereen die het je vertelt anders heeft niet geprobeerd ze te timen. Gewoon compileren met ze ingeschakeld zal het hele programma vertragen vanwege de noodzakelijke prolog/epilog-code — meet het zelf als je me niet gelooft. Het is nog erger op in orde zijnde CPU’s dan op de x86. Om deze reden ondersteunt de compiler die we gebruiken zelfs geen C++-uitzonderingen.
De prestatiewinst zit hem niet zozeer in het vermijden van de kosten van het weggooien van uitzonderingen, maar in het volledig uitschakelen van uitzonderingen.
Antwoord 5, autoriteit 29%
Laat ik beginnen met te zeggen dat ik al een paar jaar geen embedded werk heb gedaan, en nooit in C++, dus mijn advies is elke cent waard die je ervoor betaalt…
De sjablonen die door STL worden gebruikt, zullen nooit code genereren die u niet zelf hoeft te genereren, dus ik zou me geen zorgen maken over opgeblazen code.
De STL genereert zelf geen uitzonderingen, dus dat zou geen probleem moeten zijn. Als je lessen niet goed zijn, zou je veilig moeten zijn. Verdeel uw objectinitialisatie in twee delen, laat de constructor een kaal object maken en voer vervolgens elke initialisatie uit die zou kunnen mislukken in een lidfunctie die een foutcode retourneert.
Ik denk dat je met alle containerklassen je eigen toewijzingsfunctie kunt definiëren, dus als je wilt toewijzen vanuit een pool, kun je dit laten gebeuren.
6, Autoriteit 8%
Naast alle opmerkingen, zou ik u voorstellen om Technisch rapport over C++ -prestaties die specifiek betrekking hebben op onderwerpen die u geïnteresseerd bent in: het gebruik van C++ in ingebed (inclusief harde real-time systemen); Hoe uitzondering-handling meestal geïmplementeerd en welke overhead het heeft; GRATIS winkel toewijzing’s overhead.
Het rapport is echt goed, evenals worden veel populaire staarten over C++ -prestaties ontkeken.
7, Autoriteit 2%
Op ons embedded scanner-project ontwikkelden we een bord met Arm7 CPU en STL meende geen probleem. Zeker, de projectdetails zijn belangrijk omdat dynamische geheugentoewijzing mogelijk geen probleem is voor vele beschikbare borden en het type projecten.