Nog meer ontwerptips en domme fouten

De volgende tip is dan ook: Gebruik geen C.

Het lijkt of C programmeurs het expres onleesbaar willen maken, tot brainfuck constructies toe.

en ik dacht dat ik C enigszins begon te snappen... Ik zie nog net dat het een functie is, dat er iets met pointers gedaan wordt en dat er een increment in een while lus zit (die iets vergelijkt en het resultaat ook nog 's AND), verder dat er iets met letters / chars gedaan wordt...

Misschien een pointer naar een char als eerste letter in een string?

Hmmz, misschien toch nog maar ff wachten met C voor AVR te gaan gebruiken... 't komt vanzelf met school trouwens. Eerst asembly

Zwaar OT natuurlijk. Misschien zou CO toch iets van een huiskamerbijkletstopic moeten hebben... Iets gelimiteerd op 10 pagina's wat gewoon de prullenbak in gaat elke 10 pagina's. Slow chat alsnog niet toegestaan (daar is IRC voor), zodat er gewoon 3 dagen tot een week inpassen, daarna is wat erin staat toch niet meer zo relevant. 't is maar een lomp ideetje (iedereen weer blij dat ik géén mod ben).

Op 6 september 2010 19:02:05 schreef Henry S.:
De volgende tip is dan ook: Gebruik geen C.

Het lijkt of C programmeurs het expres onleesbaar willen maken, tot brainfuck constructies toe.

Ik gebruik het wel (af en toe) maar ik ben al heeeeeel lang geleden opgehouden met de, voornamelijk ongedocumenteerde, code van anderen te proberen te doorgronden. Voornamelijk wegens de neiging code zo compact mogelijk te maken.
"Echte" C-programmeurs die mijn C-code zien zeggen dan wel altijd: "volgens mij ben jij een Pascal programmeur". Hetgeen geheel klopt en door mij als een groot compliment wordt beschouwd .
Ik had ooit een discussie met een C/C++-programmeur die mij wou overtuigen van de voordelen van C++. Daar zaten namelijk type-controles op pointers in. Ik heb hem, voorzichtig, uitgelegd dat dit in Pascal al vanaf het begin zo was...Duh...

Of, om het als een ontwerptip te verpakken: zorg dat je goed C leert. Voor elk fatsoenlijk platform is een C compiler beschikbaar, C biedt in mijn ogen voor microcontrollers een goede balans tussen dicht bij de hardware zitten en op een comfortabele manier code schrijven. Een strcmp is helemaal geen lastige functie, als je tenminste het pointer-concept doorhebt.

int strcmp (char *a, char *b)
{
  while (*a && (*a == *b)) {
      a++; b++;
  }
  return *a - *b;
}

strcmp is een functie die een (signed) integer teruggeeft; hij heeft twee parameters; allebei een pointer naar een char (en impliciet de karakters die op de daaropvolgende plekken in het geheugen staan tot het einde van de string, dat aangegeven wordt met een char met de waarde 0).
Vervolgens wordt gekeken of de waarde die op de locatie staat die pointer a aanwijst true is (ongelijk aan nul, dus nog niet het einde van de string) en de waarden die aangewezen worden door a en b gelijk zijn. Als dat zo is dan worden de pointers a en b opgehoogd zodat ze naar de volgende letter in de string wijzen en begint het verhaaltje weer opnieuw.

Als de string afgelopen is of de strings zijn niet meer gelijk aan elkaar dan houdt het op en wordt het verschil tussen de twee tekens die als eerste verschillend zijn, en daarmee dus of de ene string 'groter' of 'kleiner' is dan de andere.

Bonusvraag: waarom is de voorwaarde in de while lus niet (*a && *b && (*a == *b)) ?

Bonusvraag: waarom is de voorwaarde in de while lus niet (*a && *b && (*a == *b)) ?

Omdat die conditie al in *a == *b wordt afgevangen.
Als *b gelijk is aan \0 dan wordt ook niet meer aan de conditie voldaan. En, indien *a gelijk is aan \0 dan zouden er een paar dingen kunnen gebeuren: *b is ook gelijk aan \0, resultaat: 0, of *b is ongelijk aan \0, met resultaat ongelijk aan 0.
C, Wat een heerlijke taal, ik mis het echt, jaren in geprogrammeerd maar tegenwoordig moet ik het doen met C#.

Nog een klein opmerkinkje tussendoor, je zou je while lus nog korter kunnen schrijven door het ophogen van a en b op te nemen in de vergelijking .

[Bericht gewijzigd door mbbneon op maandag 6 september 2010 20:04:02 (13%)

Wat een bullshit, die code is perfect leesbaar. Meer dan 5 seconden had ik er niet voor nodig om te snappen wat daar gebeurd.

Ik zie het hele probleem ook niet; 0 is false, ongelijk 0 is true. Alle "programmeurs" die dat niet kunnen bevatten (kom op zeg, zo moeilijk is het echt niet), moeten maar gewoon bij andere talen blijven.

@mbbneon: nee, want dan werkt het (volgens mij) niet meer als het eerste of het laatste teken verschilt, als je resp. *(++a) of *(a++) doet.

Overigens zou een beetje commentaar en fatsoenlijk variabele namen natuurlijk geen kwaad kunnen.

Ik ben het helemaal met Springuin eens; C heeft zeker nog een plaats in low-level (OS kernels en zo) en embedded systems engineering. Als je nog hele gebruikersapplicaties maakt in C ben je naar mijn idee bijna altijd verkeerd bezig; daarvoor zijn er intussen programmeertalen / omgevingen die daar veel beter geschikt voor zijn.

Maar ja, ik ben natuurlijk niet objectief, want als embedded systems engineer zit ik altijd in C code of zelfs nog in DSP ASM te rommelen.

Ach, met de (prachtige) uitleg van Springuin kan ik het ook nog volgen, en ik vind mezelf geen C programmeur... (Nog niet... Wel C beginner. Eenvoudige programmatjes schrijven met het boek als naslag erbij lukt prima. Als ik het vaker doe komt dat wel goed.)

Verpakt als ontwerptip: comment & document je code!

Henry, kathode en gloei hadden een gezamelijke massa. Dat is nu gescheiden.

Ik zag nooit zo het nut van stroombegrenzing, ja, ja, ik weet het, ik was nog jong en onwetend , Nu weet ik beter, mijn labvoeding heeft er wel een.
Ik heb op dat "beest" een begrenzing in de vorm van een inschakelbare gloeilamp tussen scheidingstrafo en variac. De hoogspanningstrafo zit weer achter de variac. Ik heb gedacht aan een echte instelbare stroombegrenzing maar geen idee hoe gezien de stroom en spanning. Een FET als shunt naar een heel heftige dummyload ? Er zit wel een stroommeter tussen massa en min maar als je niet oplet is het te laat. Maar vooral voor mijn eigen veiligheid zou ik het wel willen. zweetvoetje heeft ooit een keer de 500V per ongeluk aangeraakt. Met een hand, en hij zat een kwartier later nog wat witjes te kijken.

Ik zie het hele probleem ook niet; 0 is false, ongelijk 0 is true. Alle "programmeurs" die dat niet kunnen bevatten (kom op zeg, zo moeilijk is het echt niet), moeten maar gewoon bij andere talen blijven.

De angel is er uit (altijd handig om de definitie goed te kennen, immers zou je de fout in kunnen gaan als je je niet meer herinnert wat een andere waarde dan 0 of 1 eigenlijk doet), maar je ziet het probleem dat ik zie nog immer over het hoofd... Eigenlijk heb je daarmee ook wel gelijk; het probleem is puur theoretisch omdat eigenlijk alle C-compilers de standaard opvatten zoals jij hem nu beschrijft (althans dat mag ik hopen, ik ken ze natuurlijk niet allemaal).

Alsnog zou ik het netter vinden als er gewoon een boolean type standaard in C zou zitten om elke interpretatievrijheid definitief weg te nemen, maar dat is meer een discussie voor een college compilerbouw dan voor het dagelijkse programmeerwerk.

[Bericht gewijzigd door maartenbakker op maandag 6 september 2010 21:04:10 (19%)

Op 6 september 2010 20:04:38 schreef SparkyGSX:
Maar ja, ik ben natuurlijk niet objectief, want als embedded systems engineer zit ik altijd in C code [..] te rommelen.

Pun intended?

Op 6 september 2010 20:14:51 schreef fred101:
zweetvoetje heeft ooit een keer de 500V per ongeluk aangeraakt. Met een hand, en hij zat een kwartier later nog wat witjes te kijken.

Ach, sommige types zijn nu eenmaal overgevoelig...

Een stroombegrenzing voor die helse machine van je is idd. iets moeilijker te bouwen dan voor een laagspanningsvoeding, maar onmogelijk is het niet als je tevreden bent met een stroombegrenzing die niet zozeer de stroom beperkt, maar zonder pardon het ganse systeem plat legt als het de spuigaten uitloopt. Dat lijkt me niet zo'n slechte aanpak.

Vervang de lamp door een shunt (of gebruik de lamp als shunt), en bouw een schakeling die de spanning over de shunt meet (na gelijkrichting). De schakeling moet dan wel zweven tov. de voeding. Ze kan bv. een relais met een NC-contact activeren, en dat zo houden tot je de boel met de hand reset.

fred, als het een buizenvoeding is, ka je eventueel zorgen dat de roosterspanning van de doorlaatbuizen in één ruk negatief is.
En wat dacht je van een thyratron als crowbar over de uitgang? dan gaat je zekering er gehaaid aan.

Nee, is gewoon een ongestabiliseerde voeding. Paar dikke diodes, ratel C's, dikke condensators maat verfblik en een variac als voltregeling. Ik zal wel eens een keer iets bedenken. Ik heb wel een aantal boeken over voedingen maar eerst mijn HP8601 weer tot leven brengen. Ben de 6,3V weer eens kwijt. Eerst maar eens de elco's testen.

Op 6 september 2010 23:37:30 schreef fred101: Ben de 6,3V weer eens kwijt. Eerst maar eens de elco's testen.

Als je de draad maar niet kwijt bent

P.S.
Ik zoek iets leuks om meet die vriac van mij te doen.
Moet nog een leuke behuizing vinden en wil er een 24V 5A trafo bijzetten plus de nodige meters.
Zoek ook nog een dikke knop voor die variac, Liefst zo'n Philips uit de vijftiger jaren met spantangbevestiging.
Nog andere ideën?

[Bericht gewijzigd door Tidak Ada op dinsdag 7 september 2010 00:05:59 (42%)

Vandaag weer een paar draadjes aan nixiebuizen zitten bevestigen voor mijn nieuwe nixie klok. Heel saai en vervelend werkje totdat ik me besefte dat niet alle digits aangesloten hoeven te worden... De klok kan immers maximaal 23:59 aangeven, of numeriek maximaal 2959, scheelt weer een paar draadjes. (7 draadjes op 1e digit, 4 draadjes op 3e)

Hint: Overweeg om 8 draadjes van de eerste weg te laten.....

8 draadjes? Bedoel je de 0? Ik kan in code kiezen of ik al dan geen voorloop nul wil hebben. En bij stroomuitval wilde ik wel 00:00 op het display hebben. Dat draadje zit er toch al (eigenlijk de draadjes voor 0,1,2,3 en 4). Ik ga ze er niet meer afhalen.

Tijdens het testen krijg ik steeds een combinatie van 1 en 5. Grrr, ik de header van de print gehaald, zat er een soldeer kortsluiting tussen twee pinnen. Netjes nieuwe op gezet, weer hetzelfde probleem. Blijkbaar zit er ook een sluiting in het IC voetje. Morgen weer een dag.

De domme fout in dit geval is: controleer gerecyclede onderdelen op sluiting, anders zit je er later mee te klooien.

Morgen weer een dag.

Goede aanpak! Hetgeen 's avonds een onontwarbaar probleem lijkt, blijkt de volgende ochtend niet zelden een niemandalletje te zijn.

Op 6 september 2010 18:36:38 schreef hadv:
[...]
Weet ik meteen weer waarom ik zo'n pokke hekel aan C heb. Onleesbaar.

Probeer eens haskell. Da's pas onleesbaar; is geen code meer, maar lijkt meer op een wiskundig bewijs wat je toevallig ook nog kunt uitvoeren (als bijzaak).

python (en recente javascript) heeft ook leuke dingen als list comprehensions.

a=[1,2,3,4,5]
c=[b*b for b in a]

doet hetzelfde als

int a[6];
int c[6];
for (i=0; i<5; i++) a[ i]=i;
for (i=0; i<5; i++) c[ i]=a[ i]*a[ i];

waarbij ik de bounds-checking weg heb gelaten in C.

net niet wounded in action... 24 volt ac op je tong prikkelt best.

weerstand in een circuit gevoed door 24vac lijkt wat warm te worden, maar niet heel erg...mhm zou ik warme handen hebben? even voelen met de tong..bzzzt

meestal kom ik niet hoger als 5 volt....dus

Op 9 september 2010 22:30:53 schreef alex278:
[...]
Probeer eens haskell. Da's pas onleesbaar

Er is volgens mij maar 1 letterlijk onleesbare taal:           

brainfuck

[Bericht gewijzigd door Henry S. op vrijdag 10 september 2010 17:33:56 (73%)

Post dan ook meteen een programmatje... Hello world in "brainfuck":

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++
++..+++.>++.<+++++++++++++++.>.+++.------.--------.>+.>.

@Jan klaasen: likken aan een schakeling die onder spanning staat? Dat is toch wel een beetje solliciteren naar een Darwin Award!

Er zijn tegenwoordig van die contactloze thermometers te koop voor een paar euro, ze zijn niet erg nauwkeurig, maar ze geven je een redelijke indicatie. Als je er gewoon met je vingers aan voelt; 40 graden voelt als flink warm, bij 55 graden kun je het niet meer dan een paar seconden aanraken.

@REW: tja, brainfuck. Daar heb ik in een grijs verleden wel eens mee gespeeld, en een uitgebreidere interpreter voor geschreven. Als ik me goed herinner, is brainfuck standaard niet turing complete.

De temperatuur van weerstanden voelen met je tong lijkt me sowieso niet al te tof. Vinger d'r boven of er op is 't maximale wat ik doe (en zelfs daar moet je mee uitkijken, want bij dingen zoals een 7915 of een tor waarbij de collector aan de koelplaat hangt kun je aardig grote spanningsvoerende delen hebben waar je maar meter niet tegenaan komt.)