On 06.05.2012, at 02:05, Andreas Grosam wrote:
I would like to use OSAtomicCompareAndSwap32 and OSAtomicOr32Orig using the
same variable. Unfortunately, the first requires a signed int, the other an
unsigned int.
How can I get this to work?
Have you tried union{} ?
union {
On 06.05.2012, at 21:29, Rick Mann wrote:
I've seen this technique in other places. Why is that better than just
casting pointer types? Like this:
int32_t s;
uint32_t u;
u = *(uint32_t*) s;
Your code has two variables and make it the programmer's job to keep them in
On 14.11.2011, at 19:20, Quincey Morris wrote:
Don't follow the advice to define NSWindowCollectionBehaviorFullScreenPrimary
yourself. It's really, really dangerous to replicate a fragment of one SDK in
a build against an earlier SDK. What if the value changes in a later 10.7.x
SDK, or if
On Nov 26, 2008, at 6:44 PM, Scott Ribe wrote:
Actually, it's probably not, because HFS can't store a file with a
: in
it, but can store a file with a / in it. But the UNIX stuff means
much of
the OS can't handle a file with a / in it, so it gets mapped to
: for
the OS. But some Mac APIs
On Oct 31, 2008, at 12:33 AM, Boon Chew wrote:
I am a newbie to the cocoa world (PC - Mac switcher). I have a
fair amount of experience coding in C and C++ and I am just getting
into Obj C now. Right now I am trying to learn the language idioms
and patterns in the Obj C world,
On Oct 30, 2008, at 8:31 AM, Rakesh Singhal wrote:
I have to port a project form windows to Mac. The existing code is in
C++ and classes are inherited from MFC library classes. Do I have any
alternative for MFC in MAC OS?
I have gone through some posting on Apple lists and I found that there
I would also recommend that you start over with the design of your
GUI, for
the sensibilities and design principles of Mac OS X are very
different. This
difference is exacerbated if you consider the age of MFC...
You are aware that MFC (1992) is younger than NextStep (1988)? ;-)
And if
On Oct 15, 2008, at 2:57 AM, Thomas Engelmeier wrote:
Or is there some way to build a single app that runs on both and if
so are there any drawbacks to doing this?
The only drawback is you get partially buggy, backward compatible
behavior on Leopard when you link against the 10.4 SDK.
On Sep 18, 2008, at 7:53 AM, Kiel Gillard wrote:
Howdy,
I think the following syntax is the right idea:
extern C { extern void MyFunction(void *args);
}
I'm not sure about the duplicate 'extern'. Here's what I use in my code:
extern C void MyFunction(void *args);
or you can also do
On Jun 4, 2008, at 8:24 AM, Sean McBride wrote:
Alas, TransitionWindow() is deprecated and not available in 64. So
really I don't recommend it.
Technically speaking, it's not deprecated (at least it's not marked a
such in the documentation). If you don't need 64-bit support, it might
On Jun 4, 2008, at 4:10 PM, Alexander Hartner wrote:
1.) I gathered i have to create a new NSAutoReleasePool in my
threaded method. Is this correct ?
Yes, every thread needs a separate AutoReleasePool. I don't know from
the top of my head if NSThread creates one for you (I usually use
On May 27, 2008, at 4:50 PM, Todd Heberlein wrote:
The gotchas that I often run into are: (1) Changing an Objective-C
file to an Objective-C++ object (by renaming it to a .mm file) often
causes me to rename a lot of files to .mm, because if the Objective-
C class definition has a C++
On May 14, 2008, at 8:33 PM, Scott Ribe wrote:
=== If you are primarily an experienced C++ programmer (In my
experience you will have the hardest time)
(2) I will have to personally disagree with this.
I wonder, seriously, if it doesn't depend somewhat on whether or not
you're
a really
On May 14, 2008, at 7:21 AM, Gerriet M. Denkmann wrote:
I always thought that Cocoa is an Objective-C API, which is a more
convenient counterpart to the more verbose or more cumbersome C API
of Carbon, which often gives more detailed control though.
You would hope that Cocoa and Carbon
On May 14, 2008, at 9:13 AM, glenn andreas wrote:
Also, when you support localization, you really need to use NIBs.
Different languages can easily require different layouts, due to
string lengths (German UI text tends to be _much_ longer often
requiring serious re-do of layouts), cultural
15 matches
Mail list logo
