digitalmars.D.learn - Pointerless Pointers
- Era Scarecrow (11/11) Jul 16 2008 Question, this had come up in my head a few days ago and i'm curious if...
- BCS (4/31) Jul 16 2008 M$ played around with something like that in at least one version (7.00)...
- Era Scarecrow (9/43) Jul 16 2008 I see.. it would probably be a pain to impliment, unless the compiler i...
Question, this had come up in my head a few days ago and i'm curious if it would be useful, or useful enough to use. Using pointerless pointers you would use a template, and a pointer pair values which would probably be done internally to DMD. struct pp{ int ppIndex; int offset; } then using a table that the GC keeps track of, will add it's appropriate locations from the heap where it's being used. void *_PP[]; //somewhere internal. Now say that we're using pointerless pointers on a task with a lot of new's/delete's, and we get low on memory, it will start shifting data so it's all in one place, freeing up larger chunks of unused space, since we're using PP's, the _PP table is updated but the pp's don't have to be, and even if you had a absolute address, when kept track and split into it's index and offset, none of the other data should be compromised. Would this be possibly workable? Era
Jul 16 2008
Reply to Era,Question, this had come up in my head a few days ago and i'm curious if it would be useful, or useful enough to use. Using pointerless pointers you would use a template, and a pointer pair values which would probably be done internally to DMD. struct pp{ int ppIndex; int offset; } then using a table that the GC keeps track of, will add it's appropriate locations from the heap where it's being used. void *_PP[]; //somewhere internal. Now say that we're using pointerless pointers on a task with a lot of new's/delete's, and we get low on memory, it will start shifting data so it's all in one place, freeing up larger chunks of unused space, since we're using PP's, the _PP table is updated but the pp's don't have to be, and even if you had a absolute address, when kept track and split into it's index and offset, none of the other data should be compromised. Would this be possibly workable? EraM$ played around with something like that in at least one version (7.00) of there c/c++ compiler. They called them based pointers. Aside from that (and that it seems they didn't catch on) I don't known anything about them.
Jul 16 2008
BCS Wrote:Reply to Era,I see.. it would probably be a pain to impliment, unless the compiler implimented a union pointer set as, which it could then worry about breaking offsets and non-offsets based on if it was a pp or not. union pointer{ struct pp; void *np; } The only time you MIGHT need this, would be when you make objects/mallocs by the dozens, is that right? (Think Java's String class); However if that is the case, usually where you would need it is fixable by slightly different programming and better planning, removing the need for pointerless pointers. (Unless you wanted to be able to be free of real pointers, except when absolutely neccisary) EraQuestion, this had come up in my head a few days ago and i'm curious if it would be useful, or useful enough to use. Using pointerless pointers you would use a template, and a pointer pair values which would probably be done internally to DMD. struct pp{ int ppIndex; int offset; } then using a table that the GC keeps track of, will add it's appropriate locations from the heap where it's being used. void *_PP[]; //somewhere internal. Now say that we're using pointerless pointers on a task with a lot of new's/delete's, and we get low on memory, it will start shifting data so it's all in one place, freeing up larger chunks of unused space, since we're using PP's, the _PP table is updated but the pp's don't have to be, and even if you had a absolute address, when kept track and split into it's index and offset, none of the other data should be compromised. Would this be possibly workable? EraM$ played around with something like that in at least one version (7.00) of there c/c++ compiler. They called them based pointers. Aside from that (and that it seems they didn't catch on) I don't known anything about them.
Jul 16 2008