SWIs and BASIC file reading/writing in C++
Gazza
whole, the job should be fairly easy, as I've dealt with languages
like JavaScript in the past, which are similar to C/C++ in many
respects. The two aspects I'm not sure about are calling SWIs and file
I/O using C++ routines compatible with BASICs PRINT#/INPUT#, which are
how all my data files are written. Can anybody sort this out for me?
Chris Johnson
<75fc176e-3ddf-465c...@r5g2000yqb.googlegroups.com>,
For SWI handling I would suggest oslib. A very easy SWI veneer to use.
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.
--
Chris Johnson
Gazza
wrote:
> In article
> <75fc176e-3ddf-465c-b2ac-a24b888c4...@r5g2000yqb.googlegroups.com>,
I understand the command side of things, but I need to be able to
convert files written with BASICs PRINT# command. That is why I need
either customised routines to do it, or how BASIC does it, so I can
sort it out!
Rob Kendrick
If you're new to C and C++, I would strongly recommend getting to grips
with C before C++; C++ is way more complex, and I think I can count on
the fingers of one hand the number of people I actually trust to write
it. (And one of them is not me.)
B.
Chris Johnson
<9eff70f6-fc99-4e45...@k19g2000yqc.googlegroups.com>,
Gazza <use...@garethlock.com> wrote:
> On Oct 18, 11:07 pm, Chris Johnson <chrisjohnson+n...@spamcop.net>
> wrote:
> > In article
> > <75fc176e-3ddf-465c-b2ac-a24b888c4...@r5g2000yqb.googlegroups.com>,
> > Gazza <use...@garethlock.com> wrote:
> >
> > > OK... I'm planning to port my Space Invaders clone to C++... On
> > > the whole, the job should be fairly easy, as I've dealt with
> > > languages like JavaScript in the past, which are similar to
> > > C/C++ in many respects. The two aspects I'm not sure about are
> > > calling SWIs and file I/O using C++ routines compatible with
> > > BASICs PRINT#/INPUT#, which are how all my data files are
> > > written. Can anybody sort this out for me?
> >
> > For SWI handling I would suggest oslib. A very easy SWI veneer to
> > use.
> >
> > 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.
> >
> I understand the command side of things, but I need to be able to
> convert files written with BASICs PRINT# command. That is why I need
> either customised routines to do it, or how BASIC does it, so I can
> sort it out!
I repeat - You need to read up a bit on the facilities of the C
standard libraries. Amplifying a little, and not writting real code
you have for example in BASIC the OPENIN, OPENUP and OPENOUT
commands. These are mirrored by the C function *fopen(filename,
mode). BASICs CLOSE#C% is mirrored by fclose(stream).
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
--
Chris Johnson
Steffen Huber
> On Sun, 18 Oct 2009 13:31:21 -0700 (PDT)
> Gazza <use...@garethlock.com> wrote:
>
>> OK... I'm planning to port my Space Invaders clone to C++... On the
>> whole, the job should be fairly easy, as I've dealt with languages
>> like JavaScript in the past, which are similar to C/C++ in many
>> respects. The two aspects I'm not sure about are calling SWIs and file
>> I/O using C++ routines compatible with BASICs PRINT#/INPUT#, which are
>> how all my data files are written. Can anybody sort this out for me?
>
> If you're new to C and C++, I would strongly recommend getting to grips
> with C before C++;
It really depends. People who come from an imperative background often
have problems understanding object-oriented programming, especially if
the imperative language they know have no support for proper ADTs.
> C++ is way more complex, and I think I can count on
> the fingers of one hand the number of people I actually trust to write
> it. (And one of them is not me.)
The key to learn C++ is to not try and understand the complete
language. Noone fully understands C++. The finer details of the
template mechanism are extremely difficult (and to decide whether
an error you encounter is because the compiler does not work
properly or you have made a mistake is often impossible) to
understand. The precise rules for constructor/destructor
hierarchies are also not really intuitive.
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
--
Steffen Huber
hubersn Software - http://www.hubersn-software.com/
Rob Kendrick
Steffen Huber <sp...@huber-net.de> wrote:
> > If you're new to C and C++, I would strongly recommend getting to
> > grips with C before C++;
>
> It really depends. People who come from an imperative background often
> have problems understanding object-oriented programming, especially if
> the imperative language they know have no support for proper ADTs.
However, there is plenty in C++ that you must understand that you must
also understand in C, and C is an order of magnitude simpler.
> > C++ is way more complex, and I think I can count on
> > the fingers of one hand the number of people I actually trust to
> > write it. (And one of them is not me.)
>
> The key to learn C++ is to not try and understand the complete
> language. Noone fully understands C++. The finer details of the
> template mechanism are extremely difficult (and to decide whether
> an error you encounter is because the compiler does not work
> properly or you have made a mistake is often impossible) to
> understand. The precise rules for constructor/destructor
> hierarchies are also not really intuitive.
The problem is that it's almost impossible to avoid bizarre, complex
and difficult problems. Most people don't even realise they've stepped
on a bomb.
> 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...
Vala could be possible, Jan-Jaap van der Geer tweeted this recently;
"Playing around with a little Vala programming under RISC OS wimp using
OSLib bindings and it just works! Sooo nice! OO without C++ ugliness!"
B.
Theo Markettos
> I repeat - You need to read up a bit on the facilities of the C
> standard libraries. Amplifying a little, and not writting real code
> you have for example in BASIC the OPENIN, OPENUP and OPENOUT
> commands. These are mirrored by the C function *fopen(filename,
> mode). BASICs CLOSE#C% is mirrored by fclose(stream).
Indeed, but the OP is trying to read files written by PRINT# etc. These are
written in a peculiar way (eg strings are backwards) due to memory
constraints on the BBC Micro. I'm not aware of a C library to read files
written by PRINT#
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.
Theo
Ste (news)
Chris Johnson <chrisjoh...@spamcop.net> wrote:
> That's not so different to the BASIC equivalent is it?
Don't forget BASIC's PRINT# outputs the bytes of the string in reverse
order, annoyingly. Likewise, INPUT# reads them in reverse order.
Ta,
Steve
--
Steve Revill @ Home
Note: All opinions expressed herein are my own.
Chris Johnson
Ste (news) <st...@revi11.plus.com> wrote:
> In article <50aca05762chr...@spamcop.net>,
> Chris Johnson <chrisjoh...@spamcop.net> wrote:
> > That's not so different to the BASIC equivalent is it?
> Don't forget BASIC's PRINT# outputs the bytes of the string in
> reverse order, annoyingly. Likewise, INPUT# reads them in reverse
> order.
Sorry - didn't click that OP was wanting to read from pre-existing
files. Notwithstanding that, as I said before the c function fgetc ()
will read a char from a file. Thus it is simple enough to read the
chars into a buffer and then reverse them. Similarly fputc() to write
the file.
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.
--
Chris Johnson
Theo Markettos
> 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.
Good idea. The converter can even be written in BASIC :)
Theo
Amin Kharchi
> If you're new to C and C++, I would strongly recommend getting to grips
> with C before C++; C++ is way more complex, and I think I can count on
> the fingers of one hand the number of people I actually trust to write
> it. (And one of them is not me.)
It's not a good idea to start with C if you want do C++. [1] C and C++
are different languages. There is no C/C++! [2] There is only C and C++.
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++.
[1] http://www.research.att.com/~bs/bs_faq.html#prerequisite
[2] http://www.research.att.com/~bs/bs_faq.html#C-slash
Rob Kendrick
Amin Kharchi <amin...@kharchi.eu> wrote:
> If you learn C and then C++ you have wasted time to one language while
> you wanted C++.
Inversely, you get to learn all the shared syntax, pointer arithmetic,
compiling and linking command line syntax, debugging methods, and bags
of other things without being confused by all the ill-thought-out OO
and confusing syntax.
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.
B.
Dave Higton
Amin Kharchi <amin...@kharchi.eu> wrote:
> ---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?
The input assignment is left to right, whereas the output assignment
is right to left.
C and C++ have all assignments right to left. I still fail to
understand why the input assignment was made different.
Dave
Rob Kendrick
Dave Higton <daveh...@dsl.pipex.com> wrote:
> C and C++ have all assignments right to left. I still fail to
> understand why the input assignment was made different.
A question that has plagued programmers for years. The best anybody's
ever come up with was that the standard library was devised by the
clinically insane who cut their cocaine with washing powder.
B.
James Peacock
> 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++.
It's a bit too simple as errors will be ignored (streams don't throw
exceptions by default, you need to set the exception mask).
In all honesty, streams are not a simple part of C++, though they are
safer than using printf and friends.
James
James Peacock
> On Mon, 19 Oct 2009 22:47:57 +0200
> Amin Kharchi <amin...@kharchi.eu> wrote:
>
>> If you learn C and then C++ you have wasted time to one language while
>> you wanted C++.
>
> Inversely, you get to learn all the shared syntax, pointer arithmetic,
> compiling and linking command line syntax, debugging methods, and bags
> of other things without being confused by all the ill-thought-out OO
> and confusing syntax.
To be fair, the basic syntax, compiling, linking, debugging are very
similar. The fact that C is /so/ dependent on pointer arithmetic is
arguably a weakness as it is error prone. C++ /can/ reduce dependence
on such things.
> Once you've got to grips with that, the additional syntax introduced by
> C++ essentially just bolts on. Sounds like a win to me.
I don't think 'just bolts on' would be the correct attitude to take.
To get the best from C++, you need to learn it as a new language and
get out of the low level C mindset.
> You don't teach piano by dumping your student in front of a Grand and
> give him Mozart to play.
Even basic string manipulation is a pain in C, something as simple as
concatenating two strings. Even BASIC can do it better for short
strings. C++ at least offers you the fairly safe and easy to use
std::string, which I think most C++ programmers would consider simple
enough for a beginner to use. I can't say the same about C, it will at
the least involve malloc, possibly free somewhere, memcpy or similar;
and that doesn't even mention the explicit error handling or pointer
ownership details.
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.
James
Gazza
wrote:
Thanks Theo... That was indeed what I was trying to get at. YES. I
used PRINT# on purpose, because it just adds another layer of
obfuscation into the datafiles. That and the dynamic XOR code I'm
using, seems to have made the HiScore table un-breakable so far. I've
had a couple of people I know have a go at it and they couldn't work
out what was going on without viewing the source code first.
Gazza
to plain C if struct definitions could inherit other struct
definitions eg...
struct point;
{
int xpos;
int ypos;
}
struct gameObject : point;
{
int xsize;
int ysize;
}
So... Something of type gameObject would have xpos,ypos, xsize & ysize
defined.
John-Mark Bell
Struct aggregation is your friend:
struct gameObject {
struct point base;
int xsize;
int ysize;
};
John.
Steffen Huber
> On Mon, 19 Oct 2009 13:10:31 +0200
> Steffen Huber <sp...@huber-net.de> wrote:
>
>>> If you're new to C and C++, I would strongly recommend getting to
>>> grips with C before C++;
>> It really depends. People who come from an imperative background often
>> have problems understanding object-oriented programming, especially if
>> the imperative language they know have no support for proper ADTs.
>
> However, there is plenty in C++ that you must understand that you must
> also understand in C, and C is an order of magnitude simpler.
Apart from the basic flow stuff (if/switch, loops) and the curly
braces, I can't think of much that you must know from C that you need
in modern C++. If you use the STL and the standard lib, you don't need
the pointer stuff and malloc and things. You don't need structs and
unions. You don't need the preprocessor apart from import. You don't
need the complicated C string stuff.
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.
>>> C++ is way more complex, and I think I can count on
>>> the fingers of one hand the number of people I actually trust to
>>> write it. (And one of them is not me.)
>> The key to learn C++ is to not try and understand the complete
>> language. Noone fully understands C++. The finer details of the
>> template mechanism are extremely difficult (and to decide whether
>> an error you encounter is because the compiler does not work
>> properly or you have made a mistake is often impossible) to
>> understand. The precise rules for constructor/destructor
>> hierarchies are also not really intuitive.
>
> The problem is that it's almost impossible to avoid bizarre, complex
> and difficult problems. Most people don't even realise they've stepped
> on a bomb.
Oh, it is easily possible. There are very few things in C++ that
look easy but are hard to understand.
>> 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...
>
> Vala could be possible, Jan-Jaap van der Geer tweeted this recently;
>
> "Playing around with a little Vala programming under RISC OS wimp using
> OSLib bindings and it just works! Sooo nice! OO without C++ ugliness!"
There are thousands of interesting languages around that are
"cool" and "nice". And some of them once had RISC OS ports. Tcl.
Python. Lua. Ada. Forth. Java. Apart from Lua, none of those ports
have been kept up-to-date.
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.
Rob Kendrick
Steffen Huber <sp...@huber-net.de> wrote:
> Apart from the basic flow stuff (if/switch, loops) and the curly
> braces, I can't think of much that you must know from C that you need
> in modern C++. If you use the STL and the standard lib, you don't need
> the pointer stuff and malloc and things. You don't need structs and
> unions. You don't need the preprocessor apart from import. You don't
> need the complicated C string stuff.
You'll end up with a really badly performing C++ program, though :)
And you missed pointers. And what happens when you want to interface
with something from the C world.
> 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++.
Simpler in concept, but not simpler in use.
> 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.
That's why we have libraries; just like you use in C++ to do these.
> > The problem is that it's almost impossible to avoid bizarre, complex
> > and difficult problems. Most people don't even realise they've
> > stepped on a bomb.
>
> Oh, it is easily possible. There are very few things in C++ that
> look easy but are hard to understand.
And you end up with C with operator overloading.
> > Vala could be possible, Jan-Jaap van der Geer tweeted this recently;
> >
> > "Playing around with a little Vala programming under RISC OS wimp
> > using OSLib bindings and it just works! Sooo nice! OO without C++
> > ugliness!"
>
> There are thousands of interesting languages around that are
> "cool" and "nice". And some of them once had RISC OS ports. Tcl.
> Python. Lua. Ada. Forth. Java. Apart from Lua, none of those ports
> have been kept up-to-date.
The nice approach of Vala is its simplicity, and its working. It emits
C, so you can use your already existing libraries, and its support
library requirements are quite modest (in that, it depends on Glib, but
its use of Glib is quite simple, so is likely to be around for the
foreseeable future.)
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.
B.
Jonathan Graham Harston
> I understand the command side of things, but I need to be able to
> convert files written with BASICs PRINT# command. That is why I need
> either customised routines to do it, or how BASIC does it, so I can
enough to trabslate into C? BBCFile implements PRINT# and INPUT# in
BASIC, so lets you read/write Acorn-style BASIC data files
regardless of the native implementation the interpreter happens to
use.
Otherwise, I could through some C code together to add to the VB
implementation.
--
J.G.Harston - j...@arcade.demon.co.uk - mdfs.net/User/JGH
There are three food groups: brown, green and ice cream.
Mr John FO Evans
<j.peaco...@googlemail.com> wrote:
> Even basic string manipulation is a pain in C, something as simple as
> concatenating two strings. Even BASIC can do it better for short
> strings. C++ at least offers you the fairly safe and easy to use
> std::string, which I think most C++ programmers would consider simple
> enough for a beginner to use. I can't say the same about C, it will at
> the least involve malloc, possibly free somewhere, memcpy or similar;
> and that doesn't even mention the explicit error handling or pointer
> ownership details.
What is wrong with strcat(s1,s2)??????
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!
--
_ _________________________________________
/ \._._ |_ _ _ /' Orpheus Internet Services
\_/| |_)| |(/_|_|_> / 'Internet for Everyone'
_______ | ___________./ http://www.orpheusinternet.co.uk
Rob Kendrick
Mr John FO Evans <mi...@orpheusmail.co.uk> wrote:
> What is wrong with strcat(s1,s2)??????
It doesn't give you a compiler error for use of too many question marks?
More seriously, at least it teaches you what is actually happening.
> 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).
Indeed; there are countless macro libraries out there to make C strings
safe and easy.
> Oh by the way, C has a form of garbage collection in the shape of
> local variables!
This is called the stack. It's difficult to think of a language that
doesn't use the stack like this.
B.
Gazza
wrote:
OK... I think that's what I'm looking for for the file I/O. Should be
trivial to convert that to C...
Gazza
>
> - Show quoted text -
That looks more portable, probably what I was trying to do with the
code I had. My only reference at the time was MSDN after all... So
what I was doing was probably legal from a Visual Studio point of
view, but not from within a RISC OS world.