nesting commands

[Tomio]

Hello,

this is an appendix to my bug report --> PeekB(StringField(t2$,2,".")) <-- recently.

Nesting commands is allowed.
Can someone tell me if PeekB(@StringField(t2$,2,".")) or perhaps PeekB(StringField(t2$,2,".")) should be allowed.

Or does it violate programming rules?
And if so, what is the difference to something like Trim(StringField(t2$,2,".")), which surely is an allowed nesting.

Thanks../tomio

[The_CodeMaster]

euhm.. PeekB()-function expects a memory adress as parameter, not a string like the StringField()-function returns.

Trim(StringField(t2$,2,".")), however is a valid nested command.

You only need to respect the datatypes from the functions u use, then you can nest as many as you want.
When you write an @ before a function you mean the offset (in memory) of that function so this always returns a 32-bit number.

[The_CodeMaster]

PeekB(@StringField(t2$,2,"."))

Is also valid but I don't think that's of any use

PeekL(@StringField(t2$,2,".")), however will just return the offset of the StringField()-function like I allready said.

[Tomio]

PeekB(@StringField(t2$,2,"."))

Is also valid but I don't think that's of any use

PeekL(@StringField(t2$,2,".")), however will just return the offset of the StringField()-function like I allready said.

> I don't think that's of any use

;here is one of arbitrary many uses:
t$="Ablabla,Fqwaqas,Bxxxx,Onmnmm,Z"
For i=1 To 1000
Select PeekB(@StringField(t$,i,","))
Case 'A': ;do something with the string
Case 'B': ;do something with the string
Case 'C': ;do something with the string
;...
Case 'Z': End
EndSelect
Next


I know what PeekB() does.
And @t$ is the address of t$
And PeekB(@t$) gives back the first byte at the address.
And that's exactly what I want. Not the string itself.

So, as far as I know, PeekB(@t$) is ok. Tell me if I'm wrong.
By the way, a search for "peekb(@" in the forum gives several topics back.

So: >>> in case I'm right <<< --> PeekB(@StringField(...)) should be ok also.

PB does not have the many specifications of types like C, so
PeekB should not care where the address @ comes from. It's just an address (correct me).

I sent a bug report, but hmm, I never got something like: "It's not a bug because..." or "ok, I put it on the bug-list".
And answers like "no sense" or "be cautios" are simply not an objective explanation.

Perhaps I'm stupid, but still I can't see what could be wrong with this thought.

****** Is someone out there who makes it to explain me? ******

../tomio

[The_CodeMaster]

You wrote:

So: >>> in case I'm right <<< --> PeekB(@StringField(...)) should be ok also.

It's not a bug (rather a personal oppinion), it just isn't the way purebasic works when using @ for procedures/functions. You'll just have to store your string in a variable first.

Edit: But your right about my second reply (if you store StringField(t$,i,",") in a variable first, however), didn't saw that one comming

[GedB]

Tomio,

According to the help you can use the @ symbol to return the address of a variable, or the address of a procedure.

There is nothing about being able to get the address of the return value for a procedure.

http://www.purebasic.com/documentation/ ... emory.html

It appears to work, but is an undocumented feature that leaves the stack in a corrupt state in some circumstances.

I would say that if you are nesting functions then you must respect types. If you want to use pointers, then you must use a variable.

edit: fixed typo quoted by codemaster.

[The_CodeMaster]

I would say that if you are nesting functions then you must respect types. If you want to use pointers, then move use a variable.

Like I allready said, thx GedB

[GedB]

Picked me to it.

It would be nice to hear the official verdict.

The use of @Stringfield is very confusing because it treats built in procedures differently to user defined ones, which is not good. The following gives a syntax error:

Code: Select all

Procedure.s myProc(a.l, b.l)
  ProcedureReturn Str(a+b)
EndProcedure

Debug @myProc(2, 2)

While this returns the address of the procedure:

Code: Select all

Procedure.s myProc(a.l, b.l)
  ProcedureReturn Str(a+b)
EndProcedure

Debug @myProc()

With a built in procedure it works the other way round. This returns a pointer to the result:

Code: Select all

Debug Asc(StringField("1 2 3", 2, " "))
Debug PeekB(@StringField("1 2 3", 2, " "))

While this gives an 'invalid number of paramaters' error:

Code: Select all

Debug @StringField()

If there is a bug, it is this incosistancy. I think you should be able to get an address of a built in procedure. There are circumstances where you might want to pass a built in procedure as a callback.

[The_CodeMaster]

@Tomio: Btw, I think your topic better fits in the 'feature requests and Wishlists' section.
Maybe you could phrase it like the abbility to use for ex. a '*' before a procedure by which you mean a direct pointer to the procedures return value. If the procedure hasn't got a return value 0 is passed through since 0 isn't a valid pointer.

[Tomio]

Hello alltogether,

To read my final answer please see the bug report --> PeekB(StringField(t2$,2,".")) .

Thanks for your answers!
.../tomio