• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Obj C ...good style
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Obj C ...good style


  • Subject: Re: Obj C ...good style
  • From: Ian Joyner <email@hidden>
  • Date: Sun, 26 Oct 2008 15:20:42 +1100

On 26/10/2008, at 12:52 PM, Michael wrote:

I hope the list does not mind some basic questions.

I am going through the book by Dalrymple, (Learn objective-C on the Macintosh)  and include a snippet of the program ....which draws some of the attributes of shapes to the stdout. The code is almost irrelevant to the question, which is the following.

What is best practice in Obj C.

It seems in this  case, both the definitions and the declarations occur before "main". Is this the usual practice?

Very usual. If I understand your question right, I'll say the more interesting question is why? Many languages require the definition of things to be "textually" before their use because of the compilation method. You might have heard about one-, two-, or multi-pass compilers. One-pass compilers were developed to reduce the resources a compiler needed to perform a compilation. They typically read the source and generated code straight away and reported errors. To generate code, it meant that a definition (at least a forward reference) was needed before it was called (like your drawShapes). Thus compiler implementation issues affected the language definition.

A multi-pass compiler effectively reads all the definitions in any order and thus does not need forward definitions in order to resolve situations where A references B and B references A. The compiler does not actually read the text multiple times, but builds abstract syntax trees. The first (text reading) pass will perform syntax checks. Subsequent passes can perform deeper semantics and type checking.

Really smart compilers can maintain all the dependencies between files (thus taking on the role of tools like make), and work out where to find the definitions it needs to compile a system. Such compilers can also perform better system wide checks to make sure your program will work and not have obscure crashes. (Thus in effect do a lot of the work of a linker, only in a much more user, or programmer, friendly way.) A true multi-pass, multi-module-aware compiler thus won't even need to burden programmers with book keeping stuff such as #import/includes. Such structuring should be external to program modules.

C has many of the attributes of one-pass compilers (although modern compilers are likely to be multi-pass), and not being multi-module aware, except in the primitive sense of requiring programmers to explicitly #import other module definitions (but that is mostly because to do otherwise would be very inconvenient).

Another thing about your question is that in real-world programming, projects are more complex and it is good to structure programs into several modules (which are most likely distributed across several files). Thus typically, your main will be in a different file and it will #include/import the definitions it needs.

Secondly, **if** for example, "drawshapes" were to have been placed after "main", would the declaration mimic C ( if this is indeed allowed) ie 

void drawShapes (Shape shapes[], int count); 

or 

void drawShapes (Shape [], int );


Thank you in advance.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


#import <Foundation/Foundation.h>

// --------------------------------------------------
// constants for the different kinds of shapes and their colors

typedef enum {
    kCircle,
    /* snip...more shapes */
} ShapeType;


typedef enum {
    kRedColor,
    /* snip...more colors */
} ShapeColor;


// --------------------------------------------------
// Shapes and their bounds


typedef struct {
    int x, y, width, height;
} ShapeRect;


typedef struct {
    ShapeType type;
    ShapeColor fillColor;
    ShapeRect bounds;
} Shape;


// --------------------------------------------------
// convert from the ShapeColor enum value to a human-readable name

NSString *colorName (ShapeColor color)
{
    NSString *colorName;

    switch (color) {
    case kRedColor:
        colorName = @"red";
        break;
    //snip ...more cases;
    }

    return (colorName);

} // colorName


// --------------------------------------------------
// Shape-drawing function

void drawCircle (ShapeRect bounds, 
                 ShapeColor fillColor)
{
    NSLog (@"drawing a circle at (%d %d %d %d) in %@",
           //snip...prints circle attributes
} // drawCircle


void drawRectangle (ShapeRect bounds, 
                    ShapeColor fillColor)
{
    // more code
} // drawRectangle





// --------------------------------------------------
// Draw each of the shapes

void drawShapes (Shape shapes[], int count)
{
    int i;

    for (i = 0; i < count; i++) {

        switch (shapes[i].type) {

       // snip...
        }
    }

} // drawShapes;



// --------------------------------------------------
// Main program that runs it all.  Create some shapes and print
// them out.

int main (int argc, const char * argv[]) 
{
    Shape shapes[3];

    ShapeRect rect0 = { 0, 0, 10, 30 };
    shapes[0].type = kCircle;
    shapes[0].fillColor = kRedColor;
    shapes[0].bounds = rect0;

   // snip...fill array with other attributes
    drawShapes (shapes, 3);

    return (0);

} // main


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Obj C ...good style (From: Michael <email@hidden>)

  • Prev by Date: Re: Just starting off in obj C
  • Next by Date: Re: Console littered by Xcode 3.1.1 garbage collection messages
  • Previous by thread: Re: Obj C ...good style
  • Next by thread: Re: Equivalent to xcconfig conditionals available?
  • Index(es):
    • Date
    • Thread