Doel:€250.00
Donaties:€150.00

Per saldo:€-100.00

Steun ons nu!

Laatst bijgewerkt
op 08-12-2019
Algemeen

De stichting

Recente berichten

Rheinburgh, TP V/VI door Dave.......
Vandaag om 17:58:06
Gezocht: beschrijving om mini pijpenbuiger te maken. Messing buis. door Pauldg
Vandaag om 17:50:56
Mijn eerste H0-modeltreinbaan in aanbouw door Ronald1974
Vandaag om 17:46:34
Afzekeren stroomkringen door hgr
Vandaag om 17:42:37
Toon hier je nieuwe (model-) spooraanwinst(en)... door Remco vM
Vandaag om 17:40:12
Haardvuurtje in de hut door Remco_Nzo
Vandaag om 17:35:08
Bouw Loc NS serie 2100/HSM 500 in H0 (Philotrain kit 870/37) door Gerrit F
Vandaag om 17:22:17
Projekt 083-338 door 44
Vandaag om 17:13:59
Onlangs gespot - gefotografeerd, de foto's door Sander.
Vandaag om 16:49:13
Schwarzburg-Neuffen-Bahn door Eric B
Vandaag om 16:47:07
Probleem met Loksound 3.5 (lok start niet) door bellejt
Vandaag om 16:38:58
LS Models 2019 door nederbelg
Vandaag om 16:35:07
Bemo 2018 door RhB-Mikey
Vandaag om 16:26:39
Bouw Beel + "wat reed er achter de Beel" door Hans van de Burgt
Vandaag om 15:54:44
Roco 2019 door ex-DR V100
Vandaag om 15:53:11
Very USA: The Slug door NS1220
Vandaag om 15:33:37
De Wim Vink 2020 H0 treinen kalender komt eraan. door MOVisser
Vandaag om 15:22:44
De Hondsrugbaan, H0 door Martin Hornis
Vandaag om 15:12:30
Zolderbaan 5 bij 3 meter, Märklin, C-Rail, Digitaal IB+Win Digipet # De bouw door Timaximus
Vandaag om 15:01:50
Afmetingen tankwagens door NS1220
Vandaag om 14:59:49
Wensendraadje Nederlands 2020 door Martin Hornis
Vandaag om 14:59:06
Piko NS1100, materieelbespreking door Floris
Vandaag om 14:57:36
City Noord en Zuid ....eindelijk de bouw door Debvd
Vandaag om 14:44:08
Station Hotaka aan de Oito-lijn (Japan), in spoor Z door Bezoeker
Vandaag om 14:23:31
Geweatherde Challenger, O-schaal, MTH door Jeronimos
Vandaag om 14:21:29
Watertoren van Wageningen. door Duizendpoot
Vandaag om 14:16:47
NCS 7/8 tot NS 61 62 Maffei lok in spoor 0 door FritsT
Vandaag om 13:45:04
Ronald bouwt een demo-pizza layout (je) door Daniel Caso
Vandaag om 13:24:07
Raadplaatje door mardig23
Vandaag om 13:17:02
NS modelbaan Hoekdam H0 door meino
Vandaag om 12:37:21
  

Auteur Topic: De CanBus komt naar Kranenberg, Arduino's en de CanBus  (gelezen 7313 keer)

Klaas Zondervan

  • Offline Offline
  • Berichten: 17803
    • Pagina van klaas
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #30 Gepost op: 11 november 2019, 21:49:41 »
Blijf maar lekker hier doorgaan. Van het meeste begrijp ik geen hol, maar ik lees jullie discussie wel.
Spoorbaan "Uit en Thuis" in aanbouw.

Hennik

  • Offline Offline
  • Berichten: 39
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #31 Gepost op: 11 november 2019, 23:30:27 »
Eens met Klaas! Ik lees ook met zeer veel interesse mee en probeer er wat van op te steken.

Karst Drenth

  • Offline Offline
  • Berichten: 9346
  • NS blauw, groen, rood, bruin, grijs en standgroen
    • Plan U op Sleutelspoor
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #32 Gepost op: 12 november 2019, 00:05:03 »

