Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: mel_zoom on January 25, 2007, 12:45:52 PM
-
Hi!
Ive decided to have a go at learning C on the amiga. I do know a little bit about the language and programming in general but Ive never really written anything.
In my introduction, someone pointed me at AmiDevCPP but this is clearly windows software and if possible Id prefer to use an amiga native environment.
What options are there given a relatively bare minimum of experience?
-
Easiest way to get development environment is to get hold of Developer CD 2.1 that covers up to OS3.5 and comes with StormC v3 C/C++ IDE.
-
Initially, I started by studying C++ at university, I managed to pass, however, it was something I had no intention of returning to. A few years later I thought I'd have a stab at C so I started reading;
The C Programming Language (ANSI C) - B.W. Kernighan & D.M. Ritchie
After a few weeks, I realised I sucked at that too, so I've pretty much given up on them both, just can't seem to get my head around them.
-
Don't let the detractors get you down! C is awesome! Actually, I haven't coded in C for years, but want to get back to it - especially on the Amiga.
The are several packages available freely, or commercially there is SAS C, which I use. DL examples and study them to learn if you haven't got anyone around to teach you. If you really understand what computers are and how they work, learning C is easy, but you will have to spend some time on it.
The rewards are worth it.
Come on guys, point her to some useful information regarding compilers, source, etc.
-
StormC is not a very good compiler. I used it in the past but I switched to GCC because it allows me to compile my code everywhere and it's more portable.
I would advice you to use Cubic IDE (http://www.developers.2go.cc/) as it is maintained actually, has syntax highlighting, uses gcc to create the code etc...
You don't need OS3.5 developer CD.
NDK 3.9 will be more than enough to get the autodocs.
-
I agree with Crumb.
Cubic IDE is the way to go, but it is still good to get the Developer CD 2.1 because it has the Amiga Rom Kernal Manuals in AmigaGuide format. They are OK for referencing, but if you can, you should try and at least get the actual Libraries RKM book. Although it is hard to find and the same content is on the CD, it is easier to work through the actual book. At least, that's what I found.
Good luck.
-
Here are 2 links with information about Amiga related C Books:
http://www-eksl.cs.umass.edu/~atkin/amiga/books.faq.html#SEC4
http://www.faqs.org/faqs/amiga/books/
-
There is a book by Augie Hansen:
"A Complete Guide to Mastering the C Language"
An old book that has survived for almost 20 years.
A great guide, and a good buy these days. I saw copies on Amazon for a buck or so. You won't need another book for a year or so.
RLFrost
-
I downloaded GCC and the C++ version as well back in '95. I didn't have the luxury of nice IDE's like there exists now, but I managed.
GCC is free and really good for compatibility as someone has already mentioned.
Just find in nice IDE to do your code editing and a good book like "C for Dummies".
C isn't hard or confusing until you get into compiler directives and #include, #if... stuff as your projects grow in size and complexity...
I'm curious, what other languages do you know?
EDIT:
You don't need a developer CD to do basic C programs that will run in a CLI/shell window. Just get gcc and a text editor and that's all you need. Tutorials are all over the internet on the basics of C programming.
-
@Mel:
If you really just want to start learning C (nothing at specific standards), you should use StormC3 IMO. If I remember correctly you own a bare 1200 with a Blizzard1230, right?
GCC is much too heavy for such a machine and the "wins" won´t get off the "looses" (mainly compiling speed, which is a pain in the *ss using GCC on such a machine, even more if it isn´t equipped with a SCSI expansion and lots of FAST ram).
I know what I´m speaking of, because I tried it on a machine exactly like yours. Simply unusable. VBCC will give slightly more speed, but is too big for it, too. Fun begins with 68040 and fast SCSI hard drive (and LOTS of ram for GCC use, the more, the better. Face it, fans: GCC is a ram-eating monster).
StormC3 from the Developer CD2.1 runs quite smooth on such a machine like yours, gives syntax highlighting etc. and is therefore good enough to start with.
Later on you could decide to switch to another compiler package (maybe at a time when you push your machine to a higher level, e.g. Blizzard1240 with SCSI kit and 32MB ram or such) like GCC or, for pure C even better (because way faster in compile speed and is comparable to GCC regarding standard support, optimizing and compiling quality etc.) VBCC.
Greetz
-
@ Mel_Zoom
I pointed you to AmiDevCPP because, of all the C compilers for the Amiga that I've tried so far, it was the easiest to use. I've tried StormC and Cubic IDE and I still have issues trying to get stuff to compile with them. To be fair, I haven't spent a lot of time on the effort, but that's the whole point. It's easier to learn when your time is actually spent doing, rather than struggling with the very tools that are supposed to be helping you.
Here's a couple more useful links:
* Amiga Utility Base: documentation on Amiga libraries. (http://utilitybase.com/)
* Amiga C Encyclopedia on AmiNet: How-to examples in C, old but useful for learning. (http://www.aminet.net/search.php?query=Amiga+C+Encyclopedia)
Ed.
-
hi mel_zoom!
two bits of advice:
1. get yourself a nice personal project to sink yer teeth into - that will help to motivate.
2. get hold of anything by Herb Schildt.
3. okay three bits of advice - badger Karlos!!
increasingly innacurate 4. get a Dev kit CD, and browse. find some examples, and perhaps a copy of an SDK guide.
on OS4 I have SDK viewer, not sure if it applies well to OS3 though...
good luck, have fun!!
-
I've done exactly the same about two years ago.
AFTER learning C, the gold reference on coding on the Amiga is the RKM Libs volume. It's oriented towards C (the most used language on the Amiga by far), and it goes from basic to very advanced. I found it's an awesome read because it goes directly to the point explaining how to use the OS and how some OS internals work, with some included examples. It's actually included in the DevCD2.1 others mentioned but nothing like a good book read so I've actually bought the book too. By the way, don't let the size of it intimidate you (almost 1000 pages:)), you don't need to read all that stuff to code on the Amiga.
As a compiler for a not very expanded Amiga I'd choose SASC. But if you want the stuff you'll learn to be usable on other platforms GCC is a better option (but with this one you'll need an 030 at least and even that will be damn slow).
Cheers
José
-
I think you guys are asking her to walk before she has learned to crawl.
GCC is not "slow" for learning C. She will not be waiting for 20 minutes to compile:
#include stdio.h
void main() {
printf("Hello world.");
}
Nor will it take long to compile examples using basic structures like linked-lists.
She doesn't need to know how to program OS apps before she even learns the language.
GCC and a simple text editor is all she needs and both are free.
-
I agree - GCC is great, even on a basic amy (tho its been a few years for me and my c compilers). I regularly use it on other architectures and have to admit that I am now feeling the urge to get down with C on the amiga (now where did I put my amy- oh yes still trying to get one)
:lotsacoffee:
-
It seems a recordable CD containing GCC and the NDK was left on my desk, along with a copy of the K&R C Language reference and another called "Mastering Standard C".
I wonder who left those.... ?
;-)
-
Starting with the basics, Ive been looking at variable "types". Lets see if I got this right
A "char" is 1 byte in size
A "short int" is at least as big as a "char"
An "int" is at least as big as a "short int"
A "long int" is at least as big as an "int"
From what Ive read so far, different systems agree on the "char" but differ on the rest, but typical sizes for current systems are
"char" 1 byte
"short int" 2 bytes
"int" 4 bytes
"long int" 4 bytes
Also all of the above can only represent whole number values and may be specified as "unsigned" or "signed" too but with "signed" being the default for anything other than a char?
Is this correct so far?
-
I wonder who left those.... ?
Ooo! Ooo! Let me guess! Was it... Santa Karlos?
-
mel_zoom wrote:
Starting with the basics, Ive been looking at variable "types". Lets see if I got this right
A "char" is 1 byte in size
A "short int" is at least as big as a "char"
An "int" is at least as big as a "short int"
A "long int" is at least as big as an "int"
From what Ive read so far, different systems agree on the "char" but differ on the rest, but typical sizes for current systems are
"char" 1 byte
"short int" 2 bytes
"int" 4 bytes
"long int" 4 bytes
Also all of the above can only represent whole number values and may be specified as "unsigned" or "signed" too but with "signed" being the default for anything other than a char?
Is this correct so far?
Correct so far.
Old source codes made for SAS C and DICE C compilers treat int as a 16-bit word since the original 68000 processor was 16-bit. For reasons like this you might want to include exec/types.h at the beginning of your Amiga-specific source codes and use BYTE, WORD, and LONG for the respective 8, 16, and 32-bit signed types and UBYTE, UWORD, and ULONG for the respective unsigned types.
One more thing you might want to look into before you get too involved are the SDI Headers (http://www.aminet.net/dev/c/sdi_headers-1.6.lha) which will let you generate Amiga-specific code in such a way that it can be recompiled on AmigaOS 3.x, 4.0, and MorphOS and their respective different versions of the compilers with few (if any) additional changes.
-
@lou_dias:
Yeah, I see, for programs of such class GCC is a MUST and Storm is absolutely unsuitable ;)
I think we gave her enough tips, she should have a look herself, what´s suiting her needs best.
But one thing: Compared to Storm, SAS, vbcc et al GCC IS slow. Awfully slow. More than 5 times slower than Storm on a 030 miggy without min. 16 MB ram. On other (bigger) AmigaOS machines vbcc outperforms all other compilers.
Be fair and test it yourself instead of overtaking other people´s meaning without critics. GCC is a so-to-speak standard, but it´s definetly not "the best" compiler out there. This depends on the project´s needs, I would say.
Greetz
-
@Mel
I have the complete set of RKRM's, each book released in each edition.
I don't use them at all these days, I could lend them to you if you promise to take good care of them.
-
Hi!
I actually compiled some code last night. One thing I have noticed is that the definition of "main" varies a lot in examples. So far Ive seen the following
main()
{
}
main(void)
{
}
int main()
{
return 0;
}
int main(void)
{
return 0;
}
int main(int argn, char** argv)
{
return 0;
}
My question is, which one should I be using? The last one seems pretty explicit but Im told that its the best one to use even though the first one is in the K&R book as the principal definition :-?
-
The last definition is the most 'correct' one because when your program starts, the main() function will receive a pointer to all the arguments on the command line in argv as an array. argn contains the number of arguments that were supplied (including the name of the command).
For example, if you were to type the following at the Shell prompt (not including the quotes):
'dir ram: all'
the main() function arguments would contain the following:
argn = 3
argv[0] = "dir"
argv[1] = "ram:"
argv[2] = "all"
You can think of the array as a list of the words on the command line that can be read separately by counting from left to right. Counting starts at 0.
Also, traditionally argn tends to be called argc, but it doesn't really matter. It's just a name.
Hope that helps.
-
mel_zoom wrote:
My question is, which one should I be using? The last one seems pretty explicit but Im told that its the best one to use even though the first one is in the K&R book as the principal definition :-?
For this sort of question I refer you to the excellent and witty C-faq (http://www.faqs.org/faqs/C-faq/faq/), which in this case states that the correct declaration is at the least
int main() { }
or
int main(void) { }
to tell the C-compiler (though not a C++-compiler!) that you're not expecting any arguments to main(). (The C++-compiler is a bit more literal and sees the above as two different functions: the first doesn't expect any parameter, the second expects a parameter of type 'void'.) If you do want arguments, then the correct declaration is
int main(int argc, char *argv[]) { }
The upshot is that you should end main() not with a plain 'return;' but with a 'return ;'. The integer is usually 0 to indicate that the program completed succesfully, if you set it to 5 or 10 AmigaDOS interprets this as a warning, and with 20 or higher it creates an error message. (I think, it's been a while :).)
To make things a bit more complex: the above mechanism works only for programs you start from the CLI. For programs which start from the Workbench, you will need to use a different and much more Amiga-like mechanism. For now you can ignore its existence, but remember that you need to perform a bit of special processing if you want your program to be double-clickable.
-
Go SAS. I used it 16 years ago so its gotta be good by now.
They still exist Mainframe and Unix(Solaris/HP-UX/AIX) stuff now. I'm sure no one there would know they had once supported the Amiga.
-
Hi,
If you understand German, my C workshop may be the right place for you to start:
http://www.norman-interactive.com/C-Kurs.html
-
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.
-
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".
-
Im told that its the best one to use even though the first one is in the K&R book as the principal definition
If you read the K&R, take into account that it describes an obsolete version of C and that it will expose you to what is no considered bad style or obsolete.
There were several revisions of C (e.g. C90, C99 around 1990 and 1999), parallel to the invention of C++. The book of your choice should at least cover C90. If you download the Cubic IDE development environment (free for beginners) and its C++ package, you will find it includes an electronic book on C90 and some C99:
http://www.developers.2go.cc/cubic/download.html
-
Mad_Dog wrote:
Hi,
If you understand German, my C workshop may be the right place for you to start:
http://www.norman-interactive.com/C-Kurs.html
how about translating it to English ? That way it will profit to a much bigger andience (including myself).
Thanks
-
And me :-P
-
To make things a bit more complex: the above mechanism works only for programs you start from the CLI. For programs which start from the Workbench, you will need to use a different and much more Amiga-like mechanism. For now you can ignore its existence, but remember that you need to perform a bit of special processing if you want your program to be double-clickable.
Small correction: standard Amiga C startup code does handle WB startup just fine. Any output will open a console window. When started from an icon, argc is 0.
-
Hi!
Wow so many ways to start a program in C! I think Ill stick with the basic "int main(int argc, char** argv)" one for now.
-
mel_zoom wrote:
Hi!
Wow so many ways to start a program in C! I think Ill stick with the basic "int main(int argc, char** argv)" one for now.
Basic? Shh, you´ll wake the VB dragon. ;-)
int main(void) {} is the basic way anyhow. :-)
-
Hi!
I think Im actually making progress in the theory and I have just finished installing from the CD Karlos gave me. Fingers crossed I can actually compile something soon :-)
-
CannonFodder wrote:
mel_zoom wrote:
Hi!
Wow so many ways to start a program in C! I think Ill stick with the basic "int main(int argc, char** argv)" one for now.
Basic? Shh, you´ll wake the VB dragon. ;-)
int main(void) {} is the basic way anyhow. :-)
The dragon has awaken.
However, it is a wise old dragon and know when trolls are trying to feed it poison and decides to go back to sleep.
Anyway, this method works just as well:
#include
#include
#include
void main()
{
char *Result;
int CannonFodder, funny;
funny = 1;
CannonFodder = 0;
Result = "";
if (CannonFodder != funny) Result = "not";
printf("Cannon Fodder is %s funny.\n",Result);
printf("Cannon Fodder is a %d\n",CannonFodder);
}
See what you get...
-
@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
:roflmao:
-
lou_dias:
"See what you get..."
Well I could guess but I thought it might be interesting to see how it liked your definition of "main":
gcc -Wall test.c -o test
test.c:5: warning: return type of `main' is not `int'
Cannon Fodder is not funny.
Cannon Fodder is a 0
Im told that all good c programs are also c++ programs so I also tried in c++ mode and then it didnt compile at all.
g++ -Wall test.c -o test2
test.c:5: error: `main' must return `int'
test.c:5: error: return type for `main' changed to `int'
So according to that advice, this is not a good c program.
If you are planning to ridicule someone elses abilities shouldnt you do it in an "upwards compatible" way?
-
LOL @ all
:pint:
The topic is learning C not C++, anyway I wrote it from scratch and not on a compiler.
As I've mentioned before, I know enough C/C++ but don't use it at all at work and haven't tried in 10-12 years.
Ofcourse these "complaints" are my whole problem with the language as well as all the different standards.
It seems beginners fight more with the language than the actual art of programming. Who does that help? I understand it's place for core stuff like kernels and drivers, but for robust user applications, with today's processing power, I don't feel it's ideal.
Mel, may I recommend Hollywood 2.x to you. It's one way to do Amiga programming and have it work on OS3, OS4 and AROS. It's really an over-looked product. It's as close to a ".Net" programming paradigm as you'll find in Amiga-land.
-
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;
int lou_dias_joke;
int backfired;
lou_dias_joke = 1;
backfired = 1;
result = "was funny";
if (lou_dias_joke == backfired) {
result = "backfired";
}
printf("lou_dias joke %s.\n", result);
return 0;
}
-
Mmm. Is there some way to keep the indentation when posting?
-
Ive decided to have a go at learning C on the amiga. I do know a little bit about the language and programming in general but Ive never really written anything.
That's a good idea. I also like the idea of starting to learn with C. Many people say they'll "start straight from C++" when many (including me) think that it's a good idea to learn the basics in C.
Of course that doesn't mean you would HAVE to move to C++, that's up to you. You can do in C everything, you can do in C++. And actually, I found C to suit my needs so well, that I never really thought of moving towards C++. I nowadays write C-code at work aswell.
At first it might be best to not go further than doing some simple shell programs (another thing you did right imho :-)), but then you should ask yourself what you want to do really?
Is it programs? Is it games? Is it something else?
And especially with games, you must decide what kind of games you would want to do. 3D (3D accelerated or not), 2D (system window or fullscreen, AGA or gfx-cards-only)
Personally I started using SDL and OpenGL. Both of them make many things so much easier. To be honest, I was surprised how easy it was to do simple 3D graphics with OpenGL. SDL is a bit more complex, but also makes many things (such as graphics, sounds, input handling etc.) much easier. Of course the bad news is that with both you can count out all <=AGA users but if you don't, you will be seriously restricting what you can do :-)
MorphOS has quite good SDL and OpenGL support, and I think OS4's support isn't probably all that bad either (currently there's no shared SDL library, and OpenGL isn't as "complete" as MorphOS equivalent, but it's just a matter of learning what functions to (not) use).Classic amiga version of SDL is not that good, but works. OpenGL, however, is about the same as currently on OS4, but obviously requires 3D card for any serious use (as it does on ANY system anyway)
Oh, did I mention that both SDL and OpenGL are available on many (mainstream and non-mainstream) platforms? :-)
If you are interested, I can paste links to some tutorials I found helpful.
Oh, and welcome here, I think I forgot to say that in the other thread :-)
-
Jupp3:
"You can do in C everything, you can do in C++"
I plan to learn c++ once I have a better understanding of c. At least I was told this was a good idea :)
-
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";
-
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?
-
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.
-
@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 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:
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.
-
@Cymric
Some compilers can warn about this type of potentially dangerous assignment but alas gcc isn't really one of them.
-
@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:
-
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.
-
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".
-
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 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.
-
@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.
-
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 ;-)
-
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 :-)
-
@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.
-
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:
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 (https://sourceforge.net/projects/bstring/). 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.
-
@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 ;-)
-
Guys! Can we save this for later? Im only just looking at functions :lol:
-
Hi!
So Ive spent time looking at functions in C since I last posted here. So far so good in that I understand the purpose of functions and Im not particularly struggling with the syntax.
I do have some basic questions and one not so basic question though (which is getting a bit ahead of myself too).
Question 1
Is there a way that a function can return more than one value simultaneously? Its obvious from the function definition syntax so far that you return a single value or nothing at all (void).
However if I can imagine times when returning multiple values together might be useful Im sure other people can and have found ways.
So far I can only think of returning an array or structure or modifying the parameters if you "pass by reference". An array is presumably only any good if you have to return multiple values that are the same "type", right?
Question 2
Can you actually return an array in this way or is it only by reference too? If that is the case wouldnt the array that the reference represents be destroyed when the function returns?
Ive not really looked at structures yet but I understand that they are basically made by putting together more existing types so you could make one that represents the multiple values you want to return. So, would that be a valid solution?
I looked at the other idea using the "pass by reference" idea and I know that this involves pointers and is therefore a likely place to make errors if Im not careful. I dont really want to do that yet even though I am looking at them but I noticed something weird.
The book I have says that normal variables are "passed by value" so you get a copy of them that you are free to alter. It also says that arrays are always "passed by reference" so you get the actual array and not a copy.
I am aware that the array syntax is basically another way of representing a pointer so that kind of makes sense really. I can imagine that this makes things faster compared to copying an array which might be very large.
What I found odd was that structures can be passed by value as well as reference. Why is that? A structure can contain a lot of variables and I imagine theres no reason you couldnt even have an array inside one so a structure could be as big as any array. So...
Question 3
Is there some important reason that structures can be passed by value to a function? When might you do something like that?
-
1. Returning multiple parameters in C requires passing a structure by pointer. And yes, an array is only good when passing values of the same type.
2. AFAIK structures cannot be passed by value and must be passed by reference unless C++ has some feature for creating structures/classes on the stack. It's not recommended to stuff the stack with lots of parameter data on the Amiga since the Amiga has a fixed stack space for each program.
Arrays are stored in memory as pointers so they are always passed by pointer. (When using the word "reference" you are referring to a C++/Java term that doesn't strictly apply to C.)
3. I'm not sure why you would want to waste the stack space in doing so. Normally structures are dynamically allocated with malloc() and passed by pointer to the appropriate function.
Oh, and by the way, you can embed arrays in structures if you like.
-
@mel_zoom
With regard to Q3, the only reason I can think of, for passing structures by value to a function would be if the function required a local copy of the data. That would be the case if the function had to modify the data during processing but wasn't allowed to modify the original copy belonging to whatever code called that function.
I have never had to pass a structure by value, ever. Doing so will just slow the program down, particularly if it's a big structure (e.g., contains a large fixed-size array) or that function gets called really often.
Hans
-
samuraicrow:
"AFAIK structures cannot be passed by value and must be passed by reference"
Well, I was looking at this already and have written a test program that works. Did I compile this wrong?
gcc -Wall testbyval.c -o testbyval
The code is
/* test passing structures by value - why does this work? */
#include
struct coord {
int x;
int y;
};
struct coord testbyvalue(struct coord o)
{
o.x++;
o.y++;
return o;
}
int main(void)
{
struct coord c1 = {1,2};
struct coord c2 = testbyvalue(c1);
printf("c1 = {%d,%d}\nc2 = {%d,%d}\n}", c1.x, c1.y, c2.x, c2.y);
return 0;
}
-
hans:
I understand that and I can see why arrays are "by reference" but why are structures allowed to be by value? Especially as they can contain an array even?
-
mel_zoom wrote:
samuraicrow:
"AFAIK structures cannot be passed by value and must be passed by reference"
Well, I was looking at this already and have written a test program that works. Did I compile this wrong?
You passed the structure on the stack instead of passing a pointer to it, and that is perfectly legal and valid. Most of the time we try to avoid this, especially in tight loops as building up and breaking down the stack behind the scenes is slower than just passing a pointer.
It is refreshing to see somebody express a desire to learn C and actually follow through. Even better is that you are making real effort to actually learn the language. In a year you will be telling everybody else how it's done :-)
-
Mel,
Even if a structure contains an array, the value within the structure representing the array is a pointer.
ps,
you answered your own questions in asking them for the most part
but remember, I don't know anything so don't believe anything I tell you
-
@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*
-
mel_zoom wrote:
hans:
I understand that and I can see why arrays are "by reference" but why are structures allowed to be by value? Especially as they can contain an array even?
Because a structure is seen as a data-type whereas an array is not. An array is a method of addressing a set of data of the same type. It's a quirk of the language.
BTW, I think that lou_dias is wrong about arrays in structures. A fixed-length array in a structure is the data itself, not a pointer to the array. Ah, I see that Karlos has already commented on that as I was writing this.
Hans
-
@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.
-
I'm always so wary about posting my code comments as I do this for work but always screw up when not in front of a compiler! Also I've been coding in C++ for the last couple of years and my C isn't strictly ANSI compliant anymore ... end disclaimer there :-D here goes.
1) A function can only "return" a single item. However that item can be a composite such as "struct", a pointer to other information, a reference to another item that does exist or a value.
This is where I might screw up the C vs C++ syntax btw. You don't need to pass in pointers to a function to change their value instead you can pass by reference.
for example:
// you could package all of your return values up like this.
typedef struct compositeItem{
float theHamster;
int downTheStream;
int unrelatedGubbins;
};
//and then your function would return like this.
compositeItem someDumbFunc()
{
compositeItem bodge;
//do funky things that fill compositeItem here
return bodge;
}
That would be one really bad way of doing it :-D instead you can pass by pointer or by reference.
void SonOfDumbFuncPointer( compositeItem *pCompItem, int *pVal )
{
// dereference the pointer to access the values location
(*pCompItem).theHamster = 0.0f;
(*pCompItem).downTheStream = *pVal;
(*pCompItem).unrelatedGubbins = *pVal;
++(*pVal);
}
void SonOfDumbFuncRef( compositeItem &rCompItem, int &rVal )
{
rCompitem.theHamster = 0.0f;
rCompitem.downTheStream = rVal;
rCompitem.unrelatedGubbins = rVal;
++rVal;
}
2) Arrays and pointers are, well ok they're not something to be shied away from in C or there's no point learning the language. You're correct in that the elements of an arrays can only be of one "type". That type can be made of either the language defined base types or your own.
See here for a reasonable explanation. Actually I could have skipped all of the above if I'd thought of this sooner :idea: Passing Parameters (http://www.cs.wisc.edu/~hasti/cs368/CppTutorial/NOTES/PARAMS.html#ref)
3) You might pass a structure to erm... I dunno, serialise it for lobbing over a network? No, I dunno. If I pass a structure I usually pass by reference or pointer and make it "const" if I don't want it to be modified. I'm sure that there's some really awesome and intelligent reason for passing a structure by value, that... y'know, someone that knows and will seem obvious once they mention it :-D
Hope that didn't confuse things more.
Andy
-
@AJCopeland
Any reason you prefer (*pCompItem).member over pCompItem->member ?
-
Hans_ wrote:
It's a quirk of the language.
It's these quirks that make it not a good language for beginners. Maybe if she ever learns a second language (C++ doesn't count), then she'll see the light at the end of the tunnel. C is a language with few rules. How do you write structured code when the language has no uniform structure within it's design. C is a language designed for low-memory machines because that's all they had when it was designed. All these "quirks" are just hacks someone added to the compiler at the time because of memory constraints and over time "became part of the language". C is a hack to not have to write assembly.
BTW, I think that lou_dias is wrong about arrays in structures. A fixed-length array in a structure is the data itself, not a pointer to the array. Ah, I see that Karlos has already commented on that as I was writing this.
Hans
So if the "rule" is arrays are passed by reference...why wouldn't an array within a structure not be a reference as well? Oh, I forgot, we are talking about C...but anyway, Karlos and YOU assumed I was responding to her "code" when I was actually responding to her prior set of several questions. I guess I should have quoted her. C`est la vie. (and no, that doesn't say "C is the life")
-
@Karlos
For modifying things I usually manually dereference the root of a pointer hierarchy but for nested pointers I won't bother.
So for example:
(*ptr).myNestedStruct->ptrWithinStruct = NULL;
is as valid as:
ptr->myNestedStruct->ptrWithinStruct = NULL;
but... I just like it really because I see right at the start of the line what I'm doing. One of the guys I'm working with hates me doing it so I've done it less for this current project.
of course that should really have been:
assert(NULL!=ptr);
(*prt).myNestedStruct->ptrWithinStruct = NULL; :-o
-
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.
-
Only use casts whenever they are absolutely needed.
And speaking of structures and stuff, ive got a question for the gurus.
I often have things in structures that I would like to dump to file and retrieve later. I usually take the sizeof the struct and copy every byte to file, and then later read every byte and copy it into memory and refrence the struct. It is my understanding that one can only be assured of the memory location of the first member in the struct as the optimiser may pad the struct to fit in the pipeline more efficiently. This does not seem to be a problem in practice, when the application is only running on one processor type, but I think this leads to problems passing files between programs compiled on different architectures.
One obvious solution is to hit every member in the struct and write to file, then read back and repack the struct at a later time. This is kind of a pain. Is there a painless way to correctly read and write a struct to a file in a portable manner?
-
@Koaftder
For properly portable code, I cannot stress this enough. For file IO, always write code that marshalls your binary data properly when loading and saving if you want to ensure it can be loaded on another machine. Write functions that know how to write your structures to a file stream and ones that know how to read them. Doens't need to be text based (and shouldn't be really for binary data unless you want it rendered human readable).
When performing the specific IO, you sould also consider saving blocks of "same sized" data (eg a bunch of 16-bit words) together and not mix them up with IO on elements of other sizes. This only matters if you plan to ever load the data on a version of the code compiled with a different endian representaion, however, in which case you need to know how big each binary element is in case you need to byteswap any of it.
The cost of doing this is totally mitigated by the performance hit IO operations tend to give anyway so it's rarely, if ever, perceptably slower.
Simply dumping structures is easy for quick stuff that doesnt need to be portable. Your structures may have holes in them or not, depending on packing but as those holes never contain meaningful data anyway it doens't matter except in space waste terms. Simply reordering your structure layout to put all the same-sized member elements together, largest first, eliminates this anyway.
Of course, if you do reorder your structures in this fashion, the idea of saving their members as blocks of same sized data within your functions becomes that much simpler too ;-)
-
@lou_dias
I've heard people describe C as a better assembler, but that doesn't make it a poor language to learn. As for imposed structure, well, I dislike imposed structure and I don't think that it teaches you to program well.
I've blown my own foot off in C more times than I'd like to imagine (C++ will let you take you're whole leg, and re-use the bullet :-D), but I think that learning how to write code so I'd avoid doing that again was a valuable lesson in itself.
You write structured code in the way that you present information, and by hiding functions in ".c" files so they only have local scope.
You preserve the intention of functions by enforcing "const" correctness, and by programming by contract. I.e. You assert that something is true at the beginning (You're input data is within ranges you expect and is valid) and that it has changed within the expected way within the function you've written at the end.
You can create libraries which hide the implementation of features you need throughout a program without giving others the ability to modify the underlying code, at least not without accessing that libraries source code directly or building their own.
Now that should teach you to structure code. By structure I mean that you'll make a conscious decision to implement things in a particular way and in a methodical manor as opposed to other languages where you implement things in a certain way... because it's the only way that the language will let you.
Andy
-
@AJCopland
By structure I mean that you'll make a conscious decision to implement things in a particular way and in a methodical manor as opposed to other languages where you implement things in a certain way... because it's the only way that the language will let you.
But other languages have 1 clear way of doing every certain thing. As long as these other languages give you all the functionality you need, why not use them with the saftey on rather than C/C++ with is playing with loaded guns and the safety(s) off.
Here we have a new student to programming and you give her the loaded gun right away. That can/will lead to frustration. Bad descision. What is her "need" to learn C? Certainly, other languages could speed up her "learning to program" process. Learning these other languages could then speed up her subsequent "Learning To Program In C" process.
-
@Karlos, thanks for the tips man, it's usefull for me and i'm sure it's good review for others as well. For the very few projects I do that require portability, ive hit every member in the struct and converted to network byte order and vice versa. It's a pain in the butt, especially when you have a project with a lot of different data sets. I mostly write stuff for the 8051 and use keil, which doesnt seem to do strange things with structs, but I hate my self every time I IO a struct raw....
Lately I have been messing around more with C++ on windows with MFC. I'm not a c++ guy yet but I am learning. I have seen many examples of people serializing classes to file. Especially CString classes and some of the linked list classes CList, etc. Does c++ help in serializing data in a portable manner? If i declare a class with several structs in it, will a c++ approach help make it easier to serialise to file in a portable manner?
I guess my question sounds kind of dumb, but I am wondering if doing things c++ manner can help make life easier in passing data around in files between the app compiled on different architectures. I'm not a big fan of the bloated XML libs that people bolt on to their apps. I see the usefullness of it, but XMl seems like a waste unless you need massive compatability between apps written in different languages.
-
lou_dias wrote:
But other languages have 1 clear way of doing every certain thing. As long as these other languages give you all the functionality you need, why not use them with the saftey on rather than C/C++ with is playing with loaded guns and the safety(s) off.
.Net framework has 100 ways to do the same thing. Which one is the best way? Ive written several apps in VB.Net, don't get me wrong, I like it. The OOP is actually nice in vb now, but still, writing to file or defining a bitmap to draw on the screen or talking with sockets have dozens of different ways to go about it. The VB and c# forums are chock full of guys bickering about the "proper" way to go about doing mundane things like every other language.
If a language was not Touring capable, it would be almost useless except for very specific things. You can do anything in VB/Perl/PHP/Python/Forth/Fortran/Befunge/Conrads game of life/ etc, but C/C++ gives the programmer the ultimate flexability to do anything with the absolute most efficency. 99 out of 100 programmers won't beat the C compiler when writing an algorithm in assembler.
-
@koaftder:
Regard MFC serialization, it is the *framework* (MFC framework) that helps you in serialization work, providing a pre-built infrastructure for serialization.
So you can simply add a Serialize() virtual method to your custom class (deriving it from CObject), and simply use operators << and >> for serialization.
This can be done recursively, also for classes containing structures, and for structures containing nested structures, etc.
(The important thing is that the object is "serializable", i.e. it must provide a Serialize() method, etc.)
This is not possible in C because C does not offer operator-overloading and virtual functions and polymorphism and late-binding at the level of C++ (even if these things may be done also in C, but at the expense of writing more code).
However, C++ has not built-in serialization mechanism. It is the framework you use (e.g. MFC) that can provide one (and if you follow the framework rules, you can have serialization for your own classes fairly simply).
Maybe C++ Boost libraries offer another serialization mechanism (more standard than the MFC-specific one).
-
C is a language designed for low-memory machines because that's all they had when it was designed.
That´s not strictly true Lou, C is a language designed for control freaks.
[Purely my opinion]
Programmers that are not control freaks, are not very good programmers.
[/Purely my opinion]
ps I use a RAD tool you will never have heard of, and it is far more abstracted than VB.NET even. I love it, and very rarely use anything else for commercial work but I still say C is God´s own language. ;-)
C++ is just a ¨bida¨ Karlos! :-P
-
@Koaftder
There's nothing "specific" in the STL or anything for data serialization, unless you count using the C++ stream classes and implementing the appropriate operator<<() and operator>>() for your classes. Said streams are generally character based, however.
What I did was to create classes something like this (simplifed here as the full system was a complete binary safe OOP storage engine)
class OutputStream {
private:
// write the current architectures' signature
// into the file header
bool writeHeader();
public:
bool open(const char* fileName);
void close();
size_t write8(const void* src, size_t num);
size_t write16(const void* src, size_t num);
size_t write32(const void* src, size_t num);
size_t write64(const void* src, size_t num);
//...
};
class InputStream {
private:
bool swapEndian;
// read the architecture signature
// from the file header
bool readHeader();
// normal readers
size_t read8Norm(void* dst, size_t num);
size_t read16Norm(void* dst, size_t num);
size_t read32Norm(void* dst, size_t num);
size_t read64Norm(void* dst, size_t num);
// readers with endian conversion
size_t read16Swap(void* dst, size_t num);
size_t read32Swap(void* dst, size_t num);
size_t read64Swap(void* dst, size_t num);
public:
bool open(const char* fileName);
void close();
size_t read8(void* dst, size_t num);
size_t read16(void* dst, size_t num);
size_t read32(void* dst, size_t num);
size_t read64(void* dst, size_t num);
//...
};
// typical implementation
inline size_t InputStream::read32(void* dst, size_t num)
{
return swapEndian ? read32Swap(dst, num) : read32Norm(dst, num);
}
class StreamStorable {
public:
virtual bool write(OutputStream& s) = 0;
virtual bool read(InpputStream& s) = 0;
// ensure a proper destructor is called if we
// ever delete a StreamStorable*
virtual ~StreamStorable() {}
}
The idea here is that the OutputStream has methods for writing 8/16/32/64 bit data. It always writes a header to the file first, consisting only of a few bytes of data that include information about the current machines architecture, the type of file data and so on.
The InputStream class, upon opening such a file, checks to see if the written signature is endian compatible with the current machine or not and sets the swapEndian flag accordingly, which in turn dictates which multibyte IO routines are used for reading.
Last but not least, objects that needed to be saved to / read from said streams would implement the StreamStorable interface, thus:
class Something : public StreamStorable {
private:
sint32 foo[2];
sint16 x;
public:
bool write(OutputStream& s) {
return (s.write32(foo,2)==2 && s.write16(&x,1)==1)
}
bool read(InputStream& s) {
return (s.read32(foo,2)==2 && s.read16(&x,1)==1)
}
};
//....
Something blah();
OutputStream out("ram:foo.dat");
blah.write(out);
out.close();
This is actually a total oversimplification of what was really done since the actual Storable interface would write a header of its own and store a small amount of other metadata, including the total size, inclusive of anything dynamically allocated, so that the read functions could completely reconstruct an object that migh have dynamically allocated data in them. However, I hope it gets the general idea across.
-
CannonFodder wrote:
C++ is just a ¨bida¨ Karlos! :-P
Yes, a bloody good one too! All the control (and more) you get in C with a thousand times the finesse.
-
koaftder wrote:
99 out of 100 programmers won't beat the C compiler when writing an algorithm in assembler.
If you have a good understanding of your target you can usually optimize a few functions in assembler and manage it better than the compiler. However, you sould only attempt this when you have exhausted optimizing the C/C++ code itself and it still isn't fast enough.
It should always be an aggressive-performance-optimization driven last resort, however and furthermore you should never throw your original code away (conditionally compile it out or have a different fork without asm in it) - you never know when you might have to port it to another system :-)
-
Karlos wrote:
CannonFodder wrote:
C++ is just a ¨bida¨ Karlos! :-P
Yes, a bloody good one too! All the control (and more) you get in C with a thousand times the finesse.
C++ is the Shia to Islam´s C? ;-)
/me runs very very fast!!
-
@AJCopland
Now that should teach you to structure code. By structure I mean that you'll make a conscious decision to implement things in a particular way and in a methodical manor as opposed to other languages where you implement things in a certain way... because it's the only way that the language will let you.
Amen to that (and the rest of the message). Well put.
-
Well yeah, it's quite pointless to hand optimize bubblesort in assembler, when you could have just replaced the algorithm with quick- or mergesort. ;-)
-
@Karlos
There's nothing "specific" in the STL or anything for data serialization
If we somehow consider Boost an STL++ (and in fact Boost is a widely accepted standard in C++ programmers community), you may find this useful:
http://www.boost.org/libs/serialization/doc/index.html
class StreamStorable {
public:
virtual bool write(OutputStream& s) = 0;
virtual bool read(InpputStream& s) = 0;
}
Is this not complete right?
Defining an interface class without a virtual destructor is an invitation to disasters :-)
-
No, it's not complete as I was focusing on the actual serialization mechanism and not polymorphism in general. Yes the actual class has a virtual destructor. I'll add it to th4e example for completeness ;-)
-
@lou_dias
Well I didn't give her the idea to use C but I'm sure that Mel has good reason :-) Indeed it matches my own viewpoint that C is a good starting language though.
The trouble with learning in some languages are that they force you to think in a certain manor. That's partly because it is the only way that language can do something. C has this to some degree as well (it is still a language and so that's unavoidable) but if you want to go down a particular route it'll pretty much let you and assume that you know what you're doing. I think that's a good thing because it means you have to plan, or at least think, about what it is that you're trying to do.
Going from a relatively unstructured language like C that lets you do some incredibly stupid things and just assumes that you know what you're doing, to another language that is more restrictive can be very frustrating because of the feeling that you're being locked into it's way of working. Conversely however, going from a more restrictive language to C can not only be daunting because of that freedom, it can also be unproductive because you won't know how it can be used and you'll end up using in the manor of the more restrictive language you came from.
This is not to say that C is the greatest language ever or anything. It has pitfalls and problems. I think most of my bad habits came from years of hacking in C before I learnt C++, but it's a very widely used base. The knowledge that Mel gains from learning C will be transferable to almost any other mainstream (where mainstream means a language you're likely to encounter in business) language Higher or Lower level and to any platform which is something that cannot be said for anything else, even C++ compilers aren't available on/for absolutely everything.
It looks like the place the Mel works at uses C++ so getting a grounding C first then moving onto C++ before you can develop some nasty habits might be my only real advice from all this btw :-D
Damn I'm at work not meant to be replying on here!
Andy
-
The knowledge that Mel gains from learning C will be transferable to almost any other mainstream (where mainstream means a language you're likely to encounter in business)
That´s not strictly true in every case, but is a decent enough generalization. ;-)
-
CannonFodder wrote:
C++ is the Shia to Islam´s C? ;-)
/me runs very very fast!!
No. C++ was the final revelation that perfected the language. C itself is more like your Torah/Gospel :-P
/surreal
-
Karlos wrote:
CannonFodder wrote:
C++ is the Shia to Islam´s C? ;-)
/me runs very very fast!!
No. C++ was the final revelation that perfected the language. C itself is more like your Torah/Gospel :-P
/surreal
Touche!
So Objective-C is more the Shia then? Or would that be AmigaE? ;-)
-
I've heard people describe C as a better assembler, but that doesn't make it a poor language to learn.
Quite the opposite. This is why it is an excellent language to learn as you gain true insight into the low level behaviour of the machine that higher level abstractions deny you.
I've never met a skilled C/C++ developer yet that writes inefficient or sloppy code regardless of the language they are using. In my experience, the same cannot be said for those that come purely from higher level language backgrounds.
Languages that require you as the developer to take ownership of efficiency and resource management tend to be the best to learn. Languages that take over resource management are good once you understand how said management works.
I regularly see things like this in java code:
while (isNotDone()) {
Something blah = new Something();
// ...
blah.doSomeOperationThatDoesntAlterObjectItself();
// ...
}
in places where
Something blah = new Something();
while (isNotDone()) {
// ...
blah.doSomeOperationThatDoesntAlterObjectItself();
// ...
}
would perform the exactly the same job. The developer is utterly oblivious to the cost of repeatedly constructing an object that gets used in a non-destructive way once. Instead, all they know is "best to keep variables as local as possible" because they have not learned anything about resource management since they have never used a language where they are required to manage resources themselves.
From a high level, their code is well structured, very OOP, properly implementing known patterns where they apply but the physical implementation of their code is full of inefficient resource clobbering examples like those above.
-
Objective-C is more like Sikhism, where two syntactically unrelated languages were merged to create a new one...
-
Karlos wrote:
CannonFodder wrote:
C++ is the Shia to Islam´s C? ;-)
/me runs very very fast!!
No. C++ was the final revelation that perfected the language. C itself is more like your Torah/Gospel :-P
/surreal
That's funny, I learned JAVA for a class and I would say that JAVA is the final revelation that perfected C++.
@koaftdr
JAVA offers data serialization built-in.
PS,
We are way off topic for Mel.
-
I would say that JAVA is the final revelation that perfected C++.
Complete and utter bilge. Some java shortcomings from the POV of a C++ developer:
Efficient concrete types cannot be realistically implemented as all calls are virtual, all objects are polymorphic.
Inheritence is singular and public level only.
No real control over object destruction.
No operator overloading. Except for the inbuilt StringBuffer which has an implementation of "+", thus destroying their own argument against allowing it.
I used to say "full support for generic programming (templates)" but Java has added generics, which use something very similar to C++ template syntax. Which they used to criticise very heavily ;-)
-
@Karlos
AArgh, yes I saw something just like this the other day in a render loop of all places :crazy: I was helping out a friend who's at Uni' with her group project trying to figure out why it ran so slow. The other problem is that because they're so used to Java they expect everything to be garbage collected auto-magically and were leaking almost a megabyte a frame!
That's not a comment against Java which is fine in my book, but does quite nicely demonstrate what I meant about going from a higher level language which has taught you one thing to a lower level language which doesn't support it :-D
Andy
-
lou_dias:
"We are way off topic for Mel."
Yes, it seemed to start with talk of ".net" :-P
"Here we have a new student to programming and you give her the loaded gun right away. That can/will lead to frustration. Bad descision. What is her "need" to learn C? Certainly, other languages could speed up her "learning to program" process. Learning these other languages could then speed up her subsequent "Learning To Program In C" process."
So far the only frustration is the language-war sideshow ;-) Im not finding C itself particularly difficult to comprehend for now. Why should I learn something else in order to qualify for learning C?
I dont mind the C++ chatter though I dont plan on looking into that for some time yet.
-
lou_dias:
"It's these quirks that make it not a good language for beginners. Maybe if she ever learns a second language (C++ doesn't count), then she'll see the light at the end of the tunnel."
Hmmm.
You seem to think that I am lost in a dark tunnel. Im not - C seems quite straightforward so far. Whats this "light" am I supposed to C? :-P
" C is a language with few rules. How do you write structured code when the language has no uniform structure within it's design. "
It seems quite structured to me. So far I have learned:
C provides very simple "types" that correspond to those typically used by the CPU directly. Anything more complicated requires you to define a structure that is composed of these types (and maybe other structures). I can already see how this provides a good "building up" principle for dealing with data in a program.
C code is structured into blocks that you surround in braces. Any variables you define inside a block can only be seen in that block and any blocks inside it and so on.
The highest level block of code is a function. You cant just write code anywhere. Therefore (unless I got this very wrong) all code in C lives only in functions wether they are built into a library or you have written them yourself.
The first function in your program is main(). This is what the system calls when your program is run and the value returned goes back to the system as an indicator of what happened. It was quite interesting to see what happened when I returned 5, 10 and so on and checked the shell's return code - you can actually see it.
My first program that used the full "main()" definition was this:
/* set the returncode for the amiga shell */
#include
#include
int main(int argn, char** argv)
{
int r = 0;
if (argn>1) {
r = atoi(argv[1]);
}
printf("Setting return code to %d...\n",r);
return r;
}
Ok, it isnt exactly the most useful thing but you can actually see how the shell and program interact which I thought was educational :-)
C is not very "wordy" and relies more on an equation-like written form. Which is good as far as Im concerned as it is easier to see at a glance what a block of code does when it isnt cluttered up with lots of keywords that distract you from what the code itself is actually is saying.
"C is a language designed for low-memory machines because that's all they had when it was designed. All these "quirks" are just hacks someone added to the compiler at the time because of memory constraints and over time "became part of the language". C is a hack to not have to write assembly."
According to the K&R book C was created for and on unix systems. I dont think they were regarded as "low-memory" in their day - after all the compiler itself uses quite a lot just to compile a program!
All the "low-memory" systems (home computers typically) I can remember from childhood used BASIC of some sort or other.
-
Pardon me for jumping in here...
Don't mind too much about the "language wars"...but I hope you can take away one point from it all. Once you have C and C++ well in hand, take some time to learn a completely different sort of language, one that pushes you to think in a different direction than C does. Maybe one with strict typing like Pascal, or an interpreted one like Perl. That will help you to separate specific language quirks from sound general programming principles.
Your take on C seems a lot like my wife's -- she regards the code as self-documenting, and considers comments to be a distraction. I have a different view, probably colored by my experience with IBM System/370 Assembler. I'd much rather read comments, to know what the programmer meant to do, than play computer and try to execute the code in my head.
Interestingly enough, one of my lame justifications for getting an Amiga was to get more comfortable with C, as I hope to get involved with some Linux or other kernel programming. Hacking around with Amiga programming seemed much more interesting than the many other options I have.
-Ed-
-
Your take on C seems a lot like my wife's -- she regards the code as self-documenting, and considers comments to be a distraction. I have a different view, probably colored by my experience with IBM System/370 Assembler. I'd much rather read comments, to know what the programmer meant to do, than play computer and try to execute the code in my head.
I gotta agree with your wife there. The point is, you can write code that is self-documenting without requiring you to "play computer".
C is a language, English is a language too, but C is better at concisely expressing what in English would require verbose sentences.
/* Defines an integer variable named 'a' and assigns it the value 2 */
int a = 2;
Yes, it's quite an extreme example, but shows the point.
The only things that require comments are algorithms, but the more self-documenting code you are able to write, the better.
-
falemagn wrote:
Your take on C seems a lot like my wife's -- she regards the code as self-documenting, and considers comments to be a distraction. I have a different view, probably colored by my experience with IBM System/370 Assembler. I'd much rather read comments, to know what the programmer meant to do, than play computer and try to execute the code in my head.
I gotta agree with your wife there. The point is, you can write code that is self-documenting without requiring you to "play computer".
C is a language, English is a language too, but C is better at concisely expressing what in English would require verbose sentences.
/* Defines an integer variable named 'a' and assigns it the value 2 */
int a = 2;
Yes, it's quite an extreme example, but shows the point.
The only things that require comments are algorithms, but the more self-documenting code you are able to write, the better.
IMNSHO comments should clearly (and only) state the ¨why¨, the code itself should clearly state the ¨what¨ and the ¨how¨.
YMMV :-)
-
The last thing I programmed was a stupid DOS "Hello world" type thing in Turbo Pascal on PCTask 3.
I'd like to learn C for the Amiga too but this thread is not doing beginners any good.
Maybe I should RTFM.
:-D
EDIT:
· Mel: Are you Karlos' secretary?
· Why does your Mazda link take me to a mammogram page? :inquisitive:
Answers on a postcard!
-
@Hyperspeed:
I agree that this thread might not be the best starting place. :-) Here's a quick and easy set of tutorials that I found helpful:
http://einstein.drexel.edu/courses/CompPhys/General/C_basics/c_tutorial.html
It's not Amiga-specific, but enough to hopefully give a good flavor of the language.
-Ed-
-
ethierbach: Ahhh, now that's more like it. C for the mentally challenged!
:-D
I wonder what happened to Amiga-E, there was an article on it in Amiga Format once and Iconian was alledgedly programmed in E.
To be able to code Workbench apps like this would be really cool but they'd have to be super lean.
I long for the day when I can code in Assembly too; those apps/games always seem so damn fast.
EDIT:
I suppose GoldEd would be good for writing code on Amiga because it allows you to change the colours of the text. You'd be able to save work and have a mate highlight in red the crap that needs refining...
;-)
-
@falemagn
Yeesh, yuck and no! :-x
That kinda code is itself a comment as it's a simple assignment, but what are you going to use it for and what is the number 2 representing? Bad commenting.
/* integer variable 'aIdx' is used in the following loop to iterate through mini-game actors updating them. Has initial value of 2 because first 2 entries are player 1 & player 2 */
int aIdx = 2;
for( ; aIdx < numMiniGameActors ; ++aIdx )
{
MiniGameActors[aIdx]->update(deltaTime);
}
That is a mildly spurious example, but it IS still a more valid example. Someone else will read your code, probably you, in 6 months time and be glad that you documented why you used the value 2. Also renamed 'a' to 'aIdx' to more clearly indicate that it is used as an index.
You're never writing code just for yourself, you're writing code for you in 6 months time as well. Not only that but it's good practice to comment why you did something so that when you are working on a group project you don't forget to do it for others who might be less experienced than you. (I see this lack of *why* comments everyday on the current project, it slows down work and is poor coding style).
Andy
-
AJCopland wrote:
@falemagn
Yeesh, yuck and no! :-x
That kinda code is itself a comment as it's a simple assignment,
Wasn't that the point? Self-documenting code, indeed. You said it yourself. :-)
And yes, I admitted it was an extreme case, just to show the point. That doesn't mean that other, not so extreme cases, don't exist. In fact, read on...
but what are you going to use it for and what is the number 2 representing? Bad commenting.
That was all that had to be commented, an assignment. 2 represents 2, that's all. If I wanted 2 to mean something else than just 2, I wouldn't have used 2, but rather a named constant: again, self-documenting code. In fact, read on...
/* integer variable 'aIdx' is used in the following loop to
iterate through mini-game actors updating them. Has initial
value of 2 because first 2 entries are player 1 & player 2
*/
int aIdx = 2;
for( ; aIdx < numMiniGameActors ; ++aIdx )
{
MiniGameActors[aIdx]->update(deltaTime);
}
That is a mildly spurious example, but it IS still a more valid example. Someone else will read your code, probably you, in 6 months time and be glad that you documented why you used the value 2. Also renamed 'a' to 'aIdx' to more clearly indicate that it is used as an index.
Problem is, commenting is superfluous in the above code.
1) "integer variable 'aIdx'" - the name of the variable is clear as it's clear it's an integer, no need to spell those in English.
2) "is used in the following loop to iterate through mini-game actors updating them" - the fact it's a loop it's pretty self evident, the fact it's looping through mini-game actors is evident too, by the name of the MiniGameActors array that is being indexed, and the fact that those actors are being updated is also obvious, for the mere fact that the update() method is being invoked on them.
3) "Has initial value of 2 because first 2 entries are player 1 & player 2" - so then, if that's what 2 means, why not state that explicitely in the code? You could have done it like this:
enum { numPlayers = 2; }
for(int aIdx = numPlayers; aIdx < numMiniGameActors; ++aIdx)
{
MiniGameActors[aIdx]->update(deltaTime);
}
There, no need to write any comment, the code is indeed self-documenting. In fact, looking at this code for the 1st time I can say that this is a loop going through mini game actors so that they are updated taking into consideration the time elapsed since last time they were updated. There are 2 (human?) players in the game which are considered to be "actors" too, for the sake of code simplicity, but that don't need to be updated, as they are not controlled by the AI, and those 2 players are the 1st and 2nd element of the MiniGameActors array, therefore we skip them when updating the rest.
You're never writing code just for yourself, you're writing code for you in 6 months time as well. Not only that but it's good practice to comment why you did something so that when you are working on a group project you don't forget to do it for others who might be less experienced than you. (I see this lack of *why* comments everyday on the current project, it slows down work and is poor coding style).
I'm a professional programmer, highly rewarded for my work too, been programming since I was 6. Don't assume I don't know what I'm talking about, thanks. ;-)
-
@falemagn
I didn't mean to sound like you don't know what you're talking about, I'm merely at work and brevity matters when I'm replying. Sorry.
No my example wasn't ideal because I literally copied your example and expanded on it ever so slightly. However as you say you've been coding since you were 6. We have coders who have just graduated and hadn't touched a compiler until they hit Uni'.
Code wholly without comments won't do. We have a good set of guidelines here about what to comment and why (comment the purpose and usage for a class but not how for example), but I find your guidance that comments are pointless doesn't reflect what the less experienced coders have to deal with. That's why I suggest that over-commenting is better than under commenting.
Over-comment and everyone gets the bloody idea whether they want to or not. Under-comment and there's a chance that someone won't when they really really need to.
Andy
-
Question 1
Is there a way that a function can return more than one value simultaneously? Its obvious from the function definition syntax so far that you return a single value or nothing at all (void).
I read the thread quite quickly, and I'm not sure if this was already mentioned. At least there were some talks about pointers to structs, which are quite widely used.
Anyway, you can give function pointers to a variable.
For example:
void ChangeXandY(int * x, int * y, int xdiff, int ydiff)
{
*x+=xdiff;
*y+=ydiff;
}
int main(void)
{
int x=4;
int y=5;
ChangeXandY(&x, &y, 1, 2);
return x+y;
}
Doesn't make much sense, but demonstrates one way to do what you asked. Might not be the best way to achieve ">1 return values", but it's good-to-know, not least becouse it's used often in f.ex. OpenGL and SDL.
Also if you use pointer as argument but don't want to change the data, you can add "const" so that the compiler will warn you if you try to do that ;-)
With struct, you can just do like this:
void somefunc(struct somestruct * data)
{
int x;
x=data->intvalue;
}
Oh, if you end up using structs a lot (and even if you don't), it's a good idea to learn typedef early on, that would have saved me lots of code editing later on :-)
You can do f.ex.
typedef struct
{
float x;
float y;
float z;
}Point3D;
And later in code, instead of doing something like this:
struct Point3D point;
you can do this:
Point3D point;
At least I find it more "clean" way to "say the same thing in C code"
-
Structure Point
Dim X as Double
Dim Y as Double
Dim Z as Double
Dim Name as String
End Structure
Sub Main()
Dim Position as Point
Dim Speed as Double = 1.0
Position = SetInitialPosition("Orbit 1")
For Angle as Integer = 0 to 359 'Default stepping is 1
Position = Plot(Position, Speed, Angle)
DrawIt(Position)
Next Angle
End Sub
Function SetInitialPosition(ByVal Name as String) as Point
Dim Vector as New Point
Vector.X = 1
Vector.Y = 0
Vector.Z = 0
Vector.Name = Name
Return Vector 'here you can alternately do this: SetIntitialPostion = Vector
End Function
Function Plot([b]ByVal[/b] aPoint as Point, ByVal Velocity as Double, ByVal Theta as Integer) as Point
...
End Function
The PLOT function above, the structure is passed by value as well. However, I could have written it to pass by reference like this:
Function Plot(ByRef aPoint as Point, ByVal Velocity as Double, ByVal Theta as Integer) as Point
...
End Function
This example isn't good because it alludes to designing a "game" where global variables are favored over proper programming design for the sake of speed.
Oops, wrong language! :flame:
-
Why post vb.net stuff in a thread about C? If you want to go over some vb.net stuff, why not do it in a vb.net thread? I'm game. I could use some vb.net review as I have yet to actually move over to that environment ( and there are lots of us out there ).
-
AJCopland wrote:
[...]
No my example wasn't ideal because I literally copied your example and expanded on it ever so slightly. However as you say you've been coding since you were 6. We have coders who have just graduated and hadn't touched a compiler until they hit Uni'.
But that's beside the point. The code you showed has become self-documenting once I reworked it the way I showed, can you dispute that? Your English comment was totally redundant.
Code wholly without comments won't do.
Well, the piece of code that you've shown doesn't require a comment, do you disagree?
I myself stated that there's place for comments, particularly to describe how does an algorithm function, or where the code itself isn't able to convey all the information necessary to understand why the code was written how it was written and what it does. But the occurrence of the latter situation can be reduced to a minimum by using a few simple rules:
1) give variables and functions and all other kind of symbols a meangiful name, apt at describing what that symbol is meant to do;
2) don't use literal constant numbers if those numbers have a meaning attached, use named constants instead;
3) factor your code in such a way that common patterns are implemented by using either functions or preprocessor macros with a meaningful name: the higher level your code becomes, the more explicative it gets.
We have a good set of guidelines here about what to comment and why (comment the purpose and usage for a class but not how for example), but I find your guidance that comments are pointless doesn't reflect what the less experienced coders have to deal with.
I never said that comments are pointless, nor I think they are.
That's why I suggest that over-commenting is better than under commenting.
Over-comment and everyone gets the bloody idea whether they want to or not. Under-comment and there's a chance that someone won't when they really really need to.
I gotta disagree. English is a language much more difficult than C, if you're not good at expressing yourself properly in C, I very much doubt that you're going to do a better job at English. I'm not talking about you specifically, of course, this is rather a general rule that I've come to deduce by years of experience and looking at other people's code and comments.
What's more, too many comments clutter code. I want to see the code, I've grown a sense of aestethic towards code, so much that even if code I write works, and does so well, I keep adjusting it till it looks "beautiful", in the same sense as a well written and thought out mathematical equation can be "beautiful".
Self-descriptive code makes code beautiful.
-
koaftder wrote:
Why post vb.net stuff in a thread about C? If you want to go over some vb.net stuff, why not do it in a vb.net thread? I'm game. I could use some vb.net review as I have yet to actually move over to that environment ( and there are lots of us out there ).
If you need to know anything about vb, feel free to PM me.
Well, mostly, people here talk about how C is powerful and clear(cough) and blah blah blah, self-documenting(cough cough), blah blah, well I posted some VB code for comparison. Let's leave it at that.
-
falemagn wrote:
Self-descriptive code makes code beautiful.
I agree. I know you weren't addressing me, but VB code is VERY self-descriptive. C, not so much. Please reference my code. No flames intended.
-
lou_dias wrote:
falemagn wrote:
Self-descriptive code makes code beautiful.
I agree. I know you weren't addressing me, but VB code is VERY self-descriptive. C, not so much. Please reference my code. No flames intended.
I gently refuse to comment on that in this thread. Feel free to open another thread. :-)
-
@falemagn
What's more, too many comments clutter code. I want to see the code, I've grown a sense of aestethic towards code, so much that even if code I write works, and does so well, I keep adjusting it till it looks "beautiful", in the same sense as a well written and thought out mathematical equation can be "beautiful".
Self-descriptive code makes code beautiful.
Spot on! My heart bleeds when I see badly indented or formatted code, or something that is done overly complex way while simpler and more obvious code would be possible. I want to manually recode it just to make it more pleasing to the eye (and faster to execute, but that often is the consequence of the beatification anyway).
I often spend hours reading thru code written by others and at the same time review it, but it's more like reading a novel than labouring. Occasionally I do spot a bug and fix it, but most often I just look out for neat code snippets of code or for some fresh ways to implement some particular task. Programming is constant learning, and while I've programmed for over 20 years now, I still learn new things.
This is no language thing, I did the same with assembler already.
I guess this is the definition of a geek of a sort. Oh, and sorry for the OT, again. ;-)
-
@falemagn
Ok, just so we're clear I agree with pretty much every point you've made.
The misunderstanding comes from the line:
The only things that require comments are algorithms, but the more self-documenting code you are able to write, the better.
Which in my haste this morning I totally missed. I'd personally extend that to include classes, structures, the usage of templates and a few other bits n' pieces that trip people over.
The idea of self commenting code is good, and all your points seemed valid, but having helped people through very well "self documented" code I still prefer to place comments to at least give them a secondary perspective. I also remember being a junior coder lost in "self documented" code and cursing the black heart of whoever wrote it for NOT leaving comments! So usually before a complex method I'll give a few lines description of the purpose of that method, the expected ranges and/or condition of it's inputs and expected outputs. It just helps people see what you're intention was.
I'm currently working on a project that has been outsourced to my company. The only comments in this code base are around equations in the physics library. Even though I've been doing this for a good 11 years now an undocumented interface is merely a hassle, but to someone else it's a quagmire that hinders development and can encourage lazy development practices.
Whilst C is a very precise language it isn't most of our coders "first" language. Over here that's English and so when people read my beautiful code :-D I like to tell them my purpose in writing it as well...
... plus comments give Babelfish something to work with, there's nothing worse than receiving a code base entirely with Japanese comments, variable and function names :crazy:
Andy
-
In my opinion there's far more to document what's mentioned here...
Obvious stuff, such as function input & output value descriptions and their possible limitations. What kind of values functions should NOT be used with (even if it's practically impossible to end up with such values in CURRENT project (thus no need for error checking in that project), I've sometimes just copypasted some function to new project, just to find out that it doesn't work becouse I use values slightly different than I should)
Also, I consider some kind of changelog (what was broken and when, you know :-)) code documentation
Oh and last but not least, BUGS. Sometimes you just can't find a bug (but know a workaround), maybe some API you use has some nasty bug you can't fix. Personally I sometimes keep not-so-well-working code in my project for a while before starting to fix it to a better form - Maybe the whole idea isn't as great as I though (can't know before I try it for a while), or I just lack time to fix it for time being, and leave it for later. And thanks to documentation, I have one excuse less for forgetting it :-)
-
mel_zoom wrote:
lou_dias:
"It's these quirks that make it not a good language for beginners. Maybe if she ever learns a second language (C++ doesn't count), then she'll see the light at the end of the tunnel."
Hmmm.
You seem to think that I am lost in a dark tunnel. Im not - C seems quite straightforward so far. Whats this "light" am I supposed to C? :-P
" C is a language with few rules. How do you write structured code when the language has no uniform structure within it's design. "
It seems quite structured to me.
The problems are not what you think they are, and will only surface once you begin to construct bigger programs which cover, say, more than 25 K of source code. Then you will find that the parsimonity of C can become a hindrance rather than an asset:
- there is no automated memory management, forcing you to keep meticulous tabs on what your program does with what memory---and believe me, this is much harder than it looks
- type checking is enforced by the compiler and not the language
- string handling pretty much sucks: all you have is an array and a few library functions like strcpy() and strlen()---writing code which does a lot of string processing is not fun this way
- there is no bounds checking on arrays, so you can easily do 'int a[10]; a[10]=9;' and then try to find the cause of these spurious crashes of your program
- there are no standard libraries defined by the language to do network I/O, control graphic subsystems, offer standard data structures, and so forth
- there are no facilities for threading, coroutines, and the like: this is advanced stuff, which you can happily forget about
- and a LOT more.
The picture I'm trying to paint here is that C is an exceedingly basic language offering very little programming comforts or standardisation. You must provide quite a lot of extra layers to keep your programs managable, and none of these contribute to the actual program you want to write. You require a reusable code library which does all this boring stuff so you only code this once, test it to death once so that you're sure it's rock-solid and nuke-proof, and then use it more religiously than a fundamentalist clings to his scripture. But even that is not so easy as it looks because you now face the problem of modularity---breaking up code over various separate parts---and C's approach is rather basic.
In this regard I agree with lou_dias that C might not be the best language to learn to program in. It's not that the basics are difficult or in any way 'wrong': it's that once you master the basics that you are exposed to a lot of bare machinery you can really do without. Strangely enough, books and tutorials never cover this particular aspect... :-P
-
Hyperspeed:
"Mel: Are you Karlos' secretary?"
No. Is that the only IT role you can imagine a woman working in?
"Why does your Mazda link take me to a mammogram page?"
It isnt a Mazda link, its a link to a page that generates advertising money from your visits that in turn is used to provide free mammograms for those less well off. There are several other good causes on the same site that you can click on too.
-
mel_zoom wrote:
Hyperspeed:
"Mel: Are you Karlos' secretary?"
No. Is that the only IT role you can imagine a woman working in?
"Why does your Mazda link take me to a mammogram page?"
It isnt a Mazda link, its a link to a page that generates advertising money from your visits that in turn is used to provide free mammograms for those less well off. There are several other good causes on the same site that you can click on too.
In which country?
Mammograms are free in most ¨1st world¨ countries.
-
In that case, the USA is not a 1st world country.
Healthcare costs are quite a political debate around here. :(
-
lou_dias wrote:
In that case, the USA is not a 1st world country.
Healthcare costs are quite a political debate around here. :(
This is way OT, but ¨It is un-American to have communist healthcare¨
-
lou_dias wrote:
In that case, the USA is not a 1st world country.
Healthcare costs are quite a political debate around here. :(
USA is a great country, very advanced in technology and science.
But I really can't understand why you don't have a "public" health system.
Don't you think that human health (as education, etc.) should be rights for everyone??!?
-
OT:
I am Portugues born, American raised.
I see this country with clear eyes. It has many problems that foreigners don't see and I'm not a blind loyalist like many seem to be.
The problem with this government is that politicians also have business interests. There should be a law separating the 2. That is the root of many woes. Everybody is in it for money and not for what is right.
-
- there is no automated memory management, forcing you to keep meticulous tabs on what your program does with what memory---and believe me, this is much harder than it looks
and believe me, I have done it, and it isn't THAT hard.
Actually I like it better than trying to guess what would be freed and when (Java garbage collection, for example)
- string handling pretty much sucks: all you have is an array and a few library functions like strcpy() and strlen()---writing code which does a lot of string processing is not fun this way
Weird. Last time I checked there was stuff like character searching, string searching, string compare, string copying and joining etc.
Are you sure it's the same string.h we're talking about?
Of course you might need some more "advanced" stuff in few projects you make, but you can do pretty much with those functions, and they're useful for creating your own.
While we're discussing strings, one tip:
Never do for(i=0; i- there is no bounds checking on arrays, so you can easily do 'int a[10]; a[10]=9;' and then try to find the cause of these spurious crashes of your program
Most likely becouse there isn't difference between dynamic and static memory allocations. And memory allocations is what strings are. So in some cases it would work, in some it wouldn't.
- there are no standard libraries defined by the language to do network I/O, control graphic subsystems, offer standard data structures, and so forth
Not every system is similar. Many systems don't even have any graphics abilities at all, or they differ a lot. How would you create an uniform graphics api, that can draw for example AGA planar graphics and 32bit true color graphics?
Not really a feature, but this is one thing I really like about C. It doesn't try to force you to use some certain functions for (f.ex) graphics. You can just pick one that works best for your project, or do one of your own. You can use system-dependant API (DirectX, Direct3D) or one that's cross-platform (SDL, OpenGL), the choice is yours, not the choice of the developers of the programming language, you use.
- there are no facilities for threading, coroutines, and the like: this is advanced stuff, which you can happily forget about
Just like earlier, this is highly system dependant stuff. Some systems support threading, some do not. Different threading implementations are, well, different. Some offer more options than the others, so what kind of common API would you create?
Again, C doesn't force any particular solution you. you can pick any you like. Most of them "fit in" C code very nicely.
-
*Sighs*. Of course I could have known I was going to be misunderstood. The point I was trying to make is that although C might be flexible (which is your point), as a [size=18]BEGINNING CODER[/size] you will find yourself thrown into the deep end once you leave the last page of your 'Learn C in 24 hours!' book. Keep those words [size=18]BEGINNING CODER[/size] in mind when reading my response please, and don't see it as a critique of the language---although one is forced to admit that if one has written a few projects in Python, or Ruby or Pike, C seems awfully messy and exposed.
That was my official answer. Now as to my unofficial one, which I will not debate further, because it does not cover what I meant to convey.
* Pointer stuff is prone to errors, no doubt about it. If you've been able to code a general n-dimensional matrix allocator without the code barfing up once (which is the kind of memory allocation I had in mind), then I bow to you, my Master, and will come train with you to learn the ways of the Force.
* String handling via IS messy if you've grown accostumed to simple things like 'a = a + ", world!";' With first you'd have to allocate the memory to hold the longer char *a, then copy it over with strcpy(). That's a whole lot of extra typing just for something simple as string concatenation. And that's just the beginning. Look up the capabilities of Python's string module if you want to have a useful set of routines which are not provided by ! Of course, you can easily write them yourself in C---but that was my original point.
* Your reply to my array-out-of-bounds mistake is silly: it doesn't matter if the array is dynamically or statically allocated. You are always poking around in memory you are not supposed to be poking around in. There is no language-supported checking on this type of error, which was again my point. Perhaps you are not such a good teacher of the ways of the Force after all...
* As to the system dependent stuff: If I want to code something which uses threads, and has to run on an Amiga, Windows, and Linux, I'd have to write separate threading modules for use with each operating system. Doable of course. But if I were to use Pike or Python or Java, I have but one way of writing that code to worry about, which (you guessed it) was my point. I'm not saying that the implementation of said languages on said OSes is the same (it's not) or easy (which it's not either)---but for the beginning coder it sure would be a lot easier if it were just all standardised, right...?
-
Pointer stuff is prone to errors, no doubt about it.
With correct typing I don't see this as a particular problem. There are several coding practices that reduce the change of making mistakes like that. Sure, it is well possible to screw up with pointers, but other languages have these aswell. I don't see this in any way weakness of C language.
You are always poking around in memory you are not supposed to be poking around in. There is no language-supported checking on this type of error, which was again my point.
There are tons of very nice standardized string libraries that provide dynamic and flexible string handling. You're not forced to use them however, the language doesn't enforce anything on you. Which is the point Jupp3 tried to make, I believe.
As to the system dependent stuff: If I want to code something which uses threads, and has to run on an Amiga, Windows, and Linux, I'd have to write separate threading modules for use with each operating system.
Well if you insist. I'd just use POSIX Threads library and be done with it.
C is nice since it doesn't restrict or limit you in any way if you prefer it that way. Still, you can use some very high level libraries that make your life very easy. The choice is yours, not something enforced by the language itself.
I'm not saying Python, or Ruby or other language sucks, these do have their applications. I say: Use whatever tool that fits your task. For me, C is the tool of choice.
-
as a BEGINNING CODER you will find yourself thrown into the deep end once you leave the last page of your 'Learn C in 24 hours!' book.
So what? Just use libraries that are suitable for beginners. Examples of such would be (imho) SDL and OpenGL.
But indeed that IS a problem. Many "beginner books" only have simple maths, basic structures, argument handling (overall, shell-only stuff) - all that while there are relatively easy ways to actually get (for example) graphical output of what you can calculate in your code!
I admit, "not being able to see what I could calculate" was maybe my biggest problem when I started coding in C, so in the beginning I just used a CU Amiga tutorial as base. It had code, which could actually draw pixels in window :-o - didn't understand most of it back then, but I managed to make it "do something I could see"
Soon that expanded to something, that should draw sierpinski triangle in a window (and later it actually DID draw that, once I replaced if(a=1) etc. with if(a==1), later switch-case, obviously)
Second problem was that I was using StormC back then, and it wouldn't compile much example codes I had. Later I just replaced it with gcc and separate text editor, and suddenly most of my problems just disappeared :-)
Since then it was OpenGL, then a bit of SDL and I noticed I had all features (and more) I always liked in AmosPRO, without all the problems.
Your reply to my array-out-of-bounds mistake is silly: it doesn't matter if the array is dynamically or statically allocated.
Consider following code (as code it sucks, but highlights the problem):
char *chr=malloc(atoi(argv[0]))
chr[10]='a';
There's no way compiler would know what size allocation ends up, so it can't warn about out-of-bounds access.
EDIT:
Maybe you meant that code should be checking bounds every time data is accessed, and compare it to the size of allocation? (thus forcing additional slowdown to all memory read & write operations)
Well that indeed can be a problem for beginners (especially considering how C does indexes, a[max] -> 0<=index
Again imho something, that shouldn't be forced on everyone. But I admit it, it can be a small problem for beginners.
-
c may be a pain for dealing with strings withouth a nice string lib but at least its not like vb.net on opening a file handle:
FILE * bla = fopen("c:\koft\pov.c","w");
vs
Dim bla As New System.IO.FileStream("c:\koft\POV.c", System.IO.FileAccess.Write)
(;
-
koaftder wrote:
c may be a pain for dealing with strings withouth a nice string lib but at least its not like vb.net on opening a file handle:
FILE * bla = fopen("c:\koft\pov.c","w");
vs
Dim bla As New System.IO.FileStream("c:\koft\POV.c", System.IO.FileAccess.Write)
(;
LOL, you make it sound like you typed every letter of that code. The IDE's auto-complete and selection as soon as you hit the "." reduces the actually typing greatly.
Also, a simple:
imports System.IO
at the top of your code (similar to a #include) and all you'd need in the code is:
Dim bla as New StreamWriter("c:\koft\POV.c")
-
lou_dias wrote:
LOL, you make it sound like you typed every letter of that code. The IDE's auto-complete and selection as soon as you hit the "." reduces the actually typing greatly.
Also, a simple:
imports System.IO
at the top of your code (similar to a #include) and all you'd need in the code is:
Dim bla as New StreamWriter("c:\koft\POV.c")
that sample was from sample from koft.net (http://koft.net/pov/converter.txt)
Yea, the IDE helps a lot. VisualStudio is top notch, and I use it for all my c/c++ development regardless if my stuff is targeted to linux or windows.
I know there are shortcuts but for a vb.net newbie coming from 10 years of vb experience ( started with 2.0 ) i found myself doing a lot of where.iswhatimlooking.for.inthe.framework.omg.its.all.thewayover.here?
and of course I hated that none of my code could easily migrate to .net. ):
Do we have a way in vb.net now to access lots of memory without using the dreded approach of multiple arrays each having less than 32k members or having to use a stinking collection class and stuffing data into strings to "hack" the ability to use megabytes of ram?
-
lol!
Are you guys trying to put me off?
-
@mel_zoom
Nah, it's just a case of a holy war (http://catb.org/jargon/html/H/holy-wars.html). ;-)
-
I find it amusing that there is a vb.net versus C debate going on here when the whole point of the thread was specifically about learning C on the amiga :-)
First of all I want to learn C (with the aim of learning C++) and not VB. Second I wanted to use my amiga to learn it. Since no .net language is available on the amiga its irrelavent really.
-
cymric:
I may be a beginner but I do understand that C is low level. Im not about to give up if I run into a problem handling an array.
-
@Piru
C is nice since it doesn't restrict or limit you in any way if you prefer it that way. Still, you can use some very high level libraries that make your life very easy. The choice is yours, not something enforced by the language itself.
I'm not saying Python, or Ruby or other language sucks, these do have their applications. I say: Use whatever tool that fits your task. For me, C is the tool of choice.
Cymric is still having a point, I think. If coder is a beginner he is likely to get more done in Java than in C or C++. Threading, serialization, GUI support and everything else is readily available and almost the same everywhere.
Java is well suited for beginners while experienced developers find C/C++ more flexible. IMO.
-
Ive seen a lot of people get into coding and from what I have seen is that the language almost doesn't matter anyway. A newbie will either grab it by the horns and slog though it or give up.
A person who can't grasp dealing with functions or compiling hello world will flail just as badly regardless of whether they started out with c or perl or python or basic, etc.
C is a good start, it weeds out those who would give up regardless and sets a foundation that can be expanded to anywhere.
-
mel_zoom wrote:
cymric:
I may be a beginner but I do understand that C is low level. Im not about to give up if I run into a problem handling an array.
That's perfectly okay, you need some persistence in order to learn programming in any language save for perhaps one: DWIM, Do What I Mean. You're perfectly fine with momentarily forgetting what I wrote as well---but remember that I wrote it once you begin coding big projects, and that you will require lots of extras to keep those managable. For now, concentrate on the basics, and even more importantly, enjoy yourself :-D.
@Piru:
Yes, using libraries is of course the way to go with C, I'm not at all disputing that. I'm also not trying to woo you away from your C-compiler: I too am very fond of my little blurbs of C with all their idiosyncracies, although I'm not experienced enough to do rapid prototyping with the language. I need something like Python etc. for that.
-
To be fair, designing my own libraries that wrapped up the OS behind my own class interfaces was more fun than writing the applications :lol:
-
Guys,
To me it looks like Mel is clever enough to overcome all the little nitty-gritty details that may have put some of you off. Pointers, strings, arrays, are a non issue for some people, even if C is their first language. And something tells me C isn't the first language for Mel.
Besides, many of the issues that some of you guys have raised about C are just non existent in C++: C++'s got a pretty decent string class, bound-checked arrays (vector class) and pretty nice memory handling classes (boost's shared_ptr class comes to mind).
Mel, I don't know what kind of role and expertise you have in your company, but if you're even slightly interested in general Computer Science, with some math background, and are as fascinated by languages in general even just one third than I am, then once you've grasped the basics of C, C++ and the Boost Library (http://www.boost.org/) will be your "paradise" (for lack of better term). :-)
-
... or if you want non-buffer-overflowing strings in C and don't mind being GPL or BSD licenced, download the Better String library for C/C++ (http://sourceforge.net/projects/bstring/). It supports length-terminated strings with adjustable buffer sizes for proper and fast concatination.
-
You know, I've written countless thousands of lines of C and C++ code by now. You know how many times I actually *needed* to directly concatenate a string for anything (as opposed to just reading/writing to some device or setting properties of some object)?
I can probably count it on the fingers of one hand. Unless you are specifically working on code that makes heavy use of text parsing I really think the issue is blown out of proportion.
-
Applications vary. I've had to code more text parsers to read out so-called universal file formats of weird scientific equipment than I care to remember.
-
@Cymric
I've had to do a lot of text parsing too and even then I rarely needed to concatenate strings. There are usually solutions you can come up with that don't require endless reallocation and strcat ;-)
-
@ Cymric
Why would a text parser need to concatenate strings?
-
falemagn wrote:
@ Cymric
Why would a text parser need to concatenate strings?
My point exactly. All the parsing I've done, if anything usually involved breaking text up into smaller tokens, not concatenating them into larger ones.
-
Karlos wrote:
falemagn wrote:
@ Cymric
Why would a text parser need to concatenate strings?
My point exactly. All the parsing I've done, if anything usually involved breaking text up into smaller tokens, not concatenating them into larger ones.
So you've never built SQL statements on the fly based on parameters in a filtering selection screen for a program that generates a report?
-
lou_dias wrote:
So you've never built SQL statements on the fly based on parameters in a filtering selection screen for a program that generates a report?
And that's text parsing exactly in which way?
On the costructive side: yes, in those cases - which however have nothing to do with parsing, the standard C library string functions are a pain to use. However, you can use whichever string library suits you best, or even not use C but rather C++.
-
Precisely.
That's not parsing text, that's building text. String concatenation may be a viable option there, but even then there are other solutions.
Most database stuff I've had to do that wasn't from a basic LAMP/ASP perspective has all been in C++ anyway and there the basic string class has proved more than adequate for said purposes.
-
Ok, I've written code that parses a file and replaces one text/byte(s) code with another. Now in VB6, you can read a 2MB file into a string, in memory, and doing a simple replace all at once and then writing over the old file was much faster than the traditional line by line method of drilling through the file, while writing to another followed by the delete of the old one and rename of the new to match the old.
It came in handy when converting large .CSV files with lines terminated with CR to CR/LF and vice versa.
File access is slow compared to memory access, hence having the entire file in memory was ideal and VB's "Replace" command allows you to use any sequence of bytes. It's not just limited to 7 bit ascii.
This turned a batch processing job of many large files into one that went from taking over an hour to taking just several minutes.
-
@lou_dias
#include
More search/match/replace power than you can throw a very large stick at ;-)
-
@adz
The C Programming Language (ANSI C) - B.W. Kernighan & D.M. Ritchie
I've been recommended this book also, so I picked up a copy from eBay - much better than the "C for Dummies" book I used initially. However, I haven't looked at it since this time last year!
Time to get back into it methinks... :crazy: ;-)
-
@ mel_zoom :-)
Hi :-)
There is a good list where you can ask for advice in learning C, that is open to all be they beginners or pros :-), and is sp*mfree, I'm it's moderator in chief ;-)
This list count some of the best Amiga coders and they will be happy to help you, so why not apply to it?
You can go there : Amiga-C2 mailling list (http://tech.groups.yahoo.com/group/Amiga-C2/) and push the "join" button :-)
-
lou_dias wrote:
Ok, I've written code that parses a file and replaces one text/byte(s) code with another. Now in VB6, you can read a 2MB file into a string, in memory, and doing a simple replace all at once and then writing over the old file was much faster than the traditional line by line method of drilling through the file, while writing to another followed by the delete of the old one and rename of the new to match the old.
It came in handy when converting large .CSV files with lines terminated with CR to CR/LF and vice versa.
File access is slow compared to memory access, hence having the entire file in memory was ideal and VB's "Replace" command allows you to use any sequence of bytes. It's not just limited to 7 bit ascii.
This turned a batch processing job of many large files into one that went from taking over an hour to taking just several minutes.
Why use VB to do the job of PL/SQL(T-SQL etc)?
Anyway, isn't this thread supposed to be about learning C? What point are you trying to achieve by spamming it with off topic crap about how superior VB is?
Start another thread and discuss it there.
-
cannonfodder:
Perhaps he is trying to tempt me into VB coding :-)
-
mel_zoom wrote:
cannonfodder:
Perhaps he is trying to tempt me into VB coding :-)
Well if we are all playing that game. Learn PL/SQL, you'll get paid more. ;-)
-
Nobody seems to get this. Im learning for my own interests, to be better qualified to deal with some of the technical jibber jabber I come across in my work and most of all - for fun!
A lot of SQL is used where I currently work - several implementations used across a range of systems. The one thing they all have in common is that they are overwhelmingly boring!
-
mel_zoom wrote:
Nobody seems to get this. Im learning for my own interests, to be better qualified to deal with some of the technical jibber jabber I come across in my work and most of all - for fun!
A lot of SQL is used where I currently work - several implementations used across a range of systems. The one thing they all have in common is that they are overwhelmingly boring!
Shall I start another thread?
"Why PL/SQL is not boring" ;-)
-
If you must. I am thinking I will have to start a new thread if I want to ask questions about C coding. This one seems to have gone off all by itself :lol:
-
mel_zoom wrote:
If you must. I am thinking I will have to start a new thread if I want to ask questions about C coding. This one seems to have gone off all by itself :lol:
What books have you got to read so far?
-
Well. Nothing amiga specific yet. Just the K&R book - for reference and a self paced book called "mastering standard C". Of course there is also a lot of resources on the web.
Perhaps I can use certain culinary skills to lure a personal C tutor that happens to be fond of spicy food... Except he seems to have vanished under a landslide of work ;-)
-
Well, I have these Amiga specific "beginners" C books:-
Lattice C Compiler for Amiga Volume 1 (Users Guide, Utilities, Commands, Editor + Disks) (Ring-bound in hard plastic folder)
Lattice C Compiler for Amiga Volume 2 (Debugger, Library Reference, Master Index + Disks) (Ring-bound in hard plastic folder)
The Amiga DOS Manual 2n Edition (Considered the unoffical RKRM) (Ring-bound book)
Lattice AmigaDOS C Compiler: Programmers Reference Manual
All of them are yours if you want them, just make me an offer.
I must add I have a craving for spicey foods too, and can be bribed quite easily with a good curry.
I'm free this Saturday and will be in the north too. ;-)
-
@mel_zoom
Nobody seems to get this. Im learning for my own interests, to be better qualified to deal with some of the technical jibber jabber I come across in my work and most of all - for fun!
Me too. I'd like to give some programs back to the community, and also develop some apps that are currently missing... And by this I don't mean a web browser or office app! :-o
A lot of SQL is used where I currently work - several implementations used across a range of systems. The one thing they all have in common is that they are overwhelmingly boring!
Yeah, I work with SQL too. Currently developing ASP/SQL implementation using M$ SQL Server.
-
CannonFodder wrote:
Why use VB to do the job of PL/SQL(T-SQL etc)?
Anyway, isn't this thread supposed to be about learning C? What point are you trying to achieve by spamming it with off topic crap about how superior VB is?
Start another thread and discuss it there.
Stop being ignorant, I was giving Karlos an example where string concacting becomes useful and saves time.
-
lou_dias wrote:
CannonFodder wrote:
Why use VB to do the job of PL/SQL(T-SQL etc)?
Anyway, isn't this thread supposed to be about learning C? What point are you trying to achieve by spamming it with off topic crap about how superior VB is?
Start another thread and discuss it there.
Stop being ignorant, I was giving Karlos an example where string concacting becomes useful and saves time.
Except you didn't.
Can we stick to actually helping Mel now?
-
lou_dias wrote:
Stop being ignorant, I was giving Karlos an example where string concacting becomes useful and saves time.
Do you really think I needed an example?
As I'd already said, I either used the C++ string class (which supports concatenation) or found other solutions for C. For PHP, ASP, Java etc., I used the inbuilt concatenation.
The point being that if a language doesn't have string concatenation built in it may be annoying but it's hardly a serious limitation provided it gives alternatives.
-
mel_zoom wrote:
Perhaps I can use certain culinary skills to lure a personal C tutor that happens to be fond of spicy food... Except he seems to have vanished under a landslide of work ;-)
Moi?
I'm very easily bribed by the promise of a good hot curry... :lol:
-
Make me a curry too before I starve in this wilderness of boring conversation.
:-D
(http://www.bookmice.net/darkchilde/japan/japan/curry.jpg)
-
That's easily the least appetising looking curry I have ever seen :lol:
-
it also appears to have a completely nonchalant stickman standing on the rice
:-D
-
Many years back, a girl invited me to come to her place with offerings of food to teach her in the ways of programming. We both worked for a medical supply store, she did data entry, I wrote the software she slaved with. We hit it off and after a while I discovered she had tourettes and months later I was dumped via email. Karlos beware... :-D
-
@Koaftder
Is that because her Tourettes was making her say yes all the time when she never was interested, forcing her to use email to actually say no? ;-)
-
what a, er, beautiful story :-D
tho you had to know someone well to discover they had tourettes?
I don't think I've ever met anyone with that, tho in school there was one kid who swore a lot, but I think he just liked swearing
-
koaftder wrote:
Many years back, a girl invited me to come to her place with offerings of food to teach her in the ways of programming. We both worked for a medical supply store, she did data entry, I wrote the software she slaved with. We hit it off and after a while I discovered she had tourettes and months later I was dumped via email. Karlos beware... :-D
Are you sure it wasn't the C causing her to mouth off? When she finally got sick of it, she sent you an email...
:ponder:
.
.
.
.
.
:devildance:
-
eh?? why is this thread so popular!? "Need Help Learning C" type threads are NEVER usually this popular! What is the unique attraction to this one?
lol, as if I couldn't guess :P :knuddel:
-
I think it shows that there are quite a number of programmers out there ready to help others. I for one use VC6 pro for work as needed to solve problems. I have only coded for the Amiga when I was taking c classes at school as at the time the Amiga was the only computer I had... :-D
I wonder if a project could be setup to do some porting of something I use constantly. It is called wxWidgets. http://wxwidgets.org It is a set of libraries that allows an easier way of creating windows, etc., cross platform. So any program code only needs to be made once and can be natively compiled for other platforms.
I would love to work on this, but do need help as I am not familiar with creating Amiga windows, requesters, etc.
The source for wxWidgets is free, and can be ported. Already as Linux and Windows, etc...
Anyone interested in helping?
-
Maybe this thread is popular because it features people arguing, put downs, egos, women, curry and mammogram links.
Or it could be the fascinating syntax indentation...
-
Be careful Melanie, Karlos is a Muslim, for sure he will beat you and force you to wear the burka.
-
@NattyNoh
Was that a bizarre attempt at humour or are you just trying to get banned?
-
NattyBoh:
"Be careful Melanie, Karlos is a Muslim, for sure he will beat you and force you to wear the burka."
So you said in my welcome thread. Ill be sure to be extra careful :roll:
Sounds almost as much fun as going to your wonderful country to enjoy a nice traditional pharonic circumcision.
-
(;
-
I noticed you changed your last post. You had said something like: "You realise he'll expect you to put out"
Put what out?
English might not be my first language but Im sure you arent using it properly.
-
"Putting out" refers to having sex. He obviously wants to be banned from this website but realized he crossed the line and changed it.
-
NattyBoh wrote:
Be careful Melanie, Karlos is a Muslim, for sure he will beat you and force you to wear the burka.
Length.
-
NattyBoh wrote:
Be careful Melanie, Karlos is a Muslim, for sure he will beat you and force you to wear the burka.
I think you'll find Mel is also Muslim.
Pillock.
-
Yeah, let's forget about C and have a FIGHT!
(http://img.photobucket.com/albums/v281/Gisfor/harry_hill_150.jpg)
-
I don't know if this is useful or not... It is not in the right forum but it fits the topic.
Programming Amiga book on Ebay (http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ih=015&sspagename=STRK%3AMESE%3AIT&viewitem=&item=250087592088&rd=1&rd=1)
Old but cheap and maybe useful.
-
Somewhat off topic here...
CannonFodder wrote:
NattyBoh wrote:
Be careful Melanie, Karlos is a Muslim, for sure he will beat you and force you to wear the burka.
I think you'll find Mel is also Muslim.
Not that it's really anybody's business but hers but I don't recall her saying that she is or not. Only that some of her family are.
-
Hyperspeed wrote:
Yeah, let's forget about C and have a FIGHT!
(http://img.photobucket.com/albums/v281/Gisfor/harry_hill_150.jpg)
That's easy, even without forgetting about C:
Watch closely....
C is the best procedural language bar none, C++ the best all round multiparadigm language and VB.net is soley the province of those unable to realise the aspiration of being real developers. Lastly, java, whilst being syntactically clean and nice is for workshy pseudo developers that are afraid of implementing absolutely anything for themselves or having to know the first thing about system level development.
:-P
(incidentally, I'm just winding you all up)
-
Visual Basic is a bit like programming IKEA style. Java is just rancid, the resulting programs are horribly slow and unresponsive.
Personally I think cross-platform compatibility is the bane of the modern computing world. Everyone and everything should be focused on one platform - maybe solely Assembly. That way effiency is guaranteed.
I have found the perfect language for mel_zoom though:
(http://www.artezia.net/musique/melC/melanie-c1.jpg)