Learning C with the Amiga

[Karlos]

You should always use the last form when writing portable commandline applications. Amiga specific stuff can use ReadArgs(), but that's further down the line.

At the very least, never use plain "main()" without int return type (and remembering to actually return an int from it, zero for success). That's just a legacy anachronism.

[Karlos]

Steady wrote:

Also, traditionally argn tends to be called argc, but it doesn't really matter. It's just a name.

That would be my fault, I put some simple examples on a CD ;-)

Personally I generally tend to use "int argNum, char** argVal".

[Karlos]

@lou_dias

No need to #include or .

Better to use "int main(void)", your main() doesn't specify anything whatsoever about arguments (C contrasts to C++ in regarding an empty parameter list as "no information given" rather than "no arguments"). Also, remember to return an integer, preferably 0 for success.

Never assign a string literal to a plain "char*" unless you really want to be able to modify its contents later, in which case the behaviour is undefined anyway (that is to say, modification of a string literal is undefined). Safer to use "const char*"

"if () ;" is bad style. Always surround the with braces, even when it is a single statement. A common source of error for beginners is to forget that the true branch of the "if" statement as you have written it ends at the first semicolon.

5/10: Could do better.

[Karlos]

@lou_dias

Why should there be 4 possibilites?

Mel is correct. Two entites are involved, the pointer and the object pointed to, each of which can conceivably exist in two states. 2*2 = 4. That's just basic numeric behaviour.

Now to say you will constantly point at 1 address and what's really important is the information at that address and then tell me that information can change, what's the point of a constant pointer? Just use a variable.

I guessing you've never written anything in C that has to deal with direct hardware addresses? Consider the amiga's custom chip registers, for example. They aren't variables you can directly access, just fixed addresses in memory that hold values that you can read and/or write.

Would you really want to change pointer to a specific custom chip register after it has been set up? No, because then you are no longer dealing with the same register, naturally. Such pointers are best defined as constant pointers to data that may vary (the data isn't constant, but where it resides is).

You have to remember that C was designed to support system level programming (kernels, drivers etc) and not just application level programming, so these various pointer specificaions are important.

I don't think it sees the difference between a constant pointer and the pointer it generates for a normally declared variable

Wrong again, I'm afraid. Constant items (pointers included) may be allocated in write-protected pages of memory on some implementations (ok, not amigaos), physically preventing it from being altered after it has been assigned.

-edit-

Anyhow I think perhaps this side debate might be a bit off topic at this stage :-)

[Karlos]

@Cymric

Some compilers can warn about this type of potentially dangerous assignment but alas gcc isn't really one of them.

[Karlos]

@Jupp3

Is it programs? Is it games? Is it something else?

I expect it's to be better informed so that she can know when members of the developer team are making excuses about why various things aren't ready yet :lol:

[Karlos]

Yet, any good C++ book, even an online one, will give you enough information about all the C you need to know to code good C++, so starting with C++ might be a good idea overall.

I'd generally agree with that. Syntactically the differences aren't really that many (except C++ template syntax of course, which has no equivalent in C at all), it's mostly the new paradigms it introduces and the various C habits it discourages that are the stumbling blocks. Learning C++ from day 1 wouldn't require you to forget any C bad habits.

Yet for all that, I have seen more people get around the differences from C to C++ (having learned only the bare minimum up to structures and pointers) a lot more readily than people trying to manage C++ from scratch in the same overall timescale. I think it's just down to the idea of walking before you can run, really.

So on consideration, I do think its usually helpful to just play around with C for a while before making the jump.

-edit-

I should add that, IMNSHO, anybody that knows C and doesn't think it's worth making the jump to C++ either hasn't understood what OOP actually is and how it applies to any non-trivial project or hasn't realised just how much easier C++ can make many problems in C appear.

-/edit-

As for dealing with amiga APIs after migrating to C++, well that's where the fun is; inventing your own class libraries to wrap it all up for you ;-)

[Karlos]

@falemagn