Het CanBus object daarentegen is met dat soort zaken niet bezig, hij heeft kennis van de berichttypen, beheert de bijbehorende interrupt routines etc. Verder kan hij verschillende configuraties aan, alleen zender, alleen receiver of zender en receiver. Verder zou het kunnen dat ik in de toekomst een ander type interface kaart zou willen gebruiken i.p.v. een mcp2515 kaart. In dat geval moet er een andere klasse komen die dat ondersteund. Dus zou de Mcp2515 eigenlijk een interface definitie moeten zijn zodat ik daar makkelijk een andere klasse achter kan plaatsen.


Ook ik lees het met interesse (y)

Maar je schrijft zoiets als "... eigenlijk een interface definitie ..."  Als professioneel C++ programmeur met bijna 30 jaar ervaring in dat "taaltje" zou ik zeggen: Gebruik het onvolprezen (en vaak niet begrepen) C++ mechanisme van multiple inheritance! Het Java en C# concept van Interfaces is daar direct van afgeleid ;) en werkt in C++ met multiple inheritance nagenoeg identiek aan wat je in Java gewend bent met Interfaces. Een extra plus daarbij is, dat je in tegenstelling tot het Interface concept ook al een, deel van, de implementatie mag en kunt schrijven. Iets dat de "moderne" talen pas sinds ca. 2 jaar kunnen met hun "default methods" in Interfaces ;) Wel is het dan natuurlijk slim kiezen van de methodes die je Virtual wilt/moet maken.

Als je dat slim doet, hoef je ook geen objecten dynamisch te creeren (idd lasting in een Arduino omgeving) immers de nieuwe Class bevat beide georven types en zijn ook direct daarnaartoe te casten. Alle objecten zijn statische instanties van de gedefinieerde Classes, waarbij je via de constructor en zijn parameters de mogelijkheid hebt de aangemaakte instantie nog enigzins te "customizen".

Als werkende voorbeelden van deze techniek, kan ik de DR5000, DR5088, DR5013 en DR5052 aandragen. Met al z'n bussen en protocollen (die allemaal op basis van multiple inheritance werken) etc., die ook nog eens gemixt gebruikt kunnen worden, is er in een micro-controller omgeving bijna geen andere methode denkbaar c.q. haalbaar. (wil je het onderhoudbaar en gestructureerd houden ;) )

Hoe b.v. de class-hierarchie van de brugcontrollers van de DR5052 er uit zien, veel is weggelaten, maar de essentie kun je er wel uit aflezen ;)

class BridgeController : public StationSender, protected  EventHandler<TurnTable*, int> {
  public:
BridgeController(TurnTable* turnTable) {}
};

class PlusController : public StationSender, protected StationHandler<CMD::FeedbackInt_t> {
  public:
PlusController(BridgeController* bridgeController) : bridgeController(bridgeController) {}
};

class BasicController : public StationSender, protected Digital::Interrupt, protected Kernel ::BckGndHandler, protected Kernel ::IdleHandler {
  public:
BasicController(DR5052Controller* bridgeController, PORT_t& portM_SENS, byte pinM_SENS, byte interrupt) :
     Digital::Interrupt( portM_SENS,      pinM_SENS,      interrupt, PORT_ISC_BOTHEDGES_gc) {}
};

class RocoH0Controller : public StationSender, protected Kernel::BckGndHandler, protected StationHandler<CMD::FeedbackInt_t> {
  public:
RocoH0Controller(BridgeController* bridgeController) {}
};

class DR5052Controller : public BridgeController, protected Kernel::IdleHandler {
  public:
DR5052Controller(TurnTable* turnTable, PORT_t& portM_SENS, byte pinM_SENS) : BridgeController( turnTable) {}
};

class DR5052BasicController : public DR5052Controller, public    BasicController {
  public:
DR5052BasicController(TurnTable* turnTable, PORT_t& portM_SENS, byte pinM_SENS, byte interrupt) : DR5052Controller(turnTable, portM_SENS, pinM_SENS),
      BasicController(this, portM_SENS, pinM_SENS, interrupt) {}
};

