Go Down

Topic: Re: How to serial print an array? (Read 2698 times) previous topic - next topic

GoForSmoke

#15
Oct 31, 2018, 10:41 am Last Edit: Nov 03, 2018, 06:18 am by GoForSmoke
You disagree with me? That guy has responded in the same tone to so many people.  I have yet to see him answer a question without insulting the person asking it.  If he has an issue with their question, just don't answer them.
You haven't looked enough, he's answered me without being insulting, but then I'm not a narcissist.
If I couldn't take Paul, a compiler would reduce me to nothing rather quickly.

I just want to be sure, did he insult YOU or are you a Social Justice WARRIOR looking to correct 1st world indignities? Ever read Brave New World?
Have you got the intelligence to see that PaulS does not like time wasting idiots? Obviously not, his view is beyond you.

Anyway, you having to go back so far to drag up your example does put your whinge in perspective.
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

Qdeathstar

Were you on vacation goforsmoke?
A creaking creeping shadow
stiff against the freezing fog
glares at a tickless watch.

Time has failed him -- all things shall pass.

GoForSmoke

1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

ChrisTenone

What, I need to say something else too?

GoForSmoke

#19
Nov 03, 2018, 12:56 am Last Edit: Nov 03, 2018, 12:57 am by GoForSmoke
The smoke to go for is the smoke of hairl;ine traces burning off cheap reject boards back before the PC clone boards arrived.

Go for smoke could be a hobbyist term for theater's "break a leg".

member A : I'm gonna see if that's the power pin.
member B: Go for smoke!
 
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

ChrisTenone

There is also the smoke that should not be let out.

From your style you do not strike me as a tabakee user.
What, I need to say something else too?

NavyVet1959

#21
Dec 07, 2018, 03:35 am Last Edit: Dec 07, 2018, 03:38 am by NavyVet1959
The bouncers here are pretty good and the bar is actually quite tame. The locals tend to sit in corners writing Haikus on beer mats or staring into their glasses and muttering about the weather. One guy keeps going on and on and on about snow, and he flashes a picture of his bird at anybody who will look.

There was a strange shepherd that came in last year, I think he was a German, but for the most part things are quiet. It is true that somebody was recently threated with a pitch forking  for using  'goto', but that was on the main forum, not in the bar.
On a side note, there are times when the use of a goto (properly hidden in a series of macros) can make for more readable code.  It allows you to have a single exit point from a function and that exit point does the cleanup if the return code is non-zero (i.e. a failure).  When I worked for NASA in the early '90s, we would hide the goto in a "RETURN" macro.  A function might look something like this:

Code: [Select]

typedef struct obj {
    int    val;
    char  *str;
} *OBJ;

typedef enum {
    ERR_InvalidArg = -199;
    ERR_NullPointer,
    ERR_MemoryAllocationFailure
} ERROR_CODES;

int  OBJ_Create( OBJ *handlePtr; int val; char *str )
{
    OBJ  handle = NULL;

    BEGIN("OBJ_Create");

    if (handlePtr == NULL)
        RETURN(ERR_InvalidArg);

    if (str == NULL)
        RETURN(ERR_NullPointer);

    handle = calloc(sizeof(struct obj), 1);
    if (handle == NULL)
        RETURN(ERR_MemoryAllocationFailure);

    handle->val = val;

    handle->str = strdup(str);
    if (handle->str == NULL)
        RETURN(ERR_MemoryAllocationFailure);

    *handlePtr = handle;

    RETURN(0);

    ON_EXIT {
        if (retCode != 0) {
            if (handle != NULL) {
                if (handle->str != NULL)
                    free(handle->str);
                free(handle);
            }
        }

        return (retCode);

    }
}


The BEGIN macro declared an int variable "retCode" and a "char *" variable "fnName" that was assigned the string that was the parameter to the macro.  The ON_EXIT macro hid a goto label "ExitFunction", the RETURN macro would set "retCode" and do a goto ExitFunction.  The "fnName" variable was declared so that you could add error messages throughout the code and not have to repeat the literal string, thus saving space and making it easier to change the name of the routine in the future without having to modify a lot of code.

