A sticky for learning C`s use of pointers & wintypes

[Zebuddi123]

@ Fred would it be possible for a sticky, possibly in windows or general section for adding pdf chm`s etc and other relevant info about C`s use of pointer`s and win variable types, for those of us who are interested in getting a better grasp on being able to interpret C`s pointer nuances and stuct`s etc.

Anyone else think that this is a good idea

Zebuddi.

[luis]

I think "pdf chms etc and other relevant info about C`s use of pointers and win variable types" have no place here, at least in a sticky, nothing wrong in linking them in a post or discussing about them in a thread.

1) they are for another language, one should just learn the other language or consults its relevant documentation available elsewhere.

2) when someone is coming here asking "how could I translate this to PB" he's not gonna look at the docs available here if he hasn't looked at the docs available at the "elsewhere" mentioned at point 1, he just want something done for him by someone else now for the immediate problem he's having

3) if someone is asking a more specific question then what described at point 2, he has already read the docs available elsewhere or he already know the foreign language, the docs here likely wouldn't help him, but a concise and to the point reply probably yes.

4) maybe it would be different if the docs were specifically talking about interfacing or translating constructs between PB and the other language, but again you could just make a post about that, to be linked in a more general sticky perhaps.

5) my opinion is irrelevant since I don't decide what it will be sticky or not but I had 180 secs to spare.

[TI-994A]

Anyone else think that this is a good idea

I'd find it useful, especially as it relates to PureBasic. Great suggestion Zebuddi123.

[Zebuddi123]

@ Luis For me it`s purebasic all the way!. I only suggest it here that we could have some easily accessible info posted by forum member as they see relevant to learning how these parts work and in relation to PB.

As the majority of source code (worldwide) is C based and there is quite a bit on our forums where members have used win api and other, which can be very bamboozling if not initiated in these arts

I also have to say without any disrespect some of us are not formally trained in the arts of programming, we are self taught, bedroom coders and tinkerers, we are nowhere near as advanced as some of the Guru`s here on this forum, myself included.

I don`t wish to promote C or any other language but to understand where relevant for our betterment in the use of PB (beginners, intermediate`s etc)

Zebuddi.

[TI-994A]

...some of us are not formally trained in the arts of programming, we are self taught, bedroom coders and tinkerers...

I think that to some extent, all of us are. College taught me COBOL for some reason, and coming from a six-year background of BASIC, I resisted that god-awful language. I had always wanted to make the shift to C, but BASIC was just so comfortable, with QuickBASIC, BASIC PDS, and then once VB came along, I never looked back. And now, with PureBasic, I never will.

But basically (pun intended), I can't consider myself formally trained.

[idle]

yes it'd be a good idea especially when it comes to dealing with char **string parameters to a function

There's usually no issue converting structures only needing to substitute
c int = pb long
c long = pb integer
c short = pb word
c char* = pb string as in str.s

or if you see a bit field ":" followed by a number
foo : 2
bar : 2
substitute them with a pb integer foobar.i (not sure if that's correct may need to add up the bit count and use the closest type)

[luis]

it comes to dealing with char **string parameters to a function

I just had to deal with this:

Code: Select all

Bool XF86VidModeGetAllModeLines(Display *display,  int screen,  int *modecount_return,  XF86VidModeModeInfo ***modesinfo);

Triple indirection, someone offers more ?

[idle]

Code: Select all

Bool XF86 VidModeGetAllModeLines(Display *display,  int screen,  int *modecount_return,  XF86VidModeModeInfo ***modesinfo);

Triple indirection, someone offers more ?

where's a barf icon when you need one
something like this?

Code: Select all

 
;in the function def *ppModes.XF86VidModeModeInfo)

global modes.XF86VidModeModeInfo 
global *pmodes = @modes 
global *ppmodes = @*pmodes 

VidModeGetAllModeLines(@display,screen,@modecount_return,@*ppmodes) 

[TI-994A]

where's a barf icon when you need one...

I can understand address of address; but address of, address of address?

I love PureBasic. (where's a heart icon when you need one)

[luis]

something like this?

Hi idle, actually If I understand correctly while I like the idea of *pmodes and *ppmodes I think that would be okay if I had to PASS a structure using triple indirection, but I have to RECEIVE a list of structures using triple indirection.

I did it this way:

Code: Select all

EnableExplicit

ImportC "-lXxf86vm"
 XF86VidModeGetAllModeLines.i(*display, screen, *modecount_return, *ppmodesinfo)
EndImport

ImportC "-lX11"
 XOpenDisplay.i(display_name.p-utf8)  
 XCloseDisplay(*display)
 XDefaultScreen.i(*display)
EndImport

Structure XF86VidModeModeInfo Align #PB_Structure_AlignC 
 dotclock.l
 hdisplay.u 
 hsyncstart.u
 hsyncend.u
 htotal.u
 hskew.u
 vdisplay.u
 vsyncstart.u
 vsyncend.u
 vtotal.u
 flags.l
 privsize.l
 *private
EndStructure 

Global ModeNum, *modes, *mode.XF86VidModeModeInfo 
Global screen, dpy, i
    
dpy = XOpenDisplay("")
screen = XDefaultScreen(dpy)

XF86VidModeGetAllModeLines(dpy, screen, @ModeNum, @*modes)
 
*mode = PeekI(*modes) ; triple indirection -> XF86VidModeModeInfo ***modes 
 
For i = 1 To ModeNum
    Debug "Mode " + i + " = " + *mode\hdisplay + " x " + *mode\vdisplay    
    *mode + SizeOf(XF86VidModeModeInfo) 
Next 

XCloseDisplay(dpy)

[Danilo]

There's usually no issue converting structures only needing to substitute
c int = pb long
c long = pb integer

For C's "long" data type it depends on the platform. It is PB's Integer on Linux and Mac. On Windows it is PB's Long data type.

I just made a small overview picture:

(Shows size in Bytes for each data type. 1 Byte = 8 Bit.)

Download the source: c_cpp_datatypes.zip (276k)
(C/C++ source for Win/Linux/Mac + result table as .TXT, .PDF, .DOCX, .JPG, .PNG)

[luis]

Nice useful table, thanks

Another useful reading -> http://en.wikipedia.org/wiki/64-bit_computing (LLP64/LP64 memory models)

Unfortunately native language data type it's not all you have to consider when translating C code, because each API often redefine stuff with the same name but different meanings. For example with Xlib (something I'm working with right now), Bool is a C int and so a PB long.

You have to follow back all the typedefs until you reach the original data type.