class DR5052RocoH0Controller : public DR5052Controller, public    RocoH0Controller {
  public:
DR5052RocoH0Controller(TurnTable* turnTable, PORT_t& portM_SENS, byte pinM_SENS) : DR5052Controller(turnTable, portM_SENS, pinM_SENS), RocoH0Controller(this) {}
};

class DR5052PlusController : public DR5052Controller, public PlusController {
  public:
DR5052PlusController(TurnTable* turnTable, PORT_t& portM_SENS, byte pinM_SENS) : DR5052Controller(turnTable, portM_SENS, pinM_SENS), PlusController(this) {}
};

class DR5052ProfiController : public BridgeController, public PlusController {
  public:
DR5052ProfiController(TurnTable* turnTable) : BridgeController(turnTable), PlusController(this) {}
};

class DR5052StepperController : public BridgeController, protected StationHandler<CMD::FeedbackInt_t>, protected Kernel::BckGndHandler, protected Kernel::IdleHandler {
  public:
DR5052StepperController(TurnTable* turnTable) : BridgeController(turnTable) {}
};

Grtzz,
Karst


meino

  • Offline Offline
  • Berichten: 573
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #33 Gepost op: 12 november 2019, 00:39:42 »
Maar je schrijft zoiets als "... eigenlijk een interface definitie ..."  Als professioneel C++ programmeur met bijna 30 jaar ervaring in dat "taaltje" zou ik zeggen: Gebruik het onvolprezen (en vaak niet begrepen) C++ mechanisme van multiple inheritance! Het Java en C# concept van Interfaces is daar direct van afgeleid ;) en werkt in C++ met multiple inheritance nagenoeg identiek aan wat je in Java gewend bent met Interfaces. Een extra plus daarbij is, dat je in tegenstelling tot het Interface concept ook al een, deel van, de implementatie mag en kunt schrijven. Iets dat de "moderne" talen pas sinds ca. 2 jaar kunnen met hun "default methods" in Interfaces ;) Wel is het dan natuurlijk slim kiezen van de methodes die je Virtual wilt/moet maken.

Dag Karst bedankt voor je reactie. En je informatie en kennis van C++.
Ik moet eerlijk zeggen dat ik gepokt en gemazeld ben in C (vanaf 1985). Met C++ kwam ik in aanraking ergens rond 87-88 via een cursus bij AT Computing in Nijmegen. Maar toen was het idee van OO totaal nog niet bekend, ik kan me herinneren dat het meeste ging over operator overloading. C++ heeft bij mij altijd op het tweede plan gestaan. Pas rond 1995 kwam het idee van OO (Object Oriented) meer op de voorgrond. Dat is de zelfde tijd dat we met JAVA in aanraking kwamen. Dat was ook de periode dat het kwartje viel en ik samen met een paar geestverwanten de OO werkwijze binnen ons bedrijf heb geintroduceerd.  Dus veel van mijn manier van denken en werken (ook in C++) is gebaseerd op JAVA (en UML). C++ kent niet een echte interface definitie zoals JAVA dat kent. Een abstracte, virtuele base class komt nog het dichts bij het principe van een interface, daar ben ik dan nu ook mee bezig om dat in de CanBus te implementeren.

Maar gezien de reacties blijf ik toch actief met deze discussie in dit draadje.

Groet Meino
A clean desk is a sign of an empty mind

Kranenberg

Erik Baas

  • Offline Offline
  • Berichten: 71
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #34 Gepost op: 12 november 2019, 00:54:04 »
Ga er vooral mee door, alsjeblieft! Als beginnend Arduino-gebruiker, weliswaar met veel ervaring in Clipper en VB, steek ik er weer eens wat van op! :-)

bask185

  • Offline Offline
  • Berichten: 242
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #35 Gepost op: 12 november 2019, 08:26:10 »
Hoe bedoel je? Kan je een voorbeeld geven?
Nou ik heb vandaag weer iets nieuws geleerd. Ik had technisch gezien geen ongelijk, maar ook geen gelijk. Het verschilt namelijk per compiler of een const int is toe gestaan in een switch-case label: bron

Van GCC mag het wel. Van mijn C-compiler mag het niet  :-\

Wat voor vervanging heb je in C++ eigenlijk voor een switch case.
En waarom vind je een switch case 'zwak' in C++.

