[A89] grrr lets flame eachother
[Prev][Next][Index][Thread]
[A89] grrr lets flame eachother
So much argument for such an innocent question :p
Does anybody why some posts wouldn't get through to my inbox? The only thing
I can think of is jumkmail filters, but why some emails from
lists.ticalc.org would get through and others wouldn't is a mystery.
I have seen replies to messages that I never got. I checked my deleted
messages and they aren't there either. It baffles me.
>From: Mike McElroy <lord_nightrose@yahoo.com>
>Reply-To: assembly-89@lists.ticalc.org
>To: assembly-89@lists.ticalc.org
>Subject: [A89] Re: idiots at large
>Date: Wed, 3 Sep 2003 19:59:49 -0700 (PDT)
>
> >>I seriously doubt that my CS professors have a ticalc.org profile... but
>that doesn't >>seem to affect their programming ability.
>
>Yeah, yeah... Unfortunately, most of my CS professors actually can't
>program, let alone spell. A couple of them do have TICalc profiles, too...
>but they're weird.
>
> >>C has no bounds checking
>Actually, on that note, PocketC for the Palm OS actually does have bounds
>checking, but you have to program it in. It has to do with the fact that
>PocketC labels every byte with a byte telling whether it's a pointer, int,
>double, float, etc. I used to have a PocketC program (that I wrote) that
>could, without fail, tell you the length of a FIXED-length,
>single-dimension array. Of course, I couldn't get it to work right with
>ragged or dynamic arrays.
>
>Greg Dietsche <Gregory.Dietsche@cuw.edu> wrote:
>A great reference on the subject of pointers and arrays can be found at
>this url: http://pweb.netcom.com/~tjensen/ptr/pointers.htm It seems that
>many c/c++ programmers are weak in the area of pointers, and i recommend
>reading through this short tutorial at least once per year.
>
>Jude, Mike, i find that ad hominem arguments are useless as they do not
>present a valid logical argument and merely serve as a distraction. I
>seriously doubt that my CS professors have a ticalc.org profile... but that
>doesn't seem to affect their programming ability.
>
>There is no direct comparison between "char **" and char[][] as both Noveck
>and Hendman have pointed out. you cannot use them in "exactly the same way"
>
>for a simple example of an array of pointers, i'll pick on a char *[] array
>which might have a data structure which looks like this internally (pseudo
>code, data structure and strings = 25 bytes):
>0x1234567,
>0x12345690,
>0x12345d2
>....these strings which are pointed to could be anywhere...
>"abc"
>"de"
>"f"
>"ff"
>
>note that the strings are not of a fixed length and that they could be
>anywhere in memory... the array of pointers tell you quickly look up the
>location of a string.
>
>
>
>
>
>
>char[][] is a *fixed* 2 dimensional array; no pointers involved! a char
>[4][3] array for example will always span 12 bytes and contain 4 distinct
>strings.
>"ab"
>"de"
>"f "
>"ff"
>
>notice the lack of pointers. It is easy to calculate addresses because the
>strings are of a fixed length and as a result we can use simple arithmetic
>instead of pointers.
>
>
>
>dynamic arrays can be of huge benefit; for example, a pointer array is very
>efficient (in terms of speed) when sorting since one can more or less swap
>4 byte pointers. Sorting a char[][] array is cpu intensive because you will
>need to physically copy each string for each swap (3 strcpy operations if
>you use library routines).
>
> >you can't be guaranteed what "char **foo" will contain when you try to
> >access its contents, since something might overwrite it.
>
>arguing that data type is less safe than another is moot. C has no bounds
>checking - buffer overruns can and do happen whether you are careful or
>not. Data does not randomly loose integrity. If your program "overwrites"
>an array of pointers with garbage, then you have a bug - just because you
>make a variable with the type char ** does not make the pointers and/or
>data any more volatile than other data types.
>
>
>Regards,
>Greg Dietsche http://www.gregd.org/
>GForce Programming: http://calc.gregd.org
>Detached Solutions: http://www.detachedsolutions.com
>
>
>
>----- Original Message -----
>From: JudeCN@aol.com
>To: assembly-89@lists.ticalc.org
>Sent: Wednesday, September 03, 2003 7:12 PM
>Subject: [A89] Re: c trouble
>
>
>I second lord_nightrose. If you haven't written anything, then why are you
>automatically saying that we are incorrect? I too have authored many
>programs (about as much as he), including Menu Lib, a compile-time lib for
>TIGCC that handles a great deal of string operations, including
>multi-dimensional string arrays. I think we know what we are talking
>about.
>
>Jude Nelson
>
>
> >>Mike McElroy (a.k.a lord_nightrose) wrote:
>
> >>"Dynamic anything" can be dangerous because you might, if you're not
> >>careful, end up with your variables overwriting each other. Like I said.
>
> >>>>**foo is as said a pointer to a pointer to a char. if something
> >>>>else can overwrite this char (or any of the pointers) or any of the
> >>>>chars in the contigious block that the declaration char foo[3][3]
> >>>>allocates, has absolutley nothing to do with this.
>
> >>Did you really read what I said? You just combined my two examples into
>one... >>char foo[3][3] and char **foo weren't supposed to be the same
>thing. I never said >>they were. I said that you can use char **foo as an
>array. You simply don't have >>the assurance that your data is intact as
>you would with char foo[3][3].
>
> >>Looking at your TICalc author profile, I notice you said you program for
>ASM and >>have authored no programs. I, on the other hand, program for ASM,
>C, and BASIC, >>and have authored 60 programs. Perhaps you should take this
>into account before >>you say I "obviously know nothing about C and arrays
>and pointers." I especially >>urge you to look at the source code to my
>BASIC-accessible C library, MLib. >>Might change your mind.
>
> >>Mike McElroy (lord_nightrose)
>
> >>>>Olof Hedman <alh@home.se> wrote:
>
>Mike McElroy wrote:
>
> > In addition: Although you can use "char **foo" exactly the same way as
> > "char foo[3][3]" (meaning you can read and write values in foo), you
> > can't be guaranteed what "char **foo" will contain when you try to
> > access its contents, since something might overwrite it. Though it
> > might be nice to use for dynamic arrays and whatnot, it tends to be a
> > bad idea.
>
>And this is about as f*d up as the last post. What in the world are you
>talking about?
>You obviously know nothing about C and arrays and pointers.
>char **foo is as said a pointer to a pointer to a char. if something
>else can overwrite this char (or any of the pointers) or any of the
>chars in the contigious block that the declaration char foo[3][3]
>allocates, has absolutley nothing to do with this.
>infact you can be just as sure or unsure.
>its.. as scott said, hard to explain because your statement is so
>fundamentally wrong.
>Something else can change it if you happen to have another pointer
>somewhere pointing to the same place.
>
>And why would dynamic anything generally be a bad idea?
>You should never allocate more memory then you use, specially not on a
>low memory device as a calc.
>Sometimes you use static buffers for speed gain or general lazyness but
>thats about it.
>
>--Olle
>
>
>---------------------------------
>Do you Yahoo!?
>Yahoo! SiteBuilder - Free, easy-to-use web site design software
_________________________________________________________________
Express yourself with MSN Messenger 6.0 -- download now!
http://www.msnmessenger-download.com/tracking/reach_general
Follow-Ups: