Substructure member list

[frankie]

Pelle,
I don't know if it's an actual limitation or just my way of coding, but if I define a structure or union the IDE member list automatic feature doesn't suggest list members unless I declare indirectly the structure/union in a typedef. I mean:

Code: [Select]

struct tst1 { float a; int b};  /* Indirect declaration */
typedef struct tst1 TypTst1;  /*This works*/

typedef struct { float a; int b} TypTst2;  /* direct declaration don't work */

typedef struct tst2 { float a; int b} TypTst2;  /* defining the tag name don't work either */

If my structure union contains other structure/unions as in:

Code: [Select]

struct tst {
          struct a1 {
                           float f1;
                           int    i1;
                        };
          union a2 {
                           int    c1;
                           float c2;
                        }
           };
typedef struct tst TypTst;

I cannot have the member list of the substructures! :cry:
Anythyng you can do?
Thank-you

[Pelle]

I don't know if it's an actual limitation or just my way of coding, but if I define a structure or union the IDE member list automatic feature doesn't suggest list members unless I declare indirectly the structure/union in a typedef.

Mostly limitations, I guess.

You must have a tag name, otherwise it will never work. If the structure is defined in the current source file, the IDE should be able to find it - unless there is a syntax error, like in you example (maybe a typo?):

Code: [Select]


typedef struct tst2 { float a; int b} TypTst2;

- no ; after "int b".

If the definition isn't in the current file, the project must be built - for the browse info database to be updated...

Nested struct/unions are not supported. It has been on the wishlist for a long time, but I'm not sure if/when it will be supported. This will require some changes to the database format, among other things. This, in turn, means I will (probably) have to convert existing databases - not very funny...

Pelle

[frankie]

Pelle wrote:

unless there is a syntax error, like in you example (maybe a typo?):
Code:

typedef struct tst2 { float a; int b} TypTst2;
 

- no ; after "int b".

Yes it's a typo the program I used for test is compiled correctly.
I see that this is very complicate becouse you need indexing for subtypes in database and this is a rather hard work, but this could be a very useful feature when working with large and complex structures and union.
Anyway thanks and I hope the day you will have time for this is not very far away.

[Pelle]

Maybe in the next version...

I seem to be messing with the browse info in every release - I'm starting to get rather tired of that. A better, and more stable, solution is really needed.

For version 4.0 I researched the possibility to use the compiler to build browse info, rather than a separate tool (pobr), but in the end this was much worse than the current solution.

Maybe it's best to continue with pobr, and extend it with support for nested structures and so on, but I'm not absolutely sure about this...

Pelle

[Pelle]

Frankie,

One other thing - before showing the member list, I try to rebuild browse info for the current source file - but I can only use the current disk image. If the struct definition hasn't been saved to disk yet (you just typed it), this means it will not be found.

I will add a check if the general option 'Save files without prompting before build' is used, and in this case save the file before building the browse info (otherwise I think the user should decide when to save, and when not to...).

This will at least catch some more cases...

Pelle

[frankie]

Pelle,
I always saved my files and made a full compilation before trying the member list feature (that becouse I got aware that you build browsing info's during compilation).
I understand that this task is not easy, but I was wondering if the problem is not in way you handle symbols. I mean actually you collect much information about each of them, but maybe by simplifying the approach you can get the goal. When you meet a structure union you have simply to browse the names inside, if it contains any tag or is named structure you can create a new symbol with that names as if it was and independent structure. If the inner member is nameless you don't need to create another symbol, but simply put all the names together. On member list side it could be just a recursive search, i.e. when the user type the symbol and it is a structure you can show the members related to it, when the user types the structure member restart checking this symbol if it's another structure, and in that case show its membership. What I mean is that to get the complete efficency you don't need complicate relations between database records, but simply to break down to the atom each part and search recursively each time (with a reentrancy limit anyway, I have seen other compiler loop inside the browser generator and stuck).
About the browsing info generation have you thought about using a background task with low priority that continuosly checks and updates the database?

[Pelle]

I understand that this task is not easy, but I was wondering if the problem is not in way you handle symbols. I mean actually you collect much information about each of them, but maybe by simplifying the approach you can get the goal. When you meet a structure union you have simply to browse the names inside, if it contains any tag or is named structure you can create a new symbol with that names as if it was and independent structure. If the inner member is nameless you don't need to create another symbol, but simply put all the names together.

On member list side it could be just a recursive search, i.e. when the user type the symbol and it is a structure you can show the members related to it, when the user types the structure member restart checking this symbol if it's another structure, and in that case show its membership. What I mean is that to get the complete efficency you don't need complicate relations between database records, but simply to break down to the atom each part and search recursively each time (with a reentrancy limit anyway, I have seen other compiler loop inside the browser generator and stuck).

Part of the problem is that since declarations can be "recursive", so is the code in POBR. It's actually a chain of functions, and I would have to pass around additional information to know something about "outer scopes". It would be both messy and ugly. It's easier to write each struct/union as a separate item.

I think tag names will always be needed for "top level" structures, especially if it's also a typedef name. I can probably parse the "free text" field, containing the variable declaration, for substructures (especially since it's cleaned up and normalized in v4.0) - but I will not try that right now.