En ik ben ook erg lui :-D. Dat is namelijk een goede programmeurs eigenschap. Ik wil zo veel mogelijk doen met zo min mogelijk werk, daarom maak ik scripts om zo veel taken van me over te nemen als mogelijk.  Ik laat scripts zo veel als mogelijk code voor me kloppen. Dan hoef ik niet meer na te denken over de structuur. Waar welke code hoort te komen, staat al vast. Door de code generatie kan ik minder tikfouten maken, en door de structuur, logica en simpelheid maak ik aanzienlijk minder bugs. Ik heb nu een gestripte werk versie sinds kort op github gezet, maar die is nog niet klaar.
« Laatst bewerkt op: 12 november 2019, 08:32:57 door bask185 »

Te 2/2

  • Offline Offline
  • Berichten: 653
  • Metrop-Märklin
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #36 Gepost op: 12 november 2019, 17:26:25 »
Wat voor vervanging heb je in C++ eigenlijk voor een switch case.
Bedoel je zoiets als dit
Jan Willem

analoog hybride DC baan (2-rail+3-rail),
CH, peco, piko, roco, k-rail

bask185

  • Offline Offline
  • Berichten: 242
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #37 Gepost op: 14 november 2019, 09:25:44 »
Bedoel je zoiets als dit

Dit is toch ruk in elk mogelijk opzicht. Het enige wat het meer kan, is strings gebruiken als case-labels. Heb je die syntax wel eens bekeken? En dan wordt mijn switch-case met een macro 'onduidelijk' genoemd omdat het 'niet standaard' is.
Dat C++ is echt een draak van een programmeer taal.  Waardeloze syntax is onleesbaar. De relatie tussen C en C++ is als de relaties tussen een mens en een gezwel. Ik vind alleen de klasses en OO stijl een waardevolle toevoeging.

void switch2(const Key_t& key,
    const std::vector<std::pair<Key_t, std::function<void()>>>& pairs,
    const std::function<void()>& def)
{
    std::unordered_map<Key_t, std::function<void()>> dict;
    for (const auto& entry : pairs)
        dict.insert(entry);
    assert(dict.size() == pairs.size());
    const auto it = dict.find(key);
    if (it != dict.end())
        it->second();
    else
        def();

...


{
        std::string input;
        std::cin >> input;

        switch2(input, {
            {"hi", defer(say, "hey")},
            {"whazzup", defer(say, "wazzuuuup")},
            {"bye", defer(quit, "see ya", &running)}},
            defer(say, "wat?"));
    }
}

Ik geloof ook niet dat dit efficient is. Om te beginnen, vervang je een echte switch-case door een functie call met variabelen argumenten. Dat is al trager dan een switch-case. Bovendien is het gebruik van strings voor case labels niet praktisch. Ik weet niet precies hoe het werkt, maar volgens mij moet je strings gaan vergelijken om de juiste case uit te voeren. Daar verlies je ook al efficiency.

Waarom zou je eigenlijk strings willen hebben ipv een simpele constante? Het voornaamste verschil zijn de "" om de 'label' heen.

Als je een Arduino (of een ander embedded apparaat) programmeert, wil je dat:
A. je code leesbaar
B. dat je code snel wordt uitgevoerd
C. Je programma niet onnodig groot wordt qua geheugen gebruik.

Het voorbeeld wat je gaf, voldoet volgens mij aan geen van de punten. A is duidelijk, of eigenlijk 'bijzonder onduidelijk'. Aan B twijfel ik, ik weet niet wat de compiler daar van bakt. Maar denk nog steeds niet dat het sneller is dan een conventionele switch-case. En wat C betreft... Heb je gezien wat er allemaal geinclude wordt en wat voor aanvullende functies er allemaal bij komen kijken?

Dit proberen te gebruiken in een Arduino om...ja wat willen we hiermee nu bereiken?  is wat ik noem: "deliberately shooting yourself in the foot".

meino

  • Offline Offline
  • Berichten: 573
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #38 Gepost op: 14 november 2019, 14:24:19 »
Ok, ik wil toch even reageren, omdat ik het gevoel krijg dat hier een richtingenstrijd aan staat komen. Dat lijkt me niet nuttig want alleen insiders zullen dat begrijpen. Ik heb gemerkt dat er ook anderen, met misschien wat minder ervaring, dit volgen.

