From Newsgroup: comp.lang.c



i got no thought on theoretical c few years
but if im back to coding for a while it usually rises some thoughts

some of my recent thought was mess with handles...i know a bit handles
in winapi
(like those terrible gdi objects handles)

i also began to use it recently in my code and
it feels like something is wrong here

this is as a side note maby related to c++
objects trash, becouse much of thsi trash is related to bojests that you
keep via handles

some observation, imo mosc convenient code is when you gos just some
pack ot entities and functions, say like you got for example
framebuffer bitmap and functions to draw on it

you dont need any handle, you just get a name
(this name alos may be a pointer but in such case its rather fortunate
becouse you can use this name for not only static objects but also those dynamic..still i wouldnt call it even handle

problem is such thet yoy may wish to dynamically dreate (allocate)
things thet didnt existed so
its not a name for examply library provides

so what in that case

imo in sych situation doubtfull are such things as returning handle, and passing handle becouse\in oryginal sceneri you didnt do that

you fr exanple just called functions like draw_lien assuming entity data
of gievem piece of code (say framep and frame_w frame h, regardles is
frame is statical adress and frame_w is immediate value or if frame is
pointer to heap,ad frame_w is variable)

so what now? there is a need of something analogical (in a goal to
obtain gol but avoid handles)..but how to do it?

possibly all this assumed entities may be
treated as assumed variables by some module,
aldding module name is no big cost as inner names in code stays the
same..then yu need a way to declate other entities to proide names and
not provide handles

something like

frameBuffer a,b,c;

(its something like 'include' diretive but also with name specification)

all inner functions ale extactly the same
like frmae, frame_w, frame_h and functions SetPixel(0 etc but on te user
side you must specify names unless yu maybe specify than in some context
you use only one and thsi is default

(it makes distinguis on material creation and
unameterial acces - it also shows that it is
probably natural to think on it in a dose of abstract way it is
regardles of omplementation)

its kinda of what i was saing already few times that entity/modular
language is good and obejcts are trash, but it also shows imo tahat
generally handles are kinda inferior probably (and why)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

i got no thought on theoretical c few years
but if im back to coding for a while it usually rises some thoughts

some of my recent thought was mess with handles...i know a bit handles
in winapi
(like those terrible gdi objects handles)

i also began to use it recently in my code and
it feels like something is wrong here

this is as a side note maby related to c++
objects trash, becouse much of thsi trash is related to bojests that you keep via handles

some observation, imo mosc convenient code is when you gos just some
pack ot entities and functions, say like you got for example
framebuffer bitmap and functions to draw on it

you dont need any handle, you just get a name
(this name alos may be a pointer but in such case its rather fortunate becouse you can use this name for not only static objects but also those dynamic..still i wouldnt call it even handle

problem is such thet yoy may wish to dynamically dreate (allocate)
things thet didnt existed so
its not a name for examply library provides

so what in that case

imo in sych situation doubtfull are such things as returning handle, and passing handle becouse\in oryginal sceneri you didnt do that

you fr exanple just called functions like draw_lien assuming entity data
of gievem piece of code (say framep and frame_w frame h, regardles is
frame is statical adress and frame_w is immediate value or if frame is pointer to heap,ad frame_w is variable)

so what now? there is a need of something analogical (in a goal to
obtain gol but avoid handles)..but how to do it?

possibly all this assumed entities may be
treated as assumed variables by some module,
aldding module name is no big cost as inner names in code stays the same..then yu need a way to declate other entities to proide names and
not provide handles

something like

frameBuffer a,b,c;

(its something like 'include' diretive but also with name specification)

all inner functions ale extactly the same
like frmae, frame_w, frame_h and functions SetPixel(0 etc but on te user side you must specify names unless yu maybe specify than in some context
you use only one and thsi is default

(it makes distinguis on material creation and
unameterial acces - it also shows that it is
probably natural to think on it in a dose of abstract way it is
regardles of omplementation)

its kinda of what i was saing already few times that entity/modular
language is good and obejcts are trash, but it also shows imo tahat generally handles are kinda inferior probably (and why)

it also shows a need for distinguishing the names like

inner name (inner module name , it isname of 'global' variable seen form inside of the odule)

external name (unspecified)

external name (qualified)

and it need naming conventions to distinguish it (yet some my add "local
inner variable to de list" as locals seem to be only inner)

for examlpe

main()
{
//...
a=1; //is a local is a inner or is a external unspecified (it could
also be external quaified but only if you add some command to make this
open to qualified external module, i mean like "import namespace of some qualified module"
}

im not sure yet whch conventions should be put here..some basic it seems
come to mind by default would be




main()
{
//...
a=1; //is local
.a =1; //is internal (so called 'global')

b a=1; //external, belong to module b
//but there are possible complications as i said like allowing . to
be skipped or alllowing b to be skipped

//some rules here should be practicall to allow les typing but some
..eventually could be atl least avaliable if not enforced to make
code more understandable (though i seen like for more avalieble than
enforced)

}
--- Synchronet 3.22a-Linux NewsLink 1.2