Re: Carbon, threads, and windows...

In article <4738d3f7$0$31738$426a74cc@xxxxxxxxxxxx>,
Adrien Reboisson <adrien-reboisson-at-astase-dot-com@xxxxxxxx> wrote:

Hi,

Back to your original problem: if your main thread does not contain any
OS-dependent code apart from the code inside the library, there might
not be a good reason why it should be the main thread (depending on what
calls it uses, the "loadFromFile" call you mentioned might be one, but
it probably is not). If so, you could move that code to a secondary
thread and give the main thread a normal event loop. It will be a little
tricky to get the 'secondary' thread to signal the main thread to create
the windows, but when you have that, I think you're home (unless there
are things such as mouse clicks and keyboard presses to handle, that is.

Yes, it would be an interesting design. But unfortunately I've not the
time nor the skills to rewrite all the X11/Win32 platform specific code.

??

Furthermore, I don't think that having a port with an entirely different
implementation would be a valid solution to this issue.

Again: ??

The approach would be to write a int main( argc, argv) that:

- creates a thread that calls "MAIN", the function the user writes
- runs an event loop while MAIN is running
- retrieves the return value of MAIN
- returns that value

The only user-visible change here would be that users would have to
write a function called 'MAIN', not one called 'main'. When that is a
problem, you might be able to hack around that, too. The linker has an
option "-e" to set the entry point, and the code for the normal entry
point ("start") is available (alternatively, play with the preprocessor
in the header file: "#define main MAIN")

If you have follow-up questions, can you be more specific, for instance
with a pointer to the library API in question?)

The library is CImg :
http://cimg.sourceforge.net/

<expletive/>! That is not a library, it is a 1.3 MB header file.

It's the CImgDisplay class which is used to render the pictures in an
OS-independant way.

1. Actually, CImgDisplay is declared as a struct (yes, I know that almost
is the same as a class)
2. It is not "the struct CImgDisplay", but a series of struct
definitions, one of which is chosen, depending on preprocessor flags.

From a software-engineering viewpoint, this code _is_ eccentric. That is
a pity, since some parts appear to be well-written. What's wrong with an
interface and concrete implementations for X Windows, MS Windows, etc?

BTW: is there a reason that this must be Carbon? I would guess that
doing this from Cocoa would be (slightly) easier.

The library is written in more than 20K lines of C++ code, so for me the
logical way to go is to use a C framework like Carbon, since -according
to what I read- Cocoa can only be used by Objective-C applications.

Cocoa applications run an Objective-C method, but there is no reason why
couldn't call out to C or C++ code. Having seen the code, I doubt that
it will matter that much which approach you choose.

Reinder
.

Relevant Pages

  • Re: Carbon, threads, and windows...
    ... OS-dependent code apart from the code inside the library, ... not be a good reason why it should be the main thread (depending on what ... to what I read- Cocoa can only be used by Objective-C applications. ...
    (comp.sys.mac.programmer.help)
  • Re: [PATCH][RFC 23/23]: Support for zero-copy TCP transmit of user space data
    ... struct page. ... There is a huge no-no in networking land on increasing skb. ... Reason is simple every skb will carry potentially unneded data as long ... not allowed to be slab ones (xfs was the last one who provided slab ...
    (Linux-Kernel)
  • Re: Design issue: Struct vs. Class
    ... Most are int type values but this one meta data is full of Guid. ... enum supports int etc and not string or Guid so I endup making it a Struct. ... No perticular reason, just to make it look different while programming (as ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Design issue: Struct vs. Class
    ... > After reading the thread "Struct faster than class?" ... > Most are int type values but this one meta data is full of Guid. ... No perticular reason, just to make it look different while ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Thoughts about the new standard
    ... There is no reason any longer for the distinction. ... and pointers were not as clean as they are now. ... unnecessary to specify whether an object is a struct, ...
    (comp.std.c)
Loading