In het kort gaat het om wel of geen macro's gebruiken.
Ik weet het niet zeker, maar ik krijg ook het gevoel dat dit sterk beinvloed is door wat er momenteel op universiteiten geleerd wordt. Dit doet me denken aan midden jaren 80, toen vooral onder universitaire docenten een sterke minachting voor de taal C bestond. Een taal die niet bruikbaar was, vol met ambiguiteiten, niet type vast, geen controle op de goede functie aanroep, etc. Dat klopt want de K&R C kent dat allemaal niet. En toen werden vooral talen als Pascal en Modula-2 sterk gepropageerd als de nieuwe supertalen. Ook een taal als Lisp was daar erg populair, waar ik toen werkte werdt Lisp gekscherend bestempeld als een taal voor haakjes liefhebbers (zijn er hier nog Lisp programmeurs aanwezig?).
Pas met de ANSI C standaard werd een deel van deze intrensieke problemen opgelost, maar ook in de 90er jaren werd nog veel in K&R stijl gewerkt. Ik meen dat Kernighan ooit gezegd heeft "C provides all the rope to hang yourself", waarop iemand anders zei, en "C++ doet dat in het kwadraat". Kortom dat Bask185 C++ een draak van een taal vindt, daar herken ik wel wat in. Ik zelf in de beginntijd heb ook nooit sterk de behoefte gevoeld om veel met C++ te doen. Dat veranderde pas begin jaren 90 toen het begrip OO (Object Oriented ..) opeens in het voetlicht kwam te staan. Toen werden de intrinsieke OO kwaliteiten van C++  zichtbaar. Wat nog versterkt werd toen JAVA op het toneel verscheen.

Maar wat we moeten beseffen is niet wat je allemaal met een taal kunt doen (dat is alleen van belang als je aan de Obfuscated C competitie wilt meedoen) maar de beperkingen die je jezelf oplegt in het gebruik van een taal, waardoor een programma ook voor een ander leesbaar en begrijpbaar wordt.
Ik heb ooit een Coding standaard geschreven voor mijn team programmeurs, om te trachten dit voormekaar te krijgen. Je wilt niet weten hoeveel weerstand dit opgeroepen heeft.

Maar waar draaide deze discussie ook al weer over, het gebruik van #defines en macro's. Ik ben een oude ***, uit een tijd dat dit handige tools waren, zeker als je in BAL (Basic Assembler Language) programmeert. Ook in C heb ik uitgebreid macro's ontwikkeld voor precies die zaken die bask185 ook beschrijft. Dat kan heel handig zijn. Maar het blijven extensie van de oorspronkelijke taal, en als zodanig voor buitenstaanders onbekend, wat een nadeel kan zijn. Binnen een ontwikkelteam hoeft dat geen probleem te zijn zolang er leden zijn die wel van de hoed en de rand weten.
Dus enige zelfrestrictie ten aanzien van het gebruik binnen deze doelgroep (Forumleden die iets met Arduino's willen doen) is wel op zijn plaats. Verder het bij voorkeur gebruiken van enums i.p.v een #define heeft zeker nut. Maar het is niet zo dat al het gebruik van een #define uit de boze is. Ik blijf dat gebruiken om bijvoorbeeld debug code wel of niet op te nemen, dus als een instructie aan de compiler.

preekmode=off;

Groet Meino
A clean desk is a sign of an empty mind

Kranenberg

bask185

  • Offline Offline
  • Berichten: 242
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #39 Gepost op: 14 november 2019, 15:51:26 »
Je wilt niet weten hoeveel weerstand dit opgeroepen heeft.
Ik geloof je meteen. Zodra je iets niet standaard doet in programmeerwereld of elektronicawereld-> meteen tegenstand.

Heb ik ook nog een grappig klein verhaaltje over. Ik begon hier als eerste in C. Tijdens het ontwikkelen, moest ik ook nog structuur zaken leren ed. Ik kwam net van school af. Zo kwam ik ook tot een bepaalde keuze van accolade gebruik. Ik had een klein hapje genomen van python destijds. En de accolade gebruik van python vond ik erg interessant, want die was er niet. Ik vond de standaard accoladegebruiken in C niet perfect. 'else' achter een '}' en case labels op half 11. En ik wilde het eigenlijk net als python hebben. Dus ik ontwierp:
if(x < 5) {
    if(y > 6) {
        doeIets();
        if(z == 7) {
            doeIetsAnders(); } }
    helloWorld(); }
Mijn methode lijkt op de lisp methode zoals ik dat op wikipedia zie. Vind het wel grappig dat mijn gekozen stijl er nog niet tussen staat::)

