EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: DJPhil on April 22, 2010, 12:39:52 am
-
I'm sure some of you have heard of the webcomic XKCD. Today's was a good one for electronics, and I thought you guys might enjoy it.
http://www.xkcd.com/730/# (http://www.xkcd.com/730/#)
I think my favorite bit was the arena. :)
-
I was going to make it but my local supplier is all out of flux capacitors >:(
-
That would make a nice t-shirt!
-
(http://imgs.xkcd.com/comics/snakes.png)
That's a good one. ^-^
-
hit random a few times and came across this... would been handy in that thread we had about using goto :)
(http://imgs.xkcd.com/comics/goto.png)
-
I don't understand the fuss about the usage of 'goto'.
even the most 'properly' constructed code will compile down to using JMP instructions. which is nothing more than a goto.
-
Not necessarily true -- although I don't know of any languages which compile semantic constructs into e.g. function calls. That is, putting the inner braces of each execution path into their own functions. And by function, I mean, using CALLs instead of JMPs.
But the higher level semantics are much more valuable than the machine code that implements it, at least for average development. In this post-computational-abundance world, the programmers' bandwidth is the limiting factor. (Well, almost. One would hope. Of course, more computing power always means bigger and slower high level libraries, or scripting languages. So...)
And, that said, I would enjoy if assembler were designed with indentation in mind. Many (older?) assemblers won't even accept it -- they expect strict whitespacing. That makes it very hard to read and write structured code. Usually, big comment blocks are used.
Tim
-
goto xkcd (https://www.eevblog.com/forum/chat/xkcd-was-interesting-today/msg801557/#msg801557)
-
(http://imgs.xkcd.com/comics/snakes.png)
If you hover over the image on the website it says:
"The last band of color indicates the snake's tolerance for being held before biting." ;D
-
Yesterday's strip was good, and (somewhat) electronics related:
(http://imgs.xkcd.com/comics/flashlights.png)
The most powerful hand-held torch (flashlight) I could find is the X-LED XHP DualBeam, which the manufacturers reckon is 50,000 lumens.
They are apparently working on a 1 million lumen LED light, but since this will consume 5 kW you probably won't be able to slip it in your pocket.
-
I'm sure some of you have heard of the webcomic XKCD. Today's was a good one for electronics, and I thought you guys might enjoy it.
http://www.xkcd.com/730/# (http://www.xkcd.com/730/#)
I think my favorite bit was the arena. :)
Been around for a long time but still funny as hell. :D
-
The most powerful hand-held torch (flashlight) I could find is the X-LED XHP DualBeam, which the manufacturers reckon is 50,000 lumens.
They are apparently working on a 1 million lumen LED light, but since this will consume 5 kW you probably won't be able to slip it in your pocket.
Well, put two 28 V power tool batteries in series and that will give you 56 V. Such batteries can comfortably supply 100 A, so there's 5 kW. More lantern sized than pocket sized perhaps, and it won't run for very long, but it would be cool on a dark night.
-
Well, put two 28 V power tool batteries in series and that will give you 56 V. Such batteries can comfortably supply 100 A, so there's 5 kW. More lantern sized than pocket sized perhaps, and it won't run for very long, but it would be cool on a dark night.
A quick google told me that the Makita 28V battery is 3.0Ah. So, we are talking less than 2 minutes at 100 Amp. I am guessing these things aren't designed for continuous operation at 100A. So, hopefully they won't last long enough to heat up to thermal runaway...
But, at least you will be able to see what you are doing while jump starting a big diesel truck: https://www.youtube.com/watch?v=AsTJKSH7mCU (https://www.youtube.com/watch?v=AsTJKSH7mCU)
-
I don't understand the fuss about the usage of 'goto'.
even the most 'properly' constructed code will compile down to using JMP instructions. which is nothing more than a goto.
Because memory leak, and dinosaurs.
BTW if you want bright flashlights, try them with Maxwell supercapacitor banks. 75V 1800A from something that fit into a backpack.
-
(https://imgs.xkcd.com/comics/exploits_of_a_mom.png)
Had this one on the fridge. My son was fascinated by it even though he was young and didn't know what SQL was.
https://xkcd.com/1133/ (https://xkcd.com/1133/)
Is currently on the fridge:
-
In addition to the above, I like these ones:
(http://imgs.xkcd.com/comics/hard_reboot.png)
and
(http://imgs.xkcd.com/comics/code_quality.png)
-
goto xkcd (https://www.eevblog.com/forum/chat/xkcd-was-interesting-today/msg801557/#msg801557)
Well played, Sir.
Well played!
-
I don't understand the fuss about the usage of 'goto'.
even the most 'properly' constructed code will compile down to using JMP instructions. which is nothing more than a goto.
Because memory leak, and dinosaurs.
Ironically, I have a soft spot for goto in one particular usecase: preventing memory leaks on error conditions (athough I don't use it in this situation professionally, and I generally abhor goto in every other case). Example:
void main() {
FILE* f1 = fopen( ... );
if (f1 == NULL) {
printf("Failed to open f1\r\n");
return;
}
Object a = makeObject();
if (a == NULL) {
printf("Failed to make a\r\n");
goto finalize_f1;
}
...
if (nasty.error()) {
printf("Ouch\r\n");
goto finalize_a;
}
...
finalize_a:
a.finish();
delete a;
finalize_f1:
fclose(f1);
}
Obviously in this case the Object could have been allocated on the stack; but it's more the problem of issuing cleanup method calls like close() -- which may well delete objects internally. Of course more featured languages have things like the defer block, which is one of many ways to avoid this pattern.
-
Ironically, I have a soft spot for goto in one particular usecase: preventing memory leaks on error conditions (athough I don't use it in this situation professionally, and I generally abhor goto in every other case). Example: ...
In C++ the RAII pattern can be used to good effect where resource cleanup should happen for all exit paths including errors and exceptions.
-
Ironically, I have a soft spot for goto in one particular usecase: preventing memory leaks on error conditions (athough I don't use it in this situation professionally, and I generally abhor goto in every other case). Example: ...
In C++ the RAII pattern can be used to good effect where resource cleanup should happen for all exit paths including errors and exceptions.
Indeed, I really like RAII, although it's not available in pure C of course. I've been meaning for a while to see what the overhead for using C++ on AVR is...
-
I'm just learning C, so don't have a clue, but...
I fully understand that abusing goto can result in awful spaghetti code, but the "thou shalt not us goto under any circumstances" mantra seems almost cult-like!
-
I'm just learning C, so don't have a clue, but...
I fully understand that abusing goto can result in awful spaghetti code, but the "thou shalt not us goto under any circumstances" mantra seems almost cult-like!
C code can be written without using GOTOs.
-
I'm just learning C, so don't have a clue, but...
I fully understand that abusing goto can result in awful spaghetti code, but the "thou shalt not us goto under any circumstances" mantra seems almost cult-like!
You can break the rules once you've mastered them, but not before. It's neither a mantra nor cult-like, it's just something meant to preserve as much global sanity as possible.
-
I'm just learning C, so don't have a clue, but...
I fully understand that abusing goto can result in awful spaghetti code, but the "thou shalt not us goto under any circumstances" mantra seems almost cult-like!
C code can be written without using GOTOs.
I'm sure it can be written without using a lot of things! So surely that's not a reason by default.
I have read a fair bit about this on stackexchange and other sites, and it seems that people will go to (pun not intended, sorry) extreme lengths, writing convoluted code, just to avoid a goto! That's when it seems to me like more dogma than engineering!
-
I'm just learning C, so don't have a clue, but...
I fully understand that abusing goto can result in awful spaghetti code, but the "thou shalt not us goto under any circumstances" mantra seems almost cult-like!
You can break the rules once you've mastered them, but not before. It's neither a mantra nor cult-like, it's just something meant to preserve as much global sanity as possible.
I am looking forward to that day!
-
I have read a fair bit about this on stackexchange and other sites, and it seems that people will go to (pun not intended, sorry) extreme lengths, writing convoluted code, just to avoid a goto! That's when it seems to me like more dogma than engineering!
One of the most important things about good code is that the algorithm and logical flow should be clear to a human reader. Inappropriate use of goto's can go against this, which is why goto's are frowned upon. If an occasional goto is used in a clear and logical way, for example to jump to an error handler, then that should not be seen as a problem.
-
That's my understanding, Ian. But it seems a lot of people think that goto should categorically not be used, at all, ever. That's what seems daft to me.
-
good ... should be clear to a human reader. Inappropriate use of goto's can go against this
I pretty much agree a 'goto' is a special tool for a special case. Could it be that source code has inherently one-dimensional aspects to them (the flow of the program counter / instruction pointer through the code, the way the call stack works), and a goto works against this mind set by allowing unstructured jumps?
I've never seen anybody say that flowcharts are bad, as they allow you to draw arrows across logical boundaries, maybe they need a rule that you should never 'cross the streams'?
Neither in formal state transition diagrams, where you can jump between arbitrary states however you see fit. When you convert a FSM to code you basically end up with spaghetti.
I definitely remember the "no goto" rule being around in the early 80s in the time of structured BASICs, PASCAL and COBOL... Maybe a lot of it is hangover from old languages where your GOTOs used the line number as the target for jump, rather than a label. Those days were really nasty - if you renumbered code you could shoot yourself in the foot sooooo badly. These days the destination for a goto is has limited scope, and so at least it has a bit of structure to it.
One C coding standards I had to follow in the 90s recommended this construct for processing errors:
void some_func(void)
{
do {
if( ! something_that_might_error() ) /* e.g. malloc or fopen() */
break;
if( ! something_else_that_might_error() )
break;
<do the real work>
return 1; /* Success */
} while(0);
<error handling code>
return 0; /* Failure */
}
It was a poor man's way of exception handling, or abusing C to give 'goto' like functionality without actually using the word.
Anyhow - just idle musings rather than me saying anything of any value.
-
I'm sure it can be written without using a lot of things! So surely that's not a reason by default.
I have read a fair bit about this on stackexchange and other sites, and it seems that people will go to (pun not intended, sorry) extreme lengths, writing convoluted code, just to avoid a goto! That's when it seems to me like more dogma than engineering!
Go spend a week debugging/flowcharting an old FORTRAN 77 research code written by a scientist. You'll light your hair on fire and run out of the building screaming before you make much headway, but from then on every time you see or write the words "goto" or "common" in any program in any language, it will give you a mild case of PTSD.
Using one here or there for error handling/cleanup is fine, but it's too easy to fall into their "lazy" trap and start using them WAY too liberally, which ultimately ends up making the code nearly impossible to read or debug. It's best to just avoid them altogether, at least until you have a good grasp of the damage they can cause and know ways you can avoid them while maintaining readability.