Beginners 'C' programing group

[Piru]

@crystall

I think strict ANSI-C code would look like this

#include
#include

int main( void )
{
printf("Hello world!\n");
exit(0);
}

Possibly. However, EXIT_SUCCESS can be used instead of 0, and in general, if there is a define to use, use it instead of fixed value (that way if things would ever change, your code will adapt with just recompile and you don't need to worry about changing all the fixed constants in the code). This is more like generic programming style, not ANSI standard.

I think ansi does state that 0 is "success" for exit(), however. So you're correct here.

Anyway, use of exit() instead of proper failure code path is a bit dull, and forces you to write cleanup stub routines with atexit(), and thus forces you to use global variables. I would advice coders to stay away from exit() if possible, esp if coding for AmigaOS, MorphOS and other compatibles.

The problem is that there is no automatic cleanup for OS resources, just for resources set up by the startup code (stuff provided by the ANSI standard, for example: malloc()d memory, filehandles opened by fopen() etc). So  if you would open a intuition window and call exit() to terminate, the window would not get closed (unless if you do it with atexit cleanup stub routine).

Now I got carried away, sorry. :-)

[Karlos]

that_punk_guy wrote:
(Wonder what Cyberus will be able to read into that comment?)

Everything.

[redrumloa]

Karlos wrote:
Perhaps to avoid off topic discussion and trolling?

The site crew here is very laid back and open to suggestions. If a forum needed strict moderation to keep trolling out, I'm sure they would be open to the idea.

Just my educated guess. :-)

[that_punk_guy]

Could be a problem with posting code on the forum though. Particulary anything with square brackets or nested code where tabbing is necessary for clarification.

[Karlos]

@red

There is a tutorial forum already, right? You could create a C Tutor forum in there with some stricter moderation and various people on hand to answer questions. You'd need to keep an eye on the level of discussion some answers can generate, 'experts talking shop' can go off topic quickly, leaving the person asking the question more confused than before they asked.

Judging when people are going down this route as opposed to genuinely answering questions to the best of their abilites will be the tricky part, IMO.

[FluffyMcDeath]

Karlos wrote:
@thread

If c++ is your thing, the source for the above program (but not the class libraries themselves ;-) ) is all here.

That's mighty pretty, Karlos, but I must quibble.
in:
if (thing) delete thing;

The test is redundant (delete NULL is safe).

if(!thing)
{
    errorPopUpThingy("failed to alloc thing");
}

won't ever happen unless you use operator new(no_throw)
else new throws bad_alloc which you'll need to catch.

[mikeymike]

Well I'm interested in the idea, so chances are I'd frequent it probably more often than moderators just 'checking up', so I think you're safe there :-)

[Karlos]

FluffyMcDeath wrote:

That's mighty pretty, Karlos, but I must quibble.
in:
if (thing) delete thing;

The test is redundant (delete NULL is safe).

if(!thing)
{
    errorPopUpThingy("failed to alloc thing");
}

won't ever happen unless you use operator new(no_throw)
else new throws bad_alloc which you'll need to catch.

@Fluffy

You are absolutely correct about the no_throw, but I'm afraid you are assuming too much.

-edit-
Is it me, or does the above sound like it should have been wrapped in a sort of typical "James Bond villian" tag? :-)
-/edit-

Part of the reason the framework itself isn't pulbic yet is that it was written in that 'less than stellar c++' compiler, StormC.

Exceptions are not used by any of the components because I discovered early on that the exception mechanism in storm is  broken.

Its fine in single thread programs, but the framework defines a Threadable service class (kind of like a fusion of java Thread and java Runnable interface) that allows the class inhertiting the service to have its own internal thread of execution.

I discovered that in multithreaded code, the thread which throws an exception is hardly ever the one to catch it. That is, StrormC's implememntation doesn't do the book keeping.

StormC, even with exceptions enabled doesn't support new(no_throw) in any case, nor does it safely check the null pointer case for delete.

Basically any oddities you see are all down to the fact that I started in StormC++ which was a mistake.

The whole framework code will be moved to gcc which will hopefully not be too much of a problem since I don't use any storm dependent features (other than the ide). Some asm code exists in places (optimised versions of various methods).

Post gcc plans are to use proper exception based error handling (to replace the existing return value model) and probably some namespace resolution for libraries.

First things first, the code will be ported as is. Then exception handling introduced to replace the existing error returns (in places where a genuine error exists, rather than something better represented by a bool return etc.).

The gcc port will also make the cross platform coding a lot easier. Currently the windohs version is maintained in open watcom....

[Cymric]

BigBenAussie wrote:
Look, guys.. I think its great to learn C and all, but doesn't it really depend on what kind of project you want to work on? [...] However, I would imagine that creating AmigaOS apps using a standard C++ class library would be easier than a bunch of C routines with a zillion parameters.

It was about a learning to code-group. That's not the same as a creating AmigaOS apps-group, which requires much more insight into what can be done and how to do it. And aren't you slightly exxagerating the 'zillions' of parameters? I've rarely used more than 4 parameters to a function; if I need more, the function is too complex and must be split up.

C++ can actually be simpler to learn than C if one sticks to the simpler aspects. C++ can be a higher level language, and thus easier to learn, than C.
For example a C++ string object with overloaded operators makes text manipulation a zillion times easier than in C. Changing properties and running methods to manipulate a control of some kind, is, I am sure, easier to do utilising OOP than lower level C calls.

Don't forget you can abstract a helluvalot in C as well using a simple link library. Good C-code already implements a lot of the OO-methodology, with C++ offering more advanced and standardised features. Besides, do you really want to explain operator overloading and the confusing and arcane type promotion rules of C++ to a newbie? Otherwise he will blow both feet and parts of his legs away in the time it takes you to blink.

I would not expect Newbies to build class hierarchies and the like themselves but having them in existence in some sort of toolbox would shortcut development time and lower the threshold for programming in AmigaOS. Everything should be abstracted for the newbies.

Then they're better off with an interpreted scripting language such as Python or Ruby. They don't crash your machine, are very forgiving, and come with tons of 'glue' to link to toolkits, networking libraries, graphics subsystems, and so on. Even C++ looks very primitive and arcane compared to coding setups like these. It is also perfect for rapid prototyping, which can then later on be redone in C++ for speed.

Remember the whole nature of the new OS rewrite was to keep away from the metal so the rationale for writing in C or assembler and directly hitting the hardware is no longer there.

I'm afraid you got that quite wrong. There was never any need to hit the bare metal. People were just not used to program a multitasking environment and therefore made quite illegal assumptions about how the computer allocated its resources. They also thought that the OS would 'hinder' them in what they wanted done. They saw the Amiga as a C64 on steroids, not as a simple but fully functional Unix-machine. Even in the case of the Pegasos and the AmigaOne, I could hit the hardware if I wanted. Of course the OS doesn't (easily) let me, and quite frankly I have no idea what registers and stuff I need to fiddle with, but...

The rationale about the rewrite is to remove the hardware dependencies of the old AmigaOS, both in terms of the CPU as the old custom hardware. Also lots of bugs will be fixed, as well as implementation of much-needed extensions on a fundamental level, rather than tacking them onto the OS in the form of unstandardised user libraries.

I think ease of development so that new titles can be written for the platform is far more important that writing a 3d routine that runs milliseconds faster than before. WE NEED NEW SOFTWARE.

And that is very, very true.

[mikeymike]

Remember the whole nature of the new OS rewrite was to keep away from the metal so the rationale for writing in C or assembler and directly hitting the hardware is no longer there.

I'm afraid you got that quite wrong. There was never any need to hit the bare metal. People were just not used to program a multitasking environment and therefore made quite illegal assumptions about how the computer allocated its resources.

While he did get that quite wrong, so was your explanation :-)

Assembly for example hits the hardware directly.  The programmer tells the computer what memory/chip addresses he wants to reference, and the computer will access those exact addresses.  If they don't exist, the program will fail in one way or another.  Assembler is what's known as a "low level" programming language.  You pedantically and exactly program the computer.  You also need to use an implementation of Assembly that matches your CPU.

C is a higher level programming language than Assembly.    So for example you can use a compiler called 'gcc', which is written for particular operating systems and certain architectures like x86 (rather than a particular x86 CPU).  If you program in C, most of the legwork in specifying memory ranges for your program is done for you (though I don't know much about C, I think you can do things like specify particular memory ranges if you needed to).

Getting back to the point.  There's a reason why programmers "hit the hardware" directly.  Program performance is a damn sight better, and while Assembly programming is extremely pedantic, it is more flexible.  But you couldn't write a program to run on a modern operating system in Assembly, because the OS handles memory, cache, and hardware resources, it would tell your nasty little program that tries to circumvent it to get stuffed.

If say AmigaOS were completely written in C and then used on stock Amigas, it would be slower.  Most of the performance and responsiveness is derived from hitting the hardware directly.  OS4 is virtually a complete re-write from previous versions partly because of the architecture change, but mainly due to how the previous versions were programmed.

Someone can probably do a better job of explaining than I can :-)

[Karlos]

@Cymric

I tend to agree. C is the starting point for someone new.

You need to know C syntax, functions and structures before you have the knowledge base to truly take in what a class is. That's before you get into stuff like overloading, generic programming etc.

One of the things which Bjarne Stroutsrup himself notes in his C++ Language book is that "a good C program is also a good C++ program."

[Karlos]

@mikeymike

You'd be surprised for a "high level" language how low level C really is. Its much lower level than BASIC type languages and as a compiled language it is faster mostly due to the fact that it is quite close to the machine level already.

The beauty of C is that it gives you high level abstractions for things which are a pain (and non portable) to do in asm, without really being much higher.

[mikeymike]

You'd be surprised for a "high level" language how low level C really is. Its much lower level than BASIC type languages and as a compiled language it is faster mostly due to the fact that it is quite close to the machine level already.

Which is why I said "higher level" :-)

[Karlos]

@mikeymike

/me needs stronger specs :-)

[Cymric]

mikeymike wrote:
While he did get that quite wrong, so was your explanation :-). [...] Getting back to the point.  There's a reason why programmers "hit the hardware" directly.  Program performance is a damn sight better, and while Assembly programming is extremely pedantic, it is more flexible.  But you couldn't write a program to run on a modern operating system in Assembly, because the OS handles memory, cache, and hardware resources, it would tell your nasty little program that tries to circumvent it to get stuffed.

If say AmigaOS were completely written in C and then used on stock Amigas, it would be slower.  Most of the performance and responsiveness is derived from hitting the hardware directly.  OS4 is virtually a complete re-write from previous versions partly because of the architecture change, but mainly due to how the previous versions were programmed.

You are right when you say that assembly allows for unprecedented control over the computer. You sometimes have to use it, simply because the things you want done do not have a higher-language equivalent. Program performance isn't as clear-cut, however. Programming in assembly does not automatically make your code fast. You can write incredibly sloppy code in assembly if you want to (or are not careful). 15 to 20 years ago, optimisation algorithms weren't as good as they are now, and people preferred to do things directly in assembly rather than optimise the ever changing output of a C-compiler. 'Slowness' of compiler code had little to do with not being able to directly access custom chip registers or specify addresses by hand: it was almost always a case of unnecessary loop constructs and variable usage. Humans were simply better than the compiler in distinguishing 'good' from 'bad' code, and in some cases could streamline code for global performance. Compilers are still bad at this, as their view is rather localised.

The problem was that many would-be coders did not know how to properly code the Amiga, or looked upon the OS as an enemy instead of their friend. They sought illegal shortcuts mostly because of misguided ideas about 'efficiency'. I doubt that these practices would be the rationale for the rewrite of AmigaOS to version 4; people nowadays understand very well how the Amiga should be programmed and no longer resort to illegal tricks. It's the quickest way to assure that your code won't even run on today's generation of Amigas.

By the way, AmigaOS was largely written in C. Only a few core parts were done in hand-crafted assembly for efficiency. (One ill-fitting part, in BCPL, was hammered and stapled into place, ruining an otherwise elegant design in the process. That part is now completely out of AmigaOS 4.) The responsiveness was not due to the fact that the hardware was hit directly, but simply because the system had relatively lots of computing resources to begin with, while omitting memory protection.

[melott]

Hello All ....

It has been suggested that this Beginner 'C'
group be taken public here a A.Org.
I don't think that would work. The total amount
of EMail that this group is already generating
would soon bury A.Org and nobody would want to
wade through all of it to find an answer to a
question. The thread would be just to big, already,
this thread is longer than most want
to scan through.

I do see where a forum here at A.Org could be
created for indept discussion of the merits of
coding this way or that.
I think if a forum was started like this it
would need a cap on the number of post in it at
any given time, say 20 or 30 posts and the oldest
posts just dropped off and let the forum run
continually.
That might work