Als je al aan de indentation kan zien wat waar bij hoort. Dan waarom een trap van sluit accolades maken? Waarom extra wit regels toevoegen. Volgens python was dat niet nodig. Tijdens het gebruik, begon ik hem alsmaar beter te vinden. Ik hou een stricte logica aan. 1x openen is 1 inspring voorwaarts en 3x sluit accolade = volgende regel 3 inspringingen terug. Vooral bij lange complexe functies vond ik het niet onduidelijker dan de andere formats. Ik had alleen minder onnodige witregels.

Je kan natuurlijk raden hoe nieuwe collega's er op reageerden, en hoe verscheidene forum mensen reageerden. "het is zo moeilijk te lezen", "please format your code properly so that everybody can read it" en dan gingen m'n collega's ook nog zo hard muiten dat ze het niet voor dat ene enkele project de stijl eventjes overnamen. Ik had me al neergelegd om een andere stijl te pakken voor het volgende project, maar nu hadden we 1 project met 2 stijlen door elkaar, stelletje ketters!

Mensen willen het ook gewoon geen eerlijke kans geven.

meino

  • Offline Offline
  • Berichten: 573
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #40 Gepost op: 14 november 2019, 19:06:20 »
Yep, het blijft verwonderlijk dat zoiets simpels als een indentatie stijl zoveel weerstand kan oproepen.

Groet Meino
A clean desk is a sign of an empty mind

Kranenberg

Timo

  • Team encyclopedie
  • Offline Offline
  • Berichten: 4539
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #41 Gepost op: 17 november 2019, 00:23:59 »
Wow, wist niet dat we zo veel meelezende "fans" hadden  :o ;D

Maar wat Karst liet zien is inderdaad een mooi (complexer) voorbeeld van wat ik bedoelde om al het dynamisch creëren te kunnen elimineren. (y)

Zelf ben ik een elektrotechnieker die vroeger al interesse had in computers en zo toen al her en der verschillende talen gebruikte. HTML, CSS, PHP, shell, C, Ladder, Java, ActionScript, Sass etc. Maar toen nooit echt verdiept in een taal. Maar dit heeft denk ik wel geholpen met en systematisch kunnen denken. Tijdens mijn studie voor het eerst echt kennis gemaakt met OO (via Java) maar ook meer met microcontrollers gaan doen. Eerst in C (PIC) en later meer en meer C++ (Atmel en later Arduino, ESP en STM etc). En daarom wel steeds meer gaan verdiepen in C++ maar ik ben er geen professional in. Ik leer ook nog steeds bij ieder project wat ik doe. Tegenwoordig maak ik testsystemen voor allerhande elektronica. Dus naast elektronica kennis gebruik ik ook daar weer alle mogelijke talen die mogelijk zijn of moet ik er in ieder geval wat zinnigs mee kunnen ;D C/C++, Python, LabView (kan je dat een taal noemen :angel:), HTML, Ladder, SQL, FBD, SCL, Shell, Batch file, VB(A) etc. Help wel om gestructureerd door een programma te gaan maar niet om de ins en outs van een taal te onthouden ::) Moet het dus nog steeds van de hobby en vrij tijd hebben maar dan heeft C++ (voor uC's) wel de meeste interesse. Nu alleen nog wat meer tijd... ::)

Hier was ik dan ook vooral nieuwsgierig. Helemaal omdat macro's juist vaak gebruikt worden omdat het makkelijk is of de enige bekende manier. Maar de compiler kan je er dan niet bij helpen. Vandaar meer soort vraag naar het er bewust over gedacht hebben of niet. Zo ja, prima :)

En het wel of niet gebruiken van macro's, zoals ik al aan gaf vind ik het wel mooi dat de compiler je kan helpen (zowel in optimalisatie als errors) bij gebruik van C++ alternatieven. Maar niet alles heeft een alternatief en de meeste zijn uit latere revisies (C++11 bracht er veel). Maar je kunt het ook te ver doordraven en er iets onleesbaars van maken. Maar dat is niet gelimiteerd aan C++ maar geld denk ik in elke taal wel.

Ik heb ooit een Coding standaard geschreven voor mijn team programmeurs, om te trachten dit voormekaar te krijgen. Je wilt niet weten hoeveel weerstand dit opgeroepen heeft.
Dat snap ik dan ook wel ;D Ik snap dat het binnen een team/bedrijf het lezen van andermans code makkelijker/sneller maakt maar iedereen ontwikkelt een eigen stijl. En ik wil me daar vooral niet mee bemoeien 8) Zolang een stijl maar consequent is. Want dan is het een tool om makkelijker/sneller/foutlozer code te maken. Inderdaad een compititie Obfuscated C  ;D

