Doel:€250.00
Donaties:€50.00

Per saldo:€-200.00

Steun ons nu!

Laatst bijgewerkt
op 03-01-2024

Vacature: secretaris bestuur
Algemeen

De stichting

Recente berichten

Perronhoogte TP3 door Pauldg
Vandaag om 10:59:34
01TREFF 2024, 26&27 OKTOBER door Pauldg
Vandaag om 10:50:12
Handmatige bediening van wissels d.m.v. stangen door MartinRT
Vandaag om 10:47:54
Mijn eerste H0-modeltreinbaan in aanbouw door Hans GJ
Vandaag om 10:47:11
zelfbouw diesel vijf (DE-5) door FritsT
Vandaag om 10:22:10
De Hondsrugbaan door Kees (NS Blokpost 21 Klein Bruntendijk, Friesland)
Vandaag om 10:22:09
Verschil leveranciers DCC decoders? door spoorijzer
Vandaag om 10:19:50
Kranenberg, een exercitie in code 70 door meino
Vandaag om 10:18:27
US diorama in H0 door ES44C4
Vandaag om 10:09:14
Zee. Land. door AB 7216
Vandaag om 10:05:01
Schneidersein door W.Broere
Vandaag om 10:04:53
On traXS 15 t/m 17 maart Spoorwegmuseum Utrecht door MOVisser
Vandaag om 09:56:58
Bahnstrecke 5867 door Frank 123
Vandaag om 09:52:10
De bouw van mijn modelbaan in Thailand door Wim Vink
Vandaag om 09:36:22
Foto's gevraagd Den Haag CS, oude toestand door Pauldg
Vandaag om 09:22:33
Vraag over 20 voets container met vlakke zijwanden door henk
Vandaag om 09:02:16
Modelbaan Beltheim. door Hans GJ
Vandaag om 08:39:25
De spoorhaven van Zuidbarge. door mass am see
Vandaag om 08:25:21
BR 44 1263 UK Mit Borsig versuchs Wannentender 2'2'T 34. door Basilicum
Vandaag om 08:12:20
Mijn Ned. N. Spoorbaan ''Echthoven'' door NS264
Vandaag om 07:49:38
Geluid NS Mat'46 vs NS Mat'54 door Thom
Vandaag om 02:40:57
Mallnitzer Tauernbahnstrecke ÖBB N Spoor door Schachbrett
Vandaag om 00:54:59
Bouw Bührtal III door Schachbrett
Vandaag om 00:36:33
NS/32 door RK
18 maart 2024, 23:49:38
Ijzeren Rijn: militair transport door ijzeren rijn
18 maart 2024, 23:03:28
EifelBurgenBahn door Reinout van Rees
18 maart 2024, 22:07:31
Loconet over TCP/IP door bask185
18 maart 2024, 22:00:49
bezetmelder aantal lengte en treinstellen door Bobos
18 maart 2024, 21:36:41
Les Billards du Vivarais door Hans1963
18 maart 2024, 21:36:19
Am Ende der Strecke, modulebaan op 1 M2 door Frank 123
18 maart 2024, 21:34:50
  

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

Klaas Zondervan

  • Offline Offline
  • Berichten: 25135
    • 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.

Hennik

  • Offline Offline
  • Berichten: 155
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.

meino

  • Offline Offline
  • Berichten: 2086
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #32 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
De CanBus komt naar Kranenberg

ikbenerevenniet

  • Offline Offline
  • Berichten: 379
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #33 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

  • Online Online
  • Berichten: 3976
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #34 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 »
Train-Science.com
Train-Science github
It ain't rocket science ;-)

Te 2/2

  • Offline Offline
  • Berichten: 969
  • Metrop-Märklin
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #35 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

  • Online Online
  • Berichten: 3976
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #36 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".
Train-Science.com
Train-Science github
It ain't rocket science ;-)

meino

  • Offline Offline
  • Berichten: 2086
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #37 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 lul, 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
De CanBus komt naar Kranenberg

bask185

  • Online Online
  • Berichten: 3976
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #38 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.
Train-Science.com
Train-Science github
It ain't rocket science ;-)

meino

  • Offline Offline
  • Berichten: 2086
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #39 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
De CanBus komt naar Kranenberg

Timo

  • Team encyclopedie
  • Offline Offline
  • Berichten: 4656
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #40 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: 2086
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #41 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
De CanBus komt naar Kranenberg

Timo

  • Team encyclopedie
  • Offline Offline
  • Berichten: 4656
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #42 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: 2086
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #43 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
De CanBus komt naar Kranenberg

Robert E

  • Offline Offline
  • Berichten: 909
    • Robert’s Modelspoor Pagina
Re: De CanBus komt naar Kranenberg, Arduino's en de CanBus
« Reactie #44 Gepost op: 17 november 2019, 21:11:52 »
Citaat
Maar dan kan wel voor "irritaties"zorgen als er meerdere mensen aan moeten werken

Ident tool gebruiken....


Citaat
2 of 4 spaties?

Spaties, die ellende als je file eens opent op andere machine die toevallig niet de juiste IDE heeft en file opent in kladblok / Notepad++

Trouwens, als C "man" is die hele OO ook een overgang ondanks dat ik OO achtig programmeer in C....
Al helemaal de struggle / overgang naar C# die ik moet en wil maken  :)
Naja, uitdaging :)

Mvg

Robert
MDRRC-II (Lite) goedkope DIY centrale voor DCC en MM.
Heb je een vraag, stuur me dan een mail via mijn site ipv persoonlijk bericht...