For file input/output the stdio lib has it all. For example:
fgetc and fputc gets/puts a char from/to a file.
fgets and fputs similar for an array of chars (string)
Then there are fread/fwrite to read/write an array of members (may be
any bytes), and fprintf to write formatted output to a file. stdio
lib also has things such as fopen, fclose. All these are fairly easy
to relate to BASIC file handling commands.

You need to read up a bit on the facilities of the C standard
libraries.

PRINT#C%,whatever is mirrored by the far more powerful
fprintf(*stream, "formatstring", parameter list)
where *stream is the eqivalent of file handle
format stream describes what is to be output, e.g. "Value of x is %d
and y is %d\n"
and parameter list is the variables, whose values are to be inserted
in order into the formatstring. %d means 'output a signed decimal'.
You also have e.g. %x for hexadecimal, %f for a double and so on. You
can specify whether in exp or mmm.nnn format and the number of dec
places etc. %s would be a literal string.

Here are some random lines of code :

outfile = fopen ( filename, "w" ) ; /* create new file for write or
reset existing file to zero length */

fprintf ( outfile, "# %s file written by %s\n", pd->file_id, APPNAM )
;

fprintf ( outfile, "MinPadBytes:%d\n", app.v2.min_padding );
fprintf ( outfile, "MaxPadBytes:%d\n", app.v2.max_padding );
fprintf ( outfile, "PadRatio:%d\n", app.v2.padding_ratio );

fprint ( outfile, "This is a simple string, followed by a newline\n")

fprintf ( outfile, "%d,%d\n", int1, int2 ); /* comma separated
variables */

fclose ( outfile ) ;
osfile_set_type ( filename, osfile_TYPE_TEXT ) ; /* from oslib */

That's not so different to the BASIC equivalent is it?

This would result in a test file containing e.g.

# Choices file written by ID3TagEd
MinPadBytes:256
MaxPadBytes:2048
PadRatio:25
This is a simple string, followed by a newline
77,44

There is a very good introduction to C++ in one of the Qt books
which basically describes only a simple subset of C++ which
is easy to understand and easy to maintain.

At the end of the day, I would always recommend Ada 2005 or
Java or C# with a good introductory book for people who want to
learn programming. For RISC OS of course, all three languages
are a no-go area...

Steffen

"Playing around with a little Vala programming under RISC OS wimp using
OSLib bindings and it just works! Sooo nice! OO without C++ ugliness!"

Gareth, I think the BASIC file formats are documented in the BBC BASIC
manual. If you don't have the RISC OS one, I'm sure one of the BBC Micro
manuals would suffice and you can find them on the net - the formats have
barely changed since the BBC.

Then you just need to write a bit of code to read the files in one byte at a
time and interpret the contents.  If you just want strings and integers it
shouldn't be too complex.  Use fgetc() to read in a character and fill in
the result variables as you go (writing more efficient code can be left for
later).  If it helps, write this bit in BASIC first (using just, OPENIN,
CLOSE# and BGET#) and then convert it to C.

Ta,

Steve

Why not forget about BASIC PRINT#, and rewrite the new prog in C
using the standard functions. If there are existing files that must
be used by the new prog, why not write a simple utility to convert
the files once and for all over to the new format.

Must confess, I rarely used BASICs PRINT#, preferring
BPUT#handle%,string$ which is more akin to the C functions fprintf
etc.

Why should I need to no C? If I learn C++ I learn what I need for C++.
No more no less. And of course C++ is different thinking than C. Thats
why C++ was invented.

If I want read a file in C++ I don't need the C library functions. I
just use the C++ library:

---snip---
string str;
ifstream f("test.txt"); // open file for input
f >> str;      // read first word from file to string object
cout << str;   // write string to console
---snip---

What is complex on this example? It looks only complex to someone who
_don't_ know C++. But this is same case for C, Ada, Java, BASIC etc.

If you learn C and then C++ you have wasted time to one language while
you wanted C++.

Once you've got to grips with that, the additional syntax introduced by
C++ essentially just bolts on.  Sounds like a win to me.

You don't teach piano by dumping your student in front of a Grand and
give him Mozart to play.

C and C++ have all assignments right to left.  I still fail to
understand why the input assignment was made different.

In all honesty, streams are not a simple part of C++, though they are
safer than using printf and friends.

C++ is messy, ugly, difficult and complex; but it offers many
advantages over C if used with a bit of thought. You shouldn't and
don't need to dive in at the deep end.

struct point;
{
int xpos;
int ypos;

struct gameObject {
        struct point base;
        int xsize;
        int ysize;

In short, everything that is difficult in C (and I talk here from
a solution perspective, not from an implementation perspective -
if you follow that line of argument, you should learn Assembler first,
because it is and order of magnitude simpler than C) you do not need
to know in C++.

Of course, once you encounter mixed language environments, maybe
you want to use C libs from C++, you encounter real-world C++
code that still uses the language like it existed in 1999 - then
you will need to know C.

If you stay within the bounds of "safe C++", I would say
that C++ is actually simpler than C. Let's face it, for real
world problems, C is a very complicated language, because you
have to implement everything in a low-level manner with very
little abstraction and safety to keep you out of trouble.

I would even argue that every language that does not have
a garbage collector by default is a bad language for beginners.

It is really one of the major RISC OS failings (back in the Acorn years)
that we never had a consolidated library - especially for the WIMP -
that was universally used by developers and multiple languages. The
Toolbox was a weak attempt. The amount of "reinventing the wheel"
amongst developers is staggering.

Steffen

It lacking any of the traditional code generators, OS bindings, or
anything at all that make porting future versions of the compiler
difficult, it should be much easier to keep it up to date.

Which is almost exactly the same reason Lua's still kept up to date;
it's simple and trivial to maintain once ported.

Otherwise, I could through some C code together to add to the VB
implementation.

 OK the string library is limited - but it doesn't need much ingenuity to
extend it. Also pointer/array ownership can usually be controlled by the
program structure and need not involve malloc etc. if string arrays are
declared (As they are effectively in BASIC).

 If extensive use is made of malloc/free it is straightforward to provide
error checks and safe garbage collection without complicating the language.
Also with modern machines the time/memory overheads for doing this are small
for many applications.

Also it my opinion the more complex a language becomes:-

a) Simple minded programmers (like me) are less likely to understand what
they are doing.

b) As a consequence the more likely it is that features will be
misinterpreted by the programmer.

John

Oh by the way, C has a form of garbage collection in the shape of local
variables!

More seriously, at least it teaches you what is actually happening.