Van GCC mag het wel. Van mijn C-compiler mag het niet  :-\
Ahh, vandaar! Wat als je er expliciet constexpr van maakt?

En waarom vind je een switch case 'zwak' in C++.
Omdat het eigenlijk maar op een stel conditional goto's uit komt. Zeker met de beperking dat het alleen met een integer type werkt en dat de cases constexpr maakt dat er wat "onverwachte" beperkingen aan zitten. Nu moet ik zeggen dat ik het gelinkte alternatief ook ruk vind ;D Dan laat je het op runtime aankomen. Om over de syntax inderdaad nog maar te zwijgen. ::)

C. Je programma niet onnodig groot wordt qua geheugen gebruik.
Eens! Maar key word is wel "onnodig". Naar mijn idee mag een kleine overhead wel om het schrijven (enorm) te versnellen. Een Arduino voorbeeld: digitalWrite(). Naar mijn idee een mooie oplossing met beperkte overhead. Helaas komen de String-class (te veel operator overloading in combinatie met malloc's) en float's (om maar een decimale punt te hebben ::)) bij beginners snel om de hoek kijken. Voor beide helaas nog geen alternatief tegen gekomen (en niet de moeite genomen het te schrijven :angel:) maar zou OO prima kunnen. Bijvoorbeeld, als de String-class fixed-size zou zijn ipv dynamisch dan zou dat veel meer geheugen bewustzijn kweken.

Dan waarom een trap van sluit accolades maken?
Om te "forceren" (lees: makkelijk kunnen controleren) dat ik genoeg sluit-accolades plaats om niet per ongeluk de boel verkeerd te groeperen.
if(x < 5) {
    if(y > 6) {
        doeIets();
        if(z == 7) {
            doeIetsAnders(); }
    helloWorld(); } }
Zal prima compilen maar doet wat anders dan de indentatie doet vermoeden. Ik zou dan wel een nieuwe kop koffie nodig hebben om de bug te vinden ;D De discussie of code accolades of indentatie voor groepering zou moeten gebruiken is dan weer een andere. Zou het te maken hebben met het verschil in regeleinde tussen verschillende OS'en? Of het feit dat je eventueel code kleiner zou kunnen maken door leading non-printable characters weg kan laten? Voor de leesbaarheid snap ik de indentatie in ieder geval zeker!

Yep, het blijft verwonderlijk dat zoiets simpels als een indentatie stijl zoveel weerstand kan oproepen.
Daarom zeur ik dan ook niet al te vaak over stijl*. Zoals gezegd, consequente stijl is belangrijker. Maar dan kan wel voor "irritaties"zorgen als er meerdere mensen aan moeten werken ;D Indent met tab of spaties? 2 of 4 spaties? "){" of ") {". else achter een }? Commentaar uitlijnen? Commentaar ervoor of erachter? Geef je invulling in commentaar? camelCase? UpperCamelCase? Snake case? Kebab case?

