Deep question for the REAL C GURU's out there ...

[Ben Duncan]

Thanks Kurt ...

<SNIP>
> 
> Nope. It's a common idiom. Quick, without looking, tell me if the 
> pointer dereference happens before or after ms_counter is incremented.

ohhh ohhh chose me chose me ... I precedence the operators are presented in the order of 
their presentation. Since -> and postfix ++ ARE equal, the deference will happen
first, then the increment of the value. However, you are right, since the INTENT here is
to increment the value, and the target of SLAG prolly are NOT going to be such C GURUS's
- as here on the list -, clarity would be ptr->counter = ptr->counter + 1

> If you know the answer, then the code is fine. If you *don't* know the 
> answer, rewrite the code, because I guarantee you won't remember what 
> you were thinking 6 months from now. Personally, I think you're asking 
> for a rogue pointer to creep in, but I write code the same way I write 
> prose: plodding, linear, and step-wise. I'll trade nifty coding for 
> clarity every time.
> 
> 
>>Notice the MenuStatus and the MenuItem pointers. I can set these to
>>directly to the address of the information I need to access. And they
>>WORK as should ( I have tested this out).
>>
>>Now my questions's are:
>>
>>If this works, why does everone use the "aptr->bptr->item" method. Is
>>that more the political correct method? Is there anything BAD or
>>BORKEN with doing the way I am doing it?
> 
> 
> No. Double levels of indirection with structure pointersare more common 
> in the code I usually read and write, especially when trying to 
> implement wrapper code that invokes a function through a function 
> ponter, which is often what aptr->bptr->item ends up being (that is, 
> item is a function pointer, not a scalar data type). The way you're 
> doing it, if "item" ends up needing to point at a function one day, 
> you'll have to rewrite your code.

On day, if I get into functions (LOL). Right Now it is all about manipulating
data. Screen locations, prompts, answers to prompts, pop-up windows, etc. All this
is controlled by building and passing data values to the C code, which is nothing more
than wrappers to S-Lang library. The idea is to extend S-lang with simple commands
much like FoxPro/Delphi/FilePro/AppGen ..etc..etc. with command sets such as
"NEWIN", SAY, GET, SELECT,and so on and so.

Let Mr. John Davies (author of S-Lang) worry about function pointers, since SLAG is
just going to be an accumulation of higher level functions to perform the basic
lower level S-lang library functions. Most of the the Application level and control code
is going to be written in S-lang itself.


It would have be nice if most of the S-Lang library functions are available to the
S-Lang interpreter, but they are not. Hmmmm.... Perhaps I am going ABOUT this the
wrong way and should be writing the missing S-Lang library interfaces to be available
to the S-lang interpreter.


> 
> Kurt
> _______________________________________________
> Linux-users mailing list
> Linux-users at linux-sxs.org
> http://mail.linux-sxs.org/cgi-bin/mailman/listinfo/linux-users
> 
> Need to chat further on this subject? Check out #linux-users on irc.linux-sxs.org !
> 
> .
> 

-- 
Ben Duncan   - VersAccounting Software LLC 336 Elton Road  Jackson MS, 39212
"Never attribute to malice, that which can be adequately explained by stupidity"
        - Hanlon's Razor