It might not be as obvious that it would be useful in this simple example, but when you have a routine that is a lot longer and would normally have a lot of nested "if" statements or return statements, this can simplify the logic quite a bit.

Robin2

#22
Dec 07, 2018, 09:31 am Last Edit: Dec 07, 2018, 09:33 am by Robin2
On a side note, there are times when the use of a goto (properly hidden in a series of macros)
Where do you get the stuff you are smokin ?  :)  :)

Maybe we need a Wall of Shame for code ?

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

NavyVet1959

#23
Dec 07, 2018, 12:09 pm Last Edit: Dec 07, 2018, 01:40 pm by NavyVet1959
Where do you get the stuff you are smokin ?  :)  :)

Maybe we need a Wall of Shame for code ?

...R
It was a series of macros that we developed back when I was working for NASA in the early '90s.  It acted as an extension to the language.  Because of the machines we were working on, portability, and other constraints, all code needed to be in standard 'C'.  No C++ allowed.  These macros allowed for a single exit point in the code and if used correctly, helped to minimize the chance of memory leaks (i.e. allocating memory in a routine and not cleaning up correctly when you needed to exit.  They acted as an extension to the language.

The macros were defined in a header file (ON_EXIT.h) and included in all source files:

Code: [Select]

#ifndef _ON_EXIT_H_
#define _ON_EXIT_H_

#define BEGIN(x) int retCode; char *fnName = x;
#define RETURN(x) { retCode = x; goto ExitFunction; }
#define ON_EXIT ExitFunction:

#endif


Since we didn't have C++ as an option, but we still wanted some aspects of object-oriented design, what we did was say that every 'object' consists of some sort object identifier (usually 3-5 capital letters) and every 'method' (member function) had that identifier followed by and underscore and then the reset of the member function name.  When you have large teams of developers working on a system and they are often from different groups or even different companies, this helps in keeping things organized.  When you have projects that large, you don't want everyone just doing their own thing -- you need agreed upon standards.  There's a difference between software engineering and just hacking some code together.

Robin2

It was a series of macros that we developed back when I was working for NASA in the early '90s.
I wonder if you have missed the fact that this Bar Sport section is just for foolishness :)

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

NavyVet1959

I wonder if you have missed the fact that this Bar Sport section is just for foolishness :)

...R
I guess we frequent different types of bars... Back when I was at NASA, we would sometimes go to a stripper bar called "Heartbreakers" for lunch -- both the male and female engineers.  Why?  Because they had a really good "free" buffet and there was just a one drink minimum.  So, we would each order a single $5 beer and nurse it while eating boiled shrimp, prime rib, cheesecake, and other such stuff.  The females usually sat with their backs to the dancers and for the most part, even the guys didn't pay any attention to the dancers -- we would be talking about various aspects of the design of the systems we were currently working on.

AWOL

Quote
a single $5 beer
Good to see NASA taking safety seriously.

NavyVet1959

Good to see NASA taking safety seriously.
If a single weak-ass domestic beer affects someone enough that safety would be compromised, then they have no business being allowed out of their "safe space".  They would definitely not survive the long hours that we endured during the lead-up to a launch or a project delivery date.  I lived about 40 miles away and I kept a sleeping bag and pillow in my office so that I could crash out there instead of driving home because our on-site test times were late at night and we still needed to have other meetings the next morning to discuss the results of the tests.  There was a fitness center on base, so we could grab a shower and clean up in the morning.  There was a dry cleaners very close to my office, so I kept a couple of sets of clothes there.  Despite those long hours and hard times, it's an experience that I will always look back fondly at.  We had a good group of engineers on our team and everyone pulled their own weight.  We've all retired or moved on to other DoD or aerospace contractors around the country since that time, but we still keep in touch.

AWOL

#28
Dec 07, 2018, 01:49 pm Last Edit: Dec 07, 2018, 02:08 pm by AWOL
One of yours?

A friend of mine was a contractor on a PA system for a large metro railway project.
As such, he was subject to railway health and safety legislation, with very strict rules on both alcohol and working hours.
No lunch-time drinks and no stupid all-nighters.


Robin2

even the guys didn't pay any attention to the dancers
I was at one of those in Houston a long time ago. I can understand :)

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Go Up