C
Curt Wuollet
Andrew Kohlsmith wrote:
> > moment. And using an array with a write that checks for length, while
> > possibly not as space efficient as a struct, (although you'ld have to look
> > at the machine code generated to be sure), let's you do things like printf
> > and use the string functions avoiding overt pointer manipulation. After
>
> You most certainly cannot use the string functions with arrays containing
> ModBUS data. All string functions stop at a NULL and that NULL is way too
> common in ModBUS packet data.
Agreed, the code I sent deals with ascii.
> I'm a big proponent of KISS -- the stupider your software, the less chance
> it has of biting you in the ass. But as Einstein said, "Things should be
> made as simple as possible -- but no simpler." Using string functions for
> binary data is breaking this rule.
Also agreed.
> > many years, I have found few instances where absolutely obvious code
> > is improved by obfustication. Also Modbus packets are variable length
> > and the simple code is reusable anyplace you have a file pointer. To do
> > Modbus/TCP you just open a socket and build your packet a little
> > differently. And yes, there probably should be a few (unsigned char) in
> > there but it's readable and it works. I compiled and ran it before I sent
> it.
>
> I agree with you that things should be simple (see above) -- At the same
> time though I must speak out when you claim that using structs and/or unions
> over array data is too complex. I can read all the data into a struct with
> a simple file pointer, just as you can. However my data is now structured;
> I can pull out the address or checksum or specific structured elements
> without resorting to pointer arithmetic or clunky #DEFINEs. Avoiding arrays
> because of possible padding issues is silly. Everyone was a newbie at one
> time; how do you learn?
I agree here too.. But, whose code is easier for a BASIC programmer to understand. And unions over array data, which declaring a struct on top of it would be, are much less than obvious. Everyone understands arrays and array ops. Of course it is
pointers under the covers and I often use both for convenience. The machine code generated is
probably identical. But the array ops are much more readable and understandable for someone coming from BASIC. For code that is to be shared, I try to make it obvious and I'm sufficiently secure that I don't mind being picked apart. I could rewrite the whole thing with pointers and even hex or binary constants to replace the silly defines in the header files but, I wouldn't be doing the person I wrote it for any favor. The reason I sent that particular hack is that I wrote it to show another programmer how to use the Matrix Orbital display and keypad. I am not a CS type, I write bonehead C because I have a lot of it around that I very infrequently look at and it helps me to be
able to jump back in quickly and easily. When I move on, it will help the poor soul who has to understand it immeasurably. Ten years ago, I used to write very terse code to fit in very small places with chunks of assembler to overcome speed issues. That is no longer necessary or in my view advisable unless profiling has shown a problem. I'm better now and have nothing to prove by outguessing the optimizer.
There is a larger issue here, we are writing code that is supposed to be useful to as many people as possible. If we want people to participate, the threshold should be as low as possible without sacrificing function. I find the code in the archive to be pretty tough sledding. I guess that makes me an idiot, but I have much more C
and Linux experience than the great majority of our target audience, the people we want to be able to use, study, and contribute to the code base. I doubt that too many people will want to dig into the core functionality we have so far but, as we move outward towards the user we have to make things a little more accessable or
having open source is of little consequence.
Regards
cww
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> > moment. And using an array with a write that checks for length, while
> > possibly not as space efficient as a struct, (although you'ld have to look
> > at the machine code generated to be sure), let's you do things like printf
> > and use the string functions avoiding overt pointer manipulation. After
>
> You most certainly cannot use the string functions with arrays containing
> ModBUS data. All string functions stop at a NULL and that NULL is way too
> common in ModBUS packet data.
Agreed, the code I sent deals with ascii.
> I'm a big proponent of KISS -- the stupider your software, the less chance
> it has of biting you in the ass. But as Einstein said, "Things should be
> made as simple as possible -- but no simpler." Using string functions for
> binary data is breaking this rule.
Also agreed.
> > many years, I have found few instances where absolutely obvious code
> > is improved by obfustication. Also Modbus packets are variable length
> > and the simple code is reusable anyplace you have a file pointer. To do
> > Modbus/TCP you just open a socket and build your packet a little
> > differently. And yes, there probably should be a few (unsigned char) in
> > there but it's readable and it works. I compiled and ran it before I sent
> it.
>
> I agree with you that things should be simple (see above) -- At the same
> time though I must speak out when you claim that using structs and/or unions
> over array data is too complex. I can read all the data into a struct with
> a simple file pointer, just as you can. However my data is now structured;
> I can pull out the address or checksum or specific structured elements
> without resorting to pointer arithmetic or clunky #DEFINEs. Avoiding arrays
> because of possible padding issues is silly. Everyone was a newbie at one
> time; how do you learn?
I agree here too.. But, whose code is easier for a BASIC programmer to understand. And unions over array data, which declaring a struct on top of it would be, are much less than obvious. Everyone understands arrays and array ops. Of course it is
pointers under the covers and I often use both for convenience. The machine code generated is
probably identical. But the array ops are much more readable and understandable for someone coming from BASIC. For code that is to be shared, I try to make it obvious and I'm sufficiently secure that I don't mind being picked apart. I could rewrite the whole thing with pointers and even hex or binary constants to replace the silly defines in the header files but, I wouldn't be doing the person I wrote it for any favor. The reason I sent that particular hack is that I wrote it to show another programmer how to use the Matrix Orbital display and keypad. I am not a CS type, I write bonehead C because I have a lot of it around that I very infrequently look at and it helps me to be
able to jump back in quickly and easily. When I move on, it will help the poor soul who has to understand it immeasurably. Ten years ago, I used to write very terse code to fit in very small places with chunks of assembler to overcome speed issues. That is no longer necessary or in my view advisable unless profiling has shown a problem. I'm better now and have nothing to prove by outguessing the optimizer.
There is a larger issue here, we are writing code that is supposed to be useful to as many people as possible. If we want people to participate, the threshold should be as low as possible without sacrificing function. I find the code in the archive to be pretty tough sledding. I guess that makes me an idiot, but I have much more C
and Linux experience than the great majority of our target audience, the people we want to be able to use, study, and contribute to the code base. I doubt that too many people will want to dig into the core functionality we have so far but, as we move outward towards the user we have to make things a little more accessable or
having open source is of little consequence.
Regards
cww
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc