Re: [Tinycc-devel] Newcomer to TCC (and C) with a couple ofquestions..

[lostgallifreyan]

Kalle Olavi Niemitalo <address@hidden> wrote:
(02/04/2009 09:17)

>
>lostgallifreyan <address@hidden> writes:
>
>> Do the required deletions of device contexts (to spare GDI
>> resources) get done by code compiled by TCC, or do I have to do
>> this explicitly, as I do in wxLua, for example?
>
>AFAIK, TCC does not have any specific support for Windows GDI
>and does not automatically generate code to delete GDI objects.
>So if Windows requires your program to delete some GDI objects,
>then you must yourself write the appropriate GDI calls.
>

That makes sense. If it's Windows specific than I'd expect to have to do it. I 
would anyway, if in doubt. I didn't know if other OS's had a similar need, but 
even so I should have known that this would be the task of the language rather 
than the compiler. I'd just wondered if it might have been one of those things 
that was general enough for a smart compiler to do but I don't much of what 
goes into compiling code.

>> I ask because in wxLua, every colour, every pen and brush, is a
>> DC that must be deleted the instant no longer required, yet the
>> single GUI example supplied with TCC has a colour (COLORREF)
>> for text colour that does not appear to have a specific
>> deletion following it.
>
>I don't think Windows GDI requires programs to delete COLORREFs.
>Generally, if you allocate a resource with some Windows function,
>then the documentation of that function says how you should free
>that resource.  If you construct a COLORREF with the RGB macro
><http://msdn.microsoft.com/en-us/library/dd162937(VS.85).aspx>
>then this documentation does not say you need to free the
>returned COLORREF.  Likewise with the GetSysColor function
><http://msdn.microsoft.com/en-us/library/ms724371(vs.85).aspx>.
>And the documentation of COLORREF itself
><http://msdn.microsoft.com/en-us/library/dd183449(VS.85).aspx>
>says the COLORREF value just contains the RGB component values
>in its individual bytes.  Thus, no actual resource has been
>allocated in Windows and there is nothing to free.  (With
>"resource" here, I don't mean the things you compile with
>Resource Compiler and link into *.exe files.)
>

Good point. At some level an RGB value is just a set of values. I think that's 
why wxLua surprised me by requiring that a colour was a resource as much as the 
pen was. I'm very new to C (was relectant for a long time) but once I know what 
things are actual resources I can navigate better. I wish there was a more 
elaborate example based on the supplied "hello_win" program though, taking 
apart working examples or editing them is the way I learn fastest. I looked at 
header files and saw several things I think I can learn to use, but it will 
take me a while to know which ones must be handled the way wxLua taught me to 
handle GDI resources. (Point taken about not confusing with icons and such 
compiled and linked, and you've hit on a point there, ambiguous choices of 
words for stuff makes this even harder than it already might be).

>If you create a brush (HBRUSH) with CreateSolidBrush
><http://msdn.microsoft.com/en-us/library/dd183518(VS.85).aspx>
>then the documentation says you need to delete it with
>DeleteObject.  But if you instead use GetSysColorBrush
><http://msdn.microsoft.com/en-us/library/dd144927(VS.85).aspx>
>then you must not delete the brush.  So always read the
>documentation.
>

Ok. I understand that system coloured objects used in the OS at large are there 
for the using of, as it seems are some like the five HBRUSHes black, dark grey, 
grey, light grey, white. Judging by the header files, I guess that if I have to 
create some graphic object that wasn't in easy reach, as in defined in a header 
file, then I will assume I must delete it too. Nice tip, that GetSysColorBrush, 
I might have created the brush and assigned the system colour myself, but it 
seems there's a better way if I want one of those. I note that 'must not 
delete' too...

You cite from MSDN... I take it this is because TCC defaults to using MSVCRT? 
(Or, I read tonight, Kernel32.dll if the program entry point was written to 
avoid using MSVCRT). So I guess that this is entirely Windows native C for the 
Win32 TCC compiler. Still confuses me a tad though, ANSI C being portable. I'm 
not sure where the general and the specific meet there.. And that means I'm not 
sure how I should write any GDI oriented code if I want it to compile on Linux. 
I'd thought the same might apply to both.

>Note also that Windows GDI provides ways of drawing different
>colours while using just one device context and one pen or brush:
>e.g. GetStockObject(DC_BRUSH) with SetDCBrushColor.  That may be
>faster than creating a separate pen or brush for each colour.
>You mention Windows 98 though; I don't know whether this works
>there, as Microsoft has ended support for that OS and removed
>from the MSDN library apparently all information on which
>functions are compatible with that.
>

I can still try though. :) I've considered it, just not as a priority. But I 
can try it in wxLua to see if it borks. I'll have to find some tool that gives 
me a decent measure of GDI resource usage though. The ones I tried didn't 
register problems while I was working on it last month, despite me expecting 
them to. But if wxWidgets' wxPen can take a colour change after creation, I see 
no problem with that, and hopefully can extend the idea to C. But for the first 
few bits of work I'll likely settle for writing in Lua and converting, and 
exploring what my known Lua code looks like in C.