I have, however, rewritten two functions to be recursive, and as long as all structs/unions have tag names, even sub-structs/unions - it seem to work.

For the following code:

Code: [Select]


name1.name2.name3.


when the last . is typed, I scan backwards all the way to name1, and build at list of names - this list is passed to the database search function. It will try to nest into the struct/union. This also means, like before, that you can type name1.name2.name3, move away in the code for a while, get back to the position after name3, press ., and it will still work - in other words, not in a specific "mode" while typing.

Requiring tag names is of course not perfect, but it's surely much better than before. I will include the changes in beta 3 - probably at the beginning of next week.

About the browsing info generation have you thought about using a background task with low priority that continuosly checks and updates the database?

Yes - I might do it some day, but I'm a little bit afraid about synchronization problems.

Pelle

[frankie]

Pelle,
About the tag names we can consider that when the tag is missing you cannot reuse the structure definition for another variable (unless you rewrite the whole structure). So the structure name should be unique in the scope. In this case you can use the name assigned to the structure as a tag.
Do you think that this could work?
To reduce the charge on the software could be helpfull to trigger the member list search on user request (by keypress) instead of start it automatically?

[Pelle]

Frankie,

About the tag names we can consider that when the tag is missing you cannot reuse the structure definition for another variable (unless you rewrite the whole structure). So the structure name should be unique in the scope. In this case you can use the name assigned to the structure as a tag.
Do you think that this could work?

This might work. The problem here is that since the tag name is found first (if any), I can tag each member as they are found. If I'm going to use the identifier, found last, I will either have to "cache" all members before writing them to the database (more complicated code), or write temporary records to the database and later "patch" them (slow/slower).

To reduce the charge on the software could be helpfull to trigger the member list search on user request (by keypress) instead of start it automatically?

Maybe. The most obvious things is of course to use "." or "->" as the trigger - you don't have to learn yet another key combination. Also, any new hotkey means changes to Customize -> Keyboard, which will affect resources and translations - it starts a chain of changes.

My computer may still be on the "top half", although several years old, but I can't notice any slowness here (except perhaps when caching the database for the very first call...)

Pelle

[frankie]

Pelle,
maybe it's me that miss something, but when you found a struct keyword you already know that a struct is following, if a tag is present you can use it, if not you can use a placeholder to update when you meet the name.
Moreover if the substruct is unnamed you can leave the placeholder so while browsing you know that you're working on an unnamed struct.
About the key to trigger the search was an idea based on the fact that if the browser generator code grow-up bigger you can avoid some problems. Anyway I too don't experience any slow-down on my computer for the member list searching.

[Pelle]

What I try to say is that today, in POBR, parsing is intermixed with writing database records. Each structure member will have it's own record.

If the variable name is to be used as a tag, when there is no "real" tag, I will have written all members to the database before the parser sees the variable name. In this case I will have to search the database and update each member record with the new tag. This will take more time, possibly much more time, than today...

Another approach is to build an internal list of all member names and line numbers, and write everything when the entire struct have been parsed. This is at least complicated by the fact that the type parsing is recursive.

Pelle

[frankie]

I understand now, what is still not clear to me is if in the member record you put a reference to the structure tag/name (used as access key for the database) or the reference to the record (in this case a unique record number access key). In the first case it will be a nightmare to update the database, in the second case, if the tag is missing, you can create a dummy record with a placeholder name for the structure while the members will point to this record with a direct record access key. The dummy record could be adjusted when the structure scanning is finished modifying just one record. Of course there could be a difficulty, due to recursion, to know when the scanning is really finished and to trace down the placeholder.
I wan't bother you, I'm just trying to give you some ideas (helpfull I hope). Anyway I'm sure you'll find a very smart solution.

[Pelle]

To make a long story short: I think it's working now. In the end I decided to use fabricated tag names (when they are missing), and fabricated source code in the free text field (to avoid a database conversion nightmare). A bit of a hack, but as I said, it seem to work...

I wan't bother you, I'm just trying to give you some ideas (helpfull I hope).

Yes, I understand - and I'm grateful for that. It's easy to get stuck in one solution - this discussion has been very useful to me...

Pelle

[frankie]

I'm very happy that you found a good solution  =D> (I just declared that I have no doubt! :wink: ).
When you talk about a fabricated tag name you mean what I called a placeholder (a unique name automatically generated using some structure reference)?
And last I'm very happy to have been of some help.
Hope to see next beta in short (next week as stated above?)

[Pelle]

When you talk about a fabricated tag name you mean what I called a placeholder (a unique name automatically generated using some structure reference)?

It's something like: __pobr_tag_sourcefile_nnnn. I added the source file name to make it a bit more unique - and nnnn is just a unique number.

When I want a list of all members, I just search the tag field for members with the given tag - when going deeper into nested structures, I search for a specific member and tag name, then look in text field for "struct tagname" or "union tagname" which will give me (hopefully) a new tag for the next level - and the recursion continues...

Hope to see next beta in short (next week as stated above?)

Yes - it looks like monday.

Pelle