1.23: addx/targets are {python, c, obj'c, parasail}:
. if parasail is not on all the needed platforms
the base lang should be obj'c not c;
because, obj'c has better programming-in-the-large features;
well, does it support concurrency?
Showing posts with label dev.obj'c. Show all posts
Showing posts with label dev.obj'c. Show all posts
2013-03-09
2012-01-31
alloc-init pattern's rationale
1.23: sci,bk.adda/lang"obj'c/alloc-init pattern's rationale:
. in {Buck, Yacktman}`Cocoa Design Patterns
they explain the rational for separating init from alloc;
eg, x`= NSString`alloc`init .
. alloc can be a class function because
the mem requirements are known from
the interface ivars list defined by
self and self's superclasses .
. alloc works something like malloc,
only it is accepting a list of types
and converting them into the bytes count
that the malloc needs .
. my first reaction to this convention was:
how would you know what to allocate
until you see what there is to init?
these functions should indeed be separate;
but, the init should be calling the alloc,
rather than init being handed alloc's result by parameter .
. one continuing important reason for this convention
is communicating to client who it is that should be
doing the retains:
. the convention is that convenience methods are
using your autorelease pool .
. using the alloc init is your sign that
you own it (you need to auto/release it yourself )
. other than that, I've seen no intrinsic need for it;
... but, how does inheritance complicate things?
. it looks like the main reason is legacy code:
the Cocoa library can't maintain backward compatibility
unless you follow this convention .
. the main reason alloc was a class method,
was that init should be an instance method
but alloc (the source of the instance)
would have to be from a class method
because instance methods work on instances,
so the alloc couldn't be an instance method .
. I'm not sure whether {Buck, Yacktman} said that;
however, some oop evangelist did say that,
and I'd like to show next,
why I don't think it's true .
[1.31: 1.23:
. the usual oop idioms very much depend on
the root object being a pointer to heap node;
-- where that pointer that is the same size
across all objects --
and that pointer exists even before alloc is called .
. what the object really needs in order to have
access to some instance var's,
is to belong to some specific class;
and, it could get this either by
sending an init msg to the specific class it wants
or by letting the init's param decide on a class,
based upon the type of initial value assigned
(for example, when the compiler gets a value literal,
it can infer a type class from that:
"(abc) is a string
123 is a number
(1,2,3) is an array of number
(1, "(abc)) is a record in (number, string).
) . init figures out what it needs,
and then calls an alloc to help with that .
. if the client has a preference for some alloc technique
that could be a param of the init,
initWith (source, allocWith: style ) .]
. in {Buck, Yacktman}`Cocoa Design Patterns
they explain the rational for separating init from alloc;
eg, x`= NSString`alloc`init .
. alloc can be a class function because
the mem requirements are known from
the interface ivars list defined by
self and self's superclasses .
. alloc works something like malloc,
only it is accepting a list of types
and converting them into the bytes count
that the malloc needs .
. my first reaction to this convention was:
how would you know what to allocate
until you see what there is to init?
these functions should indeed be separate;
but, the init should be calling the alloc,
rather than init being handed alloc's result by parameter .
. one continuing important reason for this convention
is communicating to client who it is that should be
doing the retains:
. the convention is that convenience methods are
using your autorelease pool .
. using the alloc init is your sign that
you own it (you need to auto/release it yourself )
. other than that, I've seen no intrinsic need for it;
... but, how does inheritance complicate things?
. it looks like the main reason is legacy code:
the Cocoa library can't maintain backward compatibility
unless you follow this convention .
. the main reason alloc was a class method,
was that init should be an instance method
but alloc (the source of the instance)
would have to be from a class method
because instance methods work on instances,
so the alloc couldn't be an instance method .
. I'm not sure whether {Buck, Yacktman} said that;
however, some oop evangelist did say that,
and I'd like to show next,
why I don't think it's true .
[1.31: 1.23:
. the usual oop idioms very much depend on
the root object being a pointer to heap node;
-- where that pointer that is the same size
across all objects --
and that pointer exists even before alloc is called .
. what the object really needs in order to have
access to some instance var's,
is to belong to some specific class;
and, it could get this either by
sending an init msg to the specific class it wants
or by letting the init's param decide on a class,
based upon the type of initial value assigned
(for example, when the compiler gets a value literal,
it can infer a type class from that:
"(abc) is a string
123 is a number
(1,2,3) is an array of number
(1, "(abc)) is a record in (number, string).
) . init figures out what it needs,
and then calls an alloc to help with that .
. if the client has a preference for some alloc technique
that could be a param of the init,
initWith (source, allocWith: style ) .]
Objective-C Categories
1.20: adda/type/obj'c categories:
. Apple is using the obj'c Category for mvc separation;*
eg, string has many uses in a command-line interface,
so it exists in the core package
without any methods for drawing on a gui;
categories are then simply extending that string type,
instead of having sublclasses reuse that string type
in yet another type;
so just one class can exist yet with
relevant parts in different packages .
* see { Buck, Yacktman}`Cocoa Design Patterns
todo:
. isn't that use of categories needed only because
it's assuming something demanded by the current oop model?
. if your string wants to talk about gui-specific tricks
like font, or curve following,
that should be served by a drawing record
which then has a string as one of it's parts .
(ie, it's ok to have 2 diff'ing classes !)
--
that was a main point of the book"design patterns:
it was a critique of oop's use of subclassing;
and, that criticism can apply equally well to categorizing;
but, notice it does have a good purpose:
it allows separate compilation of extensions
without having to recompile the original interface
which would then require a recompile of
all the clients of that interface .
. but in this case, the category pattern is not needed,
the pattern to follow is this:
. the whole point of the mvc pattern is that
nearly all programming should be doable without having to
be aware of what your output device is .
. the same program I write for the command-line
should be apply without modification
to use by the gui-interfaced user .
. the runtime is supposed to have a default way of
visualizing your data structures graphically .
. the user is just another inout process
interacting with your process;
so, the gui should be handled by 2 generic packages:
it communicates with a concurrent process,
and then is also aware of 2-d or 3-d
placement preferences of datastruct's .
. so, how does adda let you define special effects
such as those specific to one style of gui?
eg, the curve-following text
needs a record (string, linedata),
and that record should have a particular name, say SL,
so then any var assigned the type SL
will be treated by the adda system as curve-following text
at least when dealing with the contexts
that are specified as customized by SL .
. the 2 primary contexts that work like that
are the user interface,
and the memory usage:
(persistent file, ram buffer, L1,2,3 cache).
. conversely,
when assigning an SL value to a native type,
then all gui-specific info would be dropped .
analysis of what it offers:
. the category has 2 use cases, depending on
whether you have the interface code,
or just have an interface document
that doesn't list the private ivars of the type .
. if you don't have the interface,
the diff' it makes seems purely syntactic:*
native functions can be stated oopishly: x`f();
and with categories you can start writing x`MYf() .
. that is offering more than just
adding a package whose input types are x`type:
the new package is being registered with the type,
so when I ask that type to apply a symbol named MYf,
the run-time engine is able to say it does .
. so, what is the equivalent to that
in lispy procedural (vs oop) programming?
. say the apply-operator is @,
I can then say ('f @ 'x) to mean f(x),
so that to apply dynamically any variable, X,
to any function, F,
I can write X`= 'x, F`= 'f, .... F @ X .
. it then looks to see if there exists a function f
that accepts x`type .
*: [1.31:
. even without affecting ivars,
the diff' it makes can be quite significant;
because, it can override methods that have
special systemic effects on the ivars,
and those effects will be missing .
. the oop syntax allows this:
x`f()`g()`h()
which means that x`f() returns an object x2
which, in turn, understands
what to do with g(), etc .
. so, the functional equivalent to x`f(...)`g(...)`h(...)
is h(g(f(x, ...), ... ), ...).
. that could mean the run-time is doing another check:
is there an f(x`type).y,
such that there is a function named g
that can accept y`type ?
. obj'c is not concerned with that though,
because once you assign a function to a particular type,
the run-time can quickly know to use
the function name f that is registered with that type .
. after that, it doesn't matter whether g can handle it;
because the object returned by x`type according to x`f
is offering no other choices .
. the reason obj'c does it this way
is for the other use case:
where the interface is known so then the
functions being added to x`type
need to register with x`type because
otherwise they won't be granted access to x`type's
private instance var's .
. this, then, is what obj'c categories uniquely do;
it's something like ada's child package feature .
. Apple is using the obj'c Category for mvc separation;*
eg, string has many uses in a command-line interface,
so it exists in the core package
without any methods for drawing on a gui;
categories are then simply extending that string type,
instead of having sublclasses reuse that string type
in yet another type;
so just one class can exist yet with
relevant parts in different packages .
* see { Buck, Yacktman}`Cocoa Design Patterns
todo:
. isn't that use of categories needed only because
it's assuming something demanded by the current oop model?
. if your string wants to talk about gui-specific tricks
like font, or curve following,
that should be served by a drawing record
which then has a string as one of it's parts .
(ie, it's ok to have 2 diff'ing classes !)
--
that was a main point of the book"design patterns:
it was a critique of oop's use of subclassing;
and, that criticism can apply equally well to categorizing;
but, notice it does have a good purpose:
it allows separate compilation of extensions
without having to recompile the original interface
which would then require a recompile of
all the clients of that interface .
. but in this case, the category pattern is not needed,
the pattern to follow is this:
. the whole point of the mvc pattern is that
nearly all programming should be doable without having to
be aware of what your output device is .
. the same program I write for the command-line
should be apply without modification
to use by the gui-interfaced user .
. the runtime is supposed to have a default way of
visualizing your data structures graphically .
. the user is just another inout process
interacting with your process;
so, the gui should be handled by 2 generic packages:
it communicates with a concurrent process,
and then is also aware of 2-d or 3-d
placement preferences of datastruct's .
. so, how does adda let you define special effects
such as those specific to one style of gui?
eg, the curve-following text
needs a record (string, linedata),
and that record should have a particular name, say SL,
so then any var assigned the type SL
will be treated by the adda system as curve-following text
at least when dealing with the contexts
that are specified as customized by SL .
. the 2 primary contexts that work like that
are the user interface,
and the memory usage:
(persistent file, ram buffer, L1,2,3 cache).
. conversely,
when assigning an SL value to a native type,
then all gui-specific info would be dropped .
analysis of what it offers:
. the category has 2 use cases, depending on
whether you have the interface code,
or just have an interface document
that doesn't list the private ivars of the type .
. if you don't have the interface,
the diff' it makes seems purely syntactic:*
native functions can be stated oopishly: x`f();
and with categories you can start writing x`MYf() .
. that is offering more than just
adding a package whose input types are x`type:
the new package is being registered with the type,
so when I ask that type to apply a symbol named MYf,
the run-time engine is able to say it does .
. so, what is the equivalent to that
in lispy procedural (vs oop) programming?
. say the apply-operator is @,
I can then say ('f @ 'x) to mean f(x),
so that to apply dynamically any variable, X,
to any function, F,
I can write X`= 'x, F`= 'f, .... F @ X .
. it then looks to see if there exists a function f
that accepts x`type .
*: [1.31:
. even without affecting ivars,
the diff' it makes can be quite significant;
because, it can override methods that have
special systemic effects on the ivars,
and those effects will be missing .
. the oop syntax allows this:
x`f()`g()`h()
which means that x`f() returns an object x2
which, in turn, understands
what to do with g(), etc .
. so, the functional equivalent to x`f(...)`g(...)`h(...)
is h(g(f(x, ...), ... ), ...).
. that could mean the run-time is doing another check:
is there an f(x`type).y,
such that there is a function named g
that can accept y`type ?
. obj'c is not concerned with that though,
because once you assign a function to a particular type,
the run-time can quickly know to use
the function name f that is registered with that type .
. after that, it doesn't matter whether g can handle it;
because the object returned by x`type according to x`f
is offering no other choices .
. the reason obj'c does it this way
is for the other use case:
where the interface is known so then the
functions being added to x`type
need to register with x`type because
otherwise they won't be granted access to x`type's
private instance var's .
. this, then, is what obj'c categories uniquely do;
it's something like ada's child package feature .
2011-07-30
including obj'c features
7.23: adda/oop/including obj'c features:
. in the expression"( a`b(x)`c ),
the ( a`b(x) ) means
the object"a has a procedure b(x)
that returns an object location
whose available functions include c .
. the syntax"(a`b) is not necessarily
involving self-modification;
it simply means subprogram"b has access to (a)
as an inout parameter
(the subprogram's object parameter).
. is there some efficient way of doing a`b`c
without passing pointers ?
I was thinking there was some virtual way
that doesn't really need pointers
(oop doesn't really need
all the pointers it thinks it needs)...
. if a subprogram's object param
returns a reference to something other than
the object param,
then in the c translation of same
this subprogram takes a destination param;
ie, a param that inputs a destination address
showing where the caller wants the return placed .
. why wouldn't it always take a destination param
even when returning self? ...
because the caller is already housing that obj .
7.26:
. my original concern here
was allowing the passing of references
and the use of object param's,
just like obj'c oop does,
while still using the sort of oop system
that did not generate garbage .
todo:
. I think obj'c has the convention that
even if ( a`b(x) doesn't return anything
if an object reference is expected as a return,
as is the case in "( a`b(x)`c ),
then it will use a reference to (a);
ie, ( a`b(x)`c ) would equal:
( a`b(x); a`c ) .
. in the expression"( a`b(x)`c ),
the ( a`b(x) ) means
the object"a has a procedure b(x)
that returns an object location
whose available functions include c .
. the syntax"(a`b) is not necessarily
involving self-modification;
it simply means subprogram"b has access to (a)
as an inout parameter
(the subprogram's object parameter).
. is there some efficient way of doing a`b`c
without passing pointers ?
I was thinking there was some virtual way
that doesn't really need pointers
(oop doesn't really need
all the pointers it thinks it needs)...
. if a subprogram's object param
returns a reference to something other than
the object param,
then in the c translation of same
this subprogram takes a destination param;
ie, a param that inputs a destination address
showing where the caller wants the return placed .
. why wouldn't it always take a destination param
even when returning self? ...
because the caller is already housing that obj .
7.26:
. my original concern here
was allowing the passing of references
and the use of object param's,
just like obj'c oop does,
while still using the sort of oop system
that did not generate garbage .
todo:
. I think obj'c has the convention that
even if ( a`b(x) doesn't return anything
if an object reference is expected as a return,
as is the case in "( a`b(x)`c ),
then it will use a reference to (a);
ie, ( a`b(x)`c ) would equal:
( a`b(x); a`c ) .
2010-07-27
D language
7.16: news.adda/lang"D:
. reasons to rewrite C to D?
. C is missing module support?
-- that feature helps figure out
where a function is defined;
but, cscope does that too .
. D was designed to remove
most of the flaws from C and C++,
while keeping the same syntax,
and even binary compatibility with C...
and almost binary compatibility with C++.
[. actually,
C syntax is a flaw too,
having decl's only a compiler could love .]
. D is also a mix of low-level
(x86 assembly is part of the language)
and higher-level characteristics
(optional gc, modules,
a fix of C++ templates, etc.).
. implementations include
front ends for LLVM and gcc .
. tango is the community replacement for
digitalmars`Phobos system library .
[7.27:
. unless there's something your lang needs
that simply can't be done in C,
the most simple and portable way
to enjoy working in your own lang,
is to just translate your lang to C .
. that route is esp'ly handy for
platforms like Apple's,
where you really need to be
using their tools .
. having translated to C,
I'm already half-way toward
translating for obj'c and cocoa .]
. reasons to rewrite C to D?
. C is missing module support?
-- that feature helps figure out
where a function is defined;
but, cscope does that too .
. D was designed to remove
most of the flaws from C and C++,
while keeping the same syntax,
and even binary compatibility with C...
and almost binary compatibility with C++.
[. actually,
C syntax is a flaw too,
having decl's only a compiler could love .]
. D is also a mix of low-level
(x86 assembly is part of the language)
and higher-level characteristics
(optional gc, modules,
a fix of C++ templates, etc.).
. implementations include
front ends for LLVM and gcc .
. tango is the community replacement for
digitalmars`Phobos system library .
[7.27:
. unless there's something your lang needs
that simply can't be done in C,
the most simple and portable way
to enjoy working in your own lang,
is to just translate your lang to C .
. that route is esp'ly handy for
platforms like Apple's,
where you really need to be
using their tools .
. having translated to C,
I'm already half-way toward
translating for obj'c and cocoa .]
2010-06-30
oop theories, designs, implementation notes
6.1: adda/oop/based on vari-sized records:
. the 3 sorts of inheritance:
# subtyping:
. inheritors are assignment compatible .
# symbolic description:
. describes one type in terms of
another (incompatible) type .
# generics:
. an object's function is selected by
the function's name (or hash of that)
-- rather than referring to methods by
index, pointer, or offset .
-- this is the obj'c meaning of inheritance; [6.7:
obj'c also supports subtyping . 6.30:
... actually,
any system that supports generics,
implicitely supports subtyping .]
. after review oop ideas,
I wondered if the the trailer idea
would be useful for oop subclassing .
. parameters that vary in size
are accommodated by replacing value with
a mini-pointer (an index into
an associated trailer array)
that then leads to the value .
. a vari-sized record is organized as
a head (the mini-pointers)
and body (the trailer).
. in the vari-length record,
the number of fields is fixed,
whereas in multi-inheriting oop,
not only does the body grow
but the head too is vari-sized .
. provide a mini-filesystem (fs)...
[6.30:
. each class expects to find
it's own instance variables
arranged in the usual way
even when it's one of many ancestors
of the obj's class .
. in a mini-fs, the directory
doesn't have to be on the obj;
just containing a type.tag,
will be eno', since that is a
key to using the lib mgr's map:
(instance's class, ancestor.class) ->
offset into instance .
-- this map shows what offset to use
into the instance
to get to an inherited class's
embedded instance record .]
6.30: todo.adda/oop/obj'c dynamic linking:
. when there is multi-inheritance,
you have an instance variable where
there are separate sections
for each subclass's privates .
. it would be efficient if type-mgr is
passed ptr's to the operated obj's;
and generally,
how is each type-mgr supervised
so as to insure that they
don't affect any surrounding bits?
. you trust your compiler,
but then in obj'c,
you can relink modules dynamically;
and, the new module might be
code from another compiler .
. need to review obj'c
for how to best use,
and not be used by, that subsystem .
6.5: adda/oop/how does c do obj'c dynamic bindings:
. the generic-oop functionality of obj'c
comes from being able to launch a subrogram
when given a function`name and a type.tag;
this could be done in unix by calling to the os
to execute a shell command;
. without that ability,
each addition to the class library
would require editing the obj'c run-time engine
and re-linking it with the expanded class library .
6.7: adda/oop/subclasses as subtypes:
. what is a new type, vs a subtype, in adda?
subtypes can't remove or ignore
inherited functions,
but new types can do a reuse but remove;
how does Ada do this ?
inheritors are new types (meaning it's
not assignment-compatible
with the inherited type);
if you want a variable to have subtype polymorphism
(ie, be assignment-compatible with
all inheritors of Baseclass),
then you need to declare the var's type to be
Baseclass'class .
6.23: pos.adda/obj'c and cocoa bindings:
. the reason to not interface cocoa
is that it's very inefficient with its
ref'counting and its (typical) way
of implementing oop .
. to the extent there does need to be
a binding to it (for the sake of
getting the usual services)
the binding will not be direct:
the mac gives all the power to the developer,
whereas addx will give the user
most of the gui design .
. for example, in nu,
"( locally-scoped assignments are
instances of NSMutableDictionary; )
this might look like an
excellent chance to reuse,
but you might be using thousands of those,
which means juggling a lot of within
both your subsystem's heap
and the mac's system heap .
. it might be ok for prototyping,
but eventually, you want basic services
to be based on your own mem'mgt .
. the 3 sorts of inheritance:
# subtyping:
. inheritors are assignment compatible .
# symbolic description:
. describes one type in terms of
another (incompatible) type .
# generics:
. an object's function is selected by
the function's name (or hash of that)
-- rather than referring to methods by
index, pointer, or offset .
-- this is the obj'c meaning of inheritance; [6.7:
obj'c also supports subtyping . 6.30:
... actually,
any system that supports generics,
implicitely supports subtyping .]
. after review oop ideas,
I wondered if the the trailer idea
would be useful for oop subclassing .
. parameters that vary in size
are accommodated by replacing value with
a mini-pointer (an index into
an associated trailer array)
that then leads to the value .
. a vari-sized record is organized as
a head (the mini-pointers)
and body (the trailer).
. in the vari-length record,
the number of fields is fixed,
whereas in multi-inheriting oop,
not only does the body grow
but the head too is vari-sized .
. provide a mini-filesystem (fs)...
[6.30:
. each class expects to find
it's own instance variables
arranged in the usual way
even when it's one of many ancestors
of the obj's class .
. in a mini-fs, the directory
doesn't have to be on the obj;
just containing a type.tag,
will be eno', since that is a
key to using the lib mgr's map:
(instance's class, ancestor.class) ->
offset into instance .
-- this map shows what offset to use
into the instance
to get to an inherited class's
embedded instance record .]
6.30: todo.adda/oop/obj'c dynamic linking:
. when there is multi-inheritance,
you have an instance variable where
there are separate sections
for each subclass's privates .
. it would be efficient if type-mgr is
passed ptr's to the operated obj's;
and generally,
how is each type-mgr supervised
so as to insure that they
don't affect any surrounding bits?
. you trust your compiler,
but then in obj'c,
you can relink modules dynamically;
and, the new module might be
code from another compiler .
. need to review obj'c
for how to best use,
and not be used by, that subsystem .
6.5: adda/oop/how does c do obj'c dynamic bindings:
. the generic-oop functionality of obj'c
comes from being able to launch a subrogram
when given a function`name and a type.tag;
this could be done in unix by calling to the os
to execute a shell command;
. without that ability,
each addition to the class library
would require editing the obj'c run-time engine
and re-linking it with the expanded class library .
6.7: adda/oop/subclasses as subtypes:
. what is a new type, vs a subtype, in adda?
subtypes can't remove or ignore
inherited functions,
but new types can do a reuse but remove;
how does Ada do this ?
inheritors are new types (meaning it's
not assignment-compatible
with the inherited type);
if you want a variable to have subtype polymorphism
(ie, be assignment-compatible with
all inheritors of Baseclass),
then you need to declare the var's type to be
Baseclass'class .
6.23: pos.adda/obj'c and cocoa bindings:
. the reason to not interface cocoa
is that it's very inefficient with its
ref'counting and its (typical) way
of implementing oop .
. to the extent there does need to be
a binding to it (for the sake of
getting the usual services)
the binding will not be direct:
the mac gives all the power to the developer,
whereas addx will give the user
most of the gui design .
. for example, in nu,
"( locally-scoped assignments are
instances of NSMutableDictionary; )
this might look like an
excellent chance to reuse,
but you might be using thousands of those,
which means juggling a lot of within
both your subsystem's heap
and the mac's system heap .
. it might be ok for prototyping,
but eventually, you want basic services
to be based on your own mem'mgt .
2010-01-31
booking obj'c
1.10: web.addn/dev.c/ms'visual c++:
(even though my primary goal right now is dev.mac,
I often use a pc tablet/laptop (xpw)
and am interested in a c sdk for that platform)
. vcsetup (in downloads) is for ms`visual c++
see tutorial .
. it has an optional game api;
but I doubted this would help sci c on xpw .
. here is a vid showing the ide;
it needs silverlight in firefox (not chrome) .
(opens into win'media player and then is dead )
lib.addn/dev.c/blog.kowalczyk.info:
co.dev.c
co.dev.obj'c
co.dev.mac.
1.15: lib.addn/dev.mac/obj'c:
1.17: the secret life of globals:
. I was wondering if there was some
sure way of knowing how c globals worked:
. did the value remain persistent across
all platform time,
or just the main program's execution time ?
. the [code complete].book reminds me,
to not even use globals .
. atleast you don't have to depend on
their being persistent: use files .
1.19: co.dev.c:
mem mgt tips:
> According to the memory management rules,you're only responsible for objects you create viaan "alloc", "new", or "copy" method,All other objects are autoreleased....Unless your PerformXMLXPathQuery returns an object that you own.But if it does that,it should have been given a better name-- one that has the word alloc, new or copy in it..... the method in question "PerformXMLXPathQuery"is a wrapper that was obtained from cocoawithlove.com .
sci.addn/dev.c/organizing large programs:
. what's the diff'tween separate files,
and when exactly are we including header files?
(I'm getting confused between what's communicated to
the compiler vs the linker)
. the headers are typically just holding the decl's
which are like the import stmt:
the decl' says
a given function type (the signature of it) will be
found among one of your other files .
. just as there are separate {decl's, def's} for functions,
there can also be separate {decl's, def's} for variables .
. shared var's are just like a pascal global,
except that you get the chance to separately compile .
. if you didn't use separate compilation
then you
could simply use the includes for
could simply use the includes formerging all the separately filed def's
and then you wouldn't need the header files .
news"decl's, def's, and perfectly legal C code, oh my!
stumped by c decl's?
cdecl.org converts them to english .
much about loader activity at tenouk.com
--. interesting details like that found in the
[van der linden]`[expert c].book .
2009-10-15
booking obj'c
[10.15:
. notes from reading to learn to obj'c .
. the adda compiler is actually translating the adda language to
the preferred language of the intended platform .
. my first such platform will be mac's objective-c with cocoa libraries .]
. notes from reading to learn to obj'c .
. the adda compiler is actually translating the adda language to
the preferred language of the intended platform .
. my first such platform will be mac's objective-c with cocoa libraries .]
7.12: biblio:
11.1: Programming in Objective-C 2.0 -- links
11.1: Cocoa Recipes old downloads:
11.2: Cocoa Recipes current downloads:
-- can only be opened in older versions of Xcode.
Subscribe to:
Posts (Atom)