Well, that only supports another assertion of mine that C++ pretty much offers "all things to all people" as far as programming goes. Nobody said you have to use any particular feature. You can basically get it to do whatever you want, however you like.

[Karlos]

That may be fun, but it's tedious to reinvent the wheel each and every time. Would be nice to have a publicly available c++ foundation class library.

Which is exactly what I was working on when I still had the time ;-)

[Karlos]

@Jupp3

Don't get me wrong, C is a great language for procedural programming, probably the best. As you say, you can use just about any paradigm in just about any language. It comes down to how well the paradigm is supported as to which language suits best. C++ is good because it supports several well. What I am trying to say is that C++, in respect to C is two things:

1) a language that directly supports OOP
2) a better implementation of existing C

Suppose you prefer using C code, which is fine, there's still no reason not to compile C code in C++ mode and take advantage of stricter type checking, inline functions and the like. You can, at any time, decide you want to add some methods or constructors to data structures that operate on them and suddenly you have primitive classes.

As for code generation, there is no significant difference to C whatsoever. I've examined the asm output of a _lot_ of C and C++ code. What applies to C usually applies to C++ too. The only bits that can be hard to follow are the output exception handling constructs. The rest, including stuff like virtual functions and the like are perfectly easy to understand at an assembler level.

[Karlos]

@SamuriCrow

It's only versions 3.x and earlier that don't work correctly.

Perhaps, but we were talking about 3.x anyway since that is what Mel is learning with. The point was only raised to explain the need for "const type*" and wasn't meant to be an attack on amiga os :-D However, I have a nasty feeling your mentioning OS4 and memory protection in the same sentence will trigger a flame war very soon ;-)

[Karlos]

@lou_dias

Sorry, but I think you misunderstood what Mel was getting at.

struct Struct1 { int someInts[10]; short foo; };

is _very_ different from

struct Struct2 { int* someInts; short foo; };

-edit-

The difference is that in Struct1, you have 10 ints together as a direct block of data followed by a short. In Struct2, you have a single int* pointing to an unknown number of ints (possibly none at all), followed by a short.

They are only the same in terms of the syntax involved in accessing their members.

but remember, I don't know anything so don't believe anything I tell you

*whistles innocently*

[Karlos]

@Mel

Passing structures by value is perfectly legal, but as you guessed and others have pointed out, it's quite slow.

Generally it's better to pass by reference, using a pointer than by value if all you want to do is read from the structure. To ensure that you can't accidentally "poke" the structure thus passed you can use a "const struct coord*".

One reason for the difference is that syntactically arrays and pointers are synonyms for the same underlying entity. Therefore, how would you actually represent passing an array by value when "int* x" and "int[] x" actually represent the same thing?

There are rare times when passing structures by value can make sense and certainly returning them by value can also be useful in some cases. Generally this is true when the structure is small, like your coordinate. The cycle-cost of allocating memory for a small structure and returning a pointer to it (which you also have to remember to free later if you don't want a memory leak) can easily outweigh the cost of simply returning it (or rather a copy of it, allocated on the stack) by value by an order of magnitude*

*this, of course assumes you don't have an instance of the structure already to hand, waiting to be used/modified, in which case, pass it by reference and let the function alter it.

-edit-

Also, if your structure is no bigger than a pointer (possibilities include bitfield structres and unions containing nothing larger than a pointer), performance wise there's no gain in passing by reference.

[Karlos]

@AJCopeland

Any reason you prefer (*pCompItem).member over pCompItem->member ?

[Karlos]

Karlos and YOU assumed I was responding to her "code" when I was actually responding to her prior set of several questions

I was responding to:

Even if a structure contains an array, the value within the structure representing the array is a pointer.

If I misunderstood what you meant by that, feel free to correct me.

However, embedding a fixed length array of X versus a plain pointer to X within a structure are still completely different cases, as I pointed out earlier.

In other words, you could, if you felt so inclined, pass a fixed length array by value simply by wrapping it in a structure and passing that by value. The entire array would be copied in that case.