Maar nee, ik ben hier niet om een stijl oorlog te starten of iemand te overtuigen :angel: Goed, ik ga het CAN verhaal verhaal weer volgen. (y) Weer even genoeg BBCode geschreven 8)


Timo

* Ook al zou ik gek worden code zonder indentatie en ben ik wel van de "noting follows a ;" :angel:
Verzonden vanaf mijn desktop met Firefox

meino

  • Offline Offline
  • Berichten: 573
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #42 Gepost op: 17 november 2019, 15:16:02 »
Ik kan het niet laten, maar een klein voorbeeldje, een winnaar uit de 2019 Obfuscated C Contest.

#include <stdio.h>
#define  f(f,g){z e=0;for(;e<f;e++)g;}
#define  i(f,g)static z f(z a){return g;}
#define  j(f,g)static void f(z*a,z*b,z*c){g}
#define  h(f,g)static z f(z a,z b,z c){return g;}
#define  g(f,g,h,i,j)static z f(z b){z a=g,c=h;for(;i)a=j;return a;}
typedef unsigned char y;typedef unsigned long long z;extern y*w;static z b(z a,z b){return a>>b|a<<(64-b);}i(_,
(a>>6)^b(a,61)^b(a,19))i(_a,b(a,39)^b(a,28)^b(a,34))h(x,((a^b)&c)^(a&b))i(u,b(a,41)^b(a,18)^b(a,14))h(t,(((((3*(a*c+b*b)>>9)+(3*
b*c>>32))*a>>21)+(3*a*a*b>>6)+((b>>4)*(b>>4)*b>>46))>>18)+a*a*a)h(m,t((b<<16)|(c>>48),(c>>24)%(1<<24),c%(1<<24))>>48<a)h(s,(a&b)
^(~a&c))i(r,b(a,1)^b(a,8)^(a>>7))g(o,0,0,c<8;c++,a*256+w[b*8+c])g(d,0,0,c<13;c++,a*31+w[b*13+c]-96)g(p,0,4,c;c/=2,a|c*m(b,a|c,a)
)g(q,0,1ull<<63,c;c/=2,a|c*m(b,p(b),a|c))g(v,b>1,2,c<b;c++,a&&b%c)g(l,b?l(b-1)+1:2,a,!v(c);c++,c+1)j(n,z d=a[7]+u(a[4])+s(a[4],a
[5],a[6])+q(l(*b))+c[*b%16];f(8,a[7-e]=e-3?e-7?a[6-e]:d+_a(a[0])+x(a[1],a[2],a[3]):d+a[3])f(16*(*b%16>14),c[e]+=c[(e+9)%16]+r(c[
(e+1)%16])+_(c[(e+14)%16])))j(k,f(8,b[e]=a[e])f(80,n(a,&e,c))f(8,a[e]+=b[e]))int main(){z a[8],b[8],c[16];f(8,a[e]=d(e))f(16,c[e
]=e-15?o(e):d(8))k(a,b,c);f(16,c[e]=e?e-15?0:11264:1ull<<63)k(a,b,c);f(8,printf("%016llx%s",a[e],e-7?"":"\n"))return!w;}y*w=(y*)
"crsmyiajqhwy{unwa|hjoi`hlxhpxrzb~edko~rtr~ileqyjk`znqgsuitvgqnfdfa||wedvnmhozkpokootqzcexeld~oibqzpcsuw{ib{x`m`hsa`jmn}wcfzpb";

Het genereert eem SHA-512 hash van zich zelf.

groet Meino
A clean desk is a sign of an empty mind

Kranenberg

Timo

  • Team encyclopedie
  • Offline Offline
  • Berichten: 4539
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #43 Gepost op: 17 november 2019, 20:12:05 »
Zo, daar heb je wel even een avond voor nodig om te verteren  ;D


Timo
Verzonden vanaf mijn desktop met Firefox

meino

  • Offline Offline
  • Berichten: 573
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #44 Gepost op: 17 november 2019, 20:29:11 »
Dat probeer ik niet eens. Ik heb helaas niet meer een FreeBSD of Solaris bak om het te compileren en te proberen.

Groet Meino
A clean desk is a sign of an empty mind

Kranenberg