[Implemented] LinkedLists inside Structures

[ZeHa]

You just said it can produce bugs. Haha.
EVERY new addition to PureBasic can produce bugs. It doesn't matter if it's syntactic stuff, new datatypes or new library functions. If you're so afraid of bugs because of new functionality, then you probably shouldn't move on to new versions of PB.

I think that's obvious. So, are there any other reasons why you're absolutely against that feature (which isn't really a feature, it should be regardet as basic functionality)?

[Dare]

Okay, moving away from the debate and the point scoring ...

Would this sort of thing be hard to implement? My take is no, overall, and also there are several ways it could be handled syntax-wise.

One way might be to define a linked list like we do a Stucture and then apply that to the structure definition, eg.

Code: Select all

DefineList listNameA
  aString.s
EndDefineList

DefineList listNameB
  myString.s
  myLong.l
  myWord.w
EndDefineList

DefineList nestedList
  wooHoo.l
  oneDeep.listNameB
EndDefineList

Structure structName
  someLong.l
  myListA.listNameA
  myListB.listNameB
  confuseUsAll.nestedList
  etc.s
EndStructure

Would that be reasonable?

Regardless ..

I don't think this is above the capabilities of the PureBasic team. (Although it is a fiddly task). I don't know what priority it would have in a list of "What is best for PureBasic" though. It is not only useful for games, but also for anything with transactions involved.

Currently we can use sqlLite in-memory (pdwyer has done some eg code) to handle these things. But it would be nice as a native capability.

[Hroudtwolf]

You just said it can produce bugs. Haha.
EVERY new addition to PureBasic can produce bugs. It doesn't matter if it's syntactic stuff, new datatypes or new library functions. If you're so afraid of bugs because of new functionality, then you probably shouldn't move on to new versions of PB.

I think that's obvious. So, are there any other reasons why you're absolutely against that feature (which isn't really a feature, it should be regardet as basic functionality)?

Young man.
You should know, that syntaxchanges could produce widespread problems than new libs.
So, it is logic that I am against syntaxchanges.

This is my position.

Best regards

Wolf

PS: Please break up trolling. You should accept and respect other people opinion.

[ZeHa]

Well I just think your "paranoia" is not a reason for not adding a good and needed (!) feature. You also offer an alternative for the feature, that should prove that you also understand the need for it.

I think it's possible to dislike feature requests because of a valid reason, but "fear of the bugs" is no valid reason in my opinion. Except if it's obvious that there might occur problems - which is not the case here (or do you think allowing "NewList" inside a Structure definition might cause such big problems? If so - you're welcome to tell us about that (I'm serious about this). If not, well, probably it might not be as dramatic as you're making it).

This is a discussion-forum. If you don't want discussions, your'e not right here.

Yes, probably that's a true thing. Think about it and discuss. I can't see any "discussion" from you, at least you don't answer to anything I wrote, you just keep repeating your "I don't like that"-statements.

[ZeHa]

PS: Nobody forces you to use PB's beta versions. And you know that PB's beta phases are usually long enough for bug hunting.

[Hroudtwolf]

I (and surely many other peoples) find continuing long time hidden compiler specific-bugs outside the beta-phases.
I don't talk about beta-phases.

but "fear of the bugs" is no valid reason in my opinion.

I don't think you have the competence to decide this. ^^

[ZeHa]

I know, because I never produce bugs :roll:

[Demivec]

Would this sort of thing be hard to implement? My take is no, overall, and also there are several ways it could be handled syntax-wise.

One way might be to define a linked list like we do a Stucture and then apply that to the structure definition, eg.

Code: Select all

DefineList listNameA
  aString.s
EndDefineList

DefineList listNameB
  myString.s
  myLong.l
  myWord.w
EndDefineList

DefineList nestedList
  wooHoo.l
  oneDeep.listNameB
EndDefineList

Structure structName
  someLong.l
  myListA.listNameA

  myListB.listNameB
  confuseUsAll.nestedList
  etc.s
EndStructure

Would that be reasonable?

I think using a "DefineList" be a working solution and be straight-forward also. I still think we need some parens on the names though for maintaining consistency. This approach could also work well for a pre-processor, the-provider-of-unimplement-features.

[Psychophanta]

Sincerely i can not see the point of the initial request here

[ZeHa]

It's just about being able to have a LinkedList as an element of a Structure. It's also possible to have arrays inside a structure, so why not a LinkedList?

[Psychophanta]

But as you say, there are many workarounds to do that, and some of these workarounds are really really elegant.
So then to implement that request would be a good way to complicate PB language unfoundedly, imo. :roll:

[tinman]

I'd welcome linked lists inside structures.

To add to the handbags at high noon, I can't believe no-one has suggested syntax based on the syntax of arrays within structures:

Code: Select all

Structure stuff
  a.l[5] ; An array
  b.l[] ; A list
EndStructure

Define.stuff mystuff
FirstItem(mystuff\b[])

; Similar to this...
NewList mylist.l()
FirstItem(mylist())

Of course, you now also need some way to initialise your list field if you create your structures dynamically. Perhaps an InitialiseList() command in the linked list library?

Code: Select all

*dynamic.stuff = AllocateMemory(SizeOf(stuff))
InitialiseList(*dynamic\b[])

It should probably give a debugger warning that the list was initialised when it was already initialised, and perform no operation with the debugger off.

Of course, it's all potentially confusing and easy to get wrong. But PB has already gone down that road with arrays within structures so we might as well use the same syntax ;)

[netmaestro]

When Fred implemented static arrays inside structures he didn't use Dim and standard arrays. He had his reasons for doing so, and they are likely similar to the reasons we haven't seen this.

While I can readily see how some coders would find it useful, my opinion is that it would be a memory management nightmare and I would be surprised if they made this change.

[Psychophanta]

While I can readily see how some coders would find it useful, my opinion is that it would be a memory management nightmare and I would be surprised if they made this change.

+1

@Tinman, what you say is just that pB make that in an automatic way (and conserving the same syntax) instead of do it in an advanced programming way (changing syntax when dealing with structure fields).

It is a discutible dilemma, but my inclination is for the no automatic way to manage lists and arrays as structure fields. But a manual way. Even thinking twice there might not be a surplus to have it. :roll:

EDIT: But another point against is that for a language; the simpler the better. i.e. that 1 unique posibility way to do a thing is better than 2 or more different ways because you must to use more memory in your own brain to know the language.

[DarkDragon]

While I can readily see how some coders would find it useful, my opinion is that it would be a memory management nightmare and I would be surprised if they made this change.

No, because:

Code: Select all

Structure TestStruct
  dataA.l
  dataB.s
EndStructure

; The normal construction of a purebasic like linked list
Structure PB_LinkedList
  *next.PB_LinkedList
  *prev.PB_LinkedList
  dat.TestStruct
EndStructure

; Example how Fred could do it internally without having to do a lot of memory management
Structure TestLLInStruct
  *test.PB_LinkedList
EndStructure

NewList TestList.TestStruct()
Global testStructuredVar.TestLLInStruct

; Initialize the first element
AddElement(TestList())
TestList()\dataA = 42
TestList()\dataB = "Hello, World!"

testStructuredVar\test = @TestList() - 8

; Give it a second element
AddElement(TestList())
TestList()\dataA = 2
TestList()\dataB = "foobar"

; Debug everything through our variable
Debug testStructuredVar\test\dat\dataA
Debug testStructuredVar\test\dat\dataB

Debug testStructuredVar\test\next\dat\dataA
Debug testStructuredVar\test\next\dat\dataB

; So you see how it is working. You could also write the data yourself through the testStructuredVar.
; But for now: That's what PB already internally does. It works with one pointer.
; It would just be nice to have the functions AddElement etc.
; for those testStructuredVar\test pointers as it isn't much more without structure.

; So it's just ONE pointer to a LL element.

@Psychophanta:
JJJJAAAAVVVVAAAA ... CTRL+SPACE ... Windows API ... You know what I mean (MSNM).