Learning C with the Amiga

[Louis Dias]

mel_zoom wrote:
lou_dias:

I never quit once I set my mind on something. I dont think the language looks that bad just yet!

This one worked fine....

#include

int main(void)
{
  const char *result;
  ...
  result = "was funny";
  ...
  result = "backfired";
  ...
}

ah yes, another thing about C syntax that makes no sense

"oh but the address stays the same" ... oh but it still leads to confusion because a variable declared as a constant should remain a constant, otherwise, why call it a constant?

const char result[] = "C is not fun";

[mel_zoom]

lou_dias:

"ah yes, another thing about C syntax that makes no sense"

I dont follow. Ive not looked much at pointers yet but the idea seems self-explanatory so far. Unless I got this very wrong, you have the pointer itself and the thing it points at and either of these can be constant. Thats four possibilities as far as I can see:

pointer to something
pointer to something constant
constant pointer to something
constant pointer to something constant

So far we only saw the pointer to something constant?

[Louis Dias]

Mel,

Why should there be 4 possibilites?

To me, constants are constants because their values don't change.  Like pi.

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.  When the compiler does it's job in converting to machine language, I don't think it sees the difference between a constant pointer and the pointer it generates for a normally declared variable.  Infact, I would say there is more of a performance hit since declaring a typed variable in advance means it allocates the space right away rather than when the code is running.

[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 :-)

[Cymric]

Karlos wrote:
Wrong again. 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.

Quite true. The following code will run happily on an Amiga:

Code: [Select]

   char *s = "Hi!";
    ....
    s[1] = 'a';
    ....
   
but will crash on a Unix computer because the string 'Hi!' is saved in memory which cannot be written to. The program will crash with a 'segmentation fault', a sure indicator of the program poking in memory where it shouldn't be. The problem is that there is nothing wrong with the above code: it's the implementation by the compiler which fscks things up.

[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:

[falemagn]

lou_dias wrote:

mel_zoom wrote:
lou_dias:

I never quit once I set my mind on something. I dont think the language looks that bad just yet!

This one worked fine....

#include

int main(void)
{
  const char *result;
  ...
  result = "was funny";
  ...
  result = "backfired";
  ...
}

ah yes, another thing about C syntax that makes no sense

"oh but the address stays the same" ... oh but it still leads to confusion because a variable declared as a constant should remain a constant, otherwise, why call it a constant?

The const qualifier in const char *var doesn't mean that var is constant, rather that the data it points to is constant.

To get a constant pointer to char you write char *const var.

[falemagn]

I plan to learn c++ once I have a better understanding of c. At least I was told this was a good idea

C++ isn't strictly a superset of C, so that may actually give you a few headaches. But you do look skilled, so I'm quite sure you'll overcome all the bad sides of that. ;-)

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. Except, it won't help you much with the Amiga API, which is strictly C-based.

Statistically (but don't ask me to quote any numbers, don't have them at hand :-P) the majority of bad C++ programmers are the ones trying to use C++ as a "C with classes".

[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 ;-)

[falemagn]

Karlos wrote:

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.

I must admit that the OO aspect of C++ isn't what I like most: I'm a fan of template metaprogramming, operator overloading and data abstraction, I just love how you can make C++ behave almost like any other language (albeit with limitations that hopefully C++0x will get rid of).

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 ;-)

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.

[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 ;-)

[Jupp3]

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.

However in MY opinion, OOP is a "way of programming" that can be applied to ANY programming language, even to assembler. Of course some languages (not C++, imho) force you into OOP style.

I like C becouse in my opinion it's easier to think "what kind of code the compiler will produce", something that many people would argue, that it doesn't matter at all anymore. C is definitely better for REALLY small projects (talking kilobytes of compiled code here) and in the end it's up to you which ever programming language YOU prefer.

Both SDL and OpenGL were created to be used on C (but it's obviously possible to use them with other languages aswell)

And last but not least, my current work project is in C :-)

[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.

[SamuraiCrow]

Cymric wrote:

Karlos wrote:
Wrong again. 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.

Quite true. The following code will run happily on an Amiga:

Code: [Select]

   char *s = "Hi!";
    ....
    s[1] = 'a';
    ....
   
but will crash on a Unix computer because the string 'Hi!' is saved in memory which cannot be written to. The program will crash with a 'segmentation fault', a sure indicator of the program poking in memory where it shouldn't be. The problem is that there is nothing wrong with the above code: it's the implementation by the compiler which fscks things up.

Actually AmigaOS 4.0 final DOES do memory protection on constant data by making it read-only.  It's only versions 3.x and earlier that don't work correctly.

For a better implementation of strings than is present in the C language use the Better String library.  Beware of the dual-licence it is under, though, since neither GPL nor the most recent BSD licence allow for the programmer to place the code under a different licence than it was originally under.