| [ANNOUNCE] VICE 1.18 [message #141722] |
Sun, 27 November 2005 05:35  |
Andreas Boose
Messages: 46
Registered: September 2003
Karma: 0
|
Member |
|
|
Version 1.18 of VICE, the Versatile Commodore Emulator, has been
released.
VICE emulates the Commodore C64, C128, VIC20, PET 8-bit computers,
PLUS4 and the CBM-II (aka C610) and is completely written in C/C++; it
runs on Unix, Win32, MS-DOS, RiscOS, OS/2, BeOS and QNX systems.
VICE is *free* software released under the GNU General Public License,
and as such it comes with full source code.
This is mainly a bugfix release. There will be a 1.18a source archive
later on that will fix some problems with picky compilers, but this
does not affect the binary distributions.
Most important changes since the last version include:
* Changes in VICE 1.18
======================
** General
----------
- Fixed a bug that caused the emulator to crash after 72 minutes.
- Added internal zlib and lpng support if no native libraries are
found at compile time.
- Fixed video recording frame rate in NTSC mode.
** C64 changes
--------------
- Added Structured Basic, Comal 80 and Ross cart support.
- Fixed the improper detaching of certain types of carts.
- The +60K expansion base address is now selectable for
compatibility with the oldest version of the expansion.
** C128 changes
---------------
- Improved the VDC emulation.
** Unix changes
---------------
- New HardSid support (experimental).
** MS-Windows changes
---------------------
- Added internal zlib and lpng support to the MSVC compile.
- 'Netplay' option linking two emulators via TCP network (experimental
and x64-only for now).
** MS-DOS changes
-----------------
- Added screenshot support.
** OS/2 changes
---------------
- The OS/2 port works again now.
** Miscellaneous changes
------------------------
- Added support for more 3rd party basic extenders to petcat.
The VICE 1.18 source archive is available at:
http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulato rs/VICE/vice-1.18.tar.gz
The VICE 1.18 MSDOS binary archive is available at:
http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulato rs/VICE/vice118.zip
The VICE 1.18 WIN32 binary archive is available at:
http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulato rs/VICE/WinVICE-1.18.zip
The VICE 1.18 RiscOS binary archive is available at:
http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulato rs/VICE/vice-riscos1_18.zip
The VICE 1.18 OS/2 binary archive is available at:
http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulato rs/VICE/vice2-1.18.zip
The VICE 1.18 BeOS binary archive is available at:
http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulato rs/VICE/BeVICE-1.18.x86.zip
The VICE 1.18 QNX 6.X binary archive is available at:
http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulato rs/VICE/VICE-1.18-x86-public.qpr
Various VICE 1.18 Solaris binary archives are available at:
http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulato rs/VICE/
For more information check out the VICE home page at:
http://www.viceteam.org/
MfG Andreas
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141723 is a reply to message #141722] |
Sun, 27 November 2005 08:30  |
Stealth
Messages: 164
Registered: June 2005
Karma: 0
|
Senior Member |
|
|
Source archive is improperly compressed and unpacks into only three files,
de.po, fr.po and it.po , so I suspect there was a glitch while tarballing
the ordeal.
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141724 is a reply to message #141723] |
Sun, 27 November 2005 11:39 |
Spiro Trikaliotis
Messages: 380
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Hello,
Stealth <protostealth@*spamblocker*hotmail.com> schrieb:
> Source archive is improperly compressed and unpacks into only three
> files, de.po, fr.po and it.po , so I suspect there was a glitch while
> tarballing the ordeal.
the tarball on zimmers.net seems to have been converted as a text file
(CR/LF vs. LF), thus, it does not work.
Until this is fixed (and until my traffic exceeds my limits ;-)), I put
up a temporary download link at
http://www.vicekb.de.vu/vice-1.18.tar.gz
Note: To find out if you have the correct tarball:
The correct tarball has a md5sum of
$ md5sum vice-1.18.tar.gz
44266d2427510adcac58cbf58da05be1 *vice-1.18.tar.gz
Regards,
Spiro.
--
Spiro R. Trikaliotis http://cbm4win.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
|
|
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141726 is a reply to message #141725] |
Sun, 27 November 2005 13:35 |
Golan Klinger
Messages: 559
Registered: December 2004
Karma: 0
|
Senior Member |
|
|
And still no binary version for OS X. :(
Is there no one who can step up and make a binary version available for
download? No matter what I did, I could not get 1.17 to compile and it is
driving me bonkers.
--
Golan Klinger
Dark is the suede that mows like a harvest.
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141727 is a reply to message #141722] |
Sun, 27 November 2005 16:40 |
iAN CooG
Messages: 613
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Andreas Boose <andreas.boose@viceteam.org> wrote:
> Version 1.18 of VICE, the Versatile Commodore Emulator, has been
> released.
Run/stop restore does not work more than once now.
Winvice x64.exe and x128.exe from viceteam site, default settings, no matter
which *.vkm I set.
--
-=[]=--- iAN CooG/HokutoForce ---=[]=-
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141728 is a reply to message #141726] |
Sun, 27 November 2005 19:17 |
Patryk 'Silver Dream
Messages: 737
Registered: July 2003
Karma: 0
|
Senior Member |
|
|
Golan Klinger wrote:
> And still no binary version for OS X. :(
>
> Is there no one who can step up and make a binary version available for
> download? No matter what I did, I could not get 1.17 to compile and it is
> driving me bonkers.
>
I thought I offered a helping hand on compiling... Threfore I know at
least one thing you didn't do when you were trying to compile 1.17.
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141729 is a reply to message #141728] |
Mon, 28 November 2005 00:27 |
Golan Klinger
Messages: 559
Registered: December 2004
Karma: 0
|
Senior Member |
|
|
silverdr wrote:
> I thought I offered a helping hand on compiling...
I followed the advice you gave back in October. I removed the references
to mkfontdir but I was still unable to get it to compile. I didn't want to
keep bugging you so I dropped the issue. I also followed previously given
advice regarding SDL. I kept trying different things but after ten or so
failed attempts, I gave up.
I can't help but wonder if the reason that there isn't a binary available
is that it isn't all that easy to get it working.
--
Golan Klinger
Dark is the suede that mows like a harvest.
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141730 is a reply to message #141729] |
Mon, 28 November 2005 06:51 |
Patryk 'Silver Dream
Messages: 737
Registered: July 2003
Karma: 0
|
Senior Member |
|
|
Golan Klinger wrote:
> silverdr wrote:
>
>
>> I thought I offered a helping hand on compiling...
>
>
> I followed the advice you gave back in October. I removed the references
> to mkfontdir but I was still unable to get it to compile. I didn't want to
> keep bugging you so I dropped the issue. I also followed previously given
> advice regarding SDL. I kept trying different things but after ten or so
> failed attempts, I gave up.
>
> I can't help but wonder if the reason that there isn't a binary available
> is that it isn't all that easy to get it working.
>
Actually (except the one problem I described) I didn't have any real
problems compiling. The reason IMHO is that the compiled version
installs in a UNIX way, where (since you compiled it) you can be sure
that you have all the necessary system-support components in place.
Under OS X the proper way of binary distribution is to make an app
bundle, which contains everything required to run the app. Unfortunately
this is not exactly the same as writing "make" and "sudo make install".
Other way would be to create an installer package, which can be done
more easily (read: less time consuming) but that I am afraid would not
be guaranteed to work on each and every machine.
Having said that - I might prepare the installer package and let you
test it. Please remind me at the end of the week.
In the meantime try to build your own version and discuss the outcome
with me. I can find few minutes to guide you if given enough information.
P.S. I also know about a true OS X port coming. I saw the alpha running
really fine - x64 only ATM :-( but very promising.
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141731 is a reply to message #141729] |
Mon, 28 November 2005 07:11 |
Patryk 'Silver Dream
Messages: 737
Registered: July 2003
Karma: 0
|
Senior Member |
|
|
Golan Klinger wrote:
>
> I can't help but wonder if the reason that there isn't a binary available
> is that it isn't all that easy to get it working.
>
Just downloaded and compiled 1.18. Compiled OOB w/o a single glitch.
Only the old _installation_ problem remains and has to be worked around
due to the mkfontscale crashing bug I described some time ago. Knowing
that - everything took about 5-6 minutes.
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141732 is a reply to message #141725] |
Mon, 28 November 2005 07:20 |
Lars Haugseth
Messages: 231
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
* Andreas Boose <andreas.boose@viceteam.org> wrote:
|
| On Sun, 27 Nov 2005 17:39:15 +0100, Spiro Trikaliotis
| <news-200511@trikaliotis.net> wrote:
|
| > Until this is fixed (and until my traffic exceeds my limits ;-)), I put
| > up a temporary download link at
| >
| > http://www.vicekb.de.vu/vice-1.18.tar.gz
|
| The corrupt archive has been replaced now.
The file src/network.c won't compile with gcc 4.0.2 under SuSE Linux 10.0.
Here is the compiler output:
network.c: In function 'network_create_event_buffer':
network.c:235: error: invalid lvalue in increment
network.c:236: error: invalid lvalue in increment
network.c:237: error: invalid lvalue in increment
network.c: In function 'network_create_event_list':
network.c:259: error: invalid lvalue in increment
network.c:260: error: invalid lvalue in increment
network.c:261: error: invalid lvalue in increment
The offending lines look like this:
235: *((unsigned int*)bufptr)++ = current_event->type;
236: *((CLOCK*)bufptr)++ = current_event->clk;
237: *((unsigned int*)bufptr)++ = current_event->size;
259: type = *((unsigned int*)bufptr)++;
260: clk = *((CLOCK*)bufptr)++;
261: size = *((unsigned int*)bufptr)++;
As a workaround I split each line into two statements, thus:
*((unsigned int*)bufptr) = current_event->type;
bufptr += sizeof(unsigned int*);
etc.
After this, it compiles fine, and seems to run without problems,
however I haven't done any networking from within VICE, so it could
be erroneous. My C is a bit rusty, and I'm not sure whether the
buffer pointer should be increased before or after the assignments
in this case.
--
Lars Haugseth
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141733 is a reply to message #141727] |
Mon, 28 November 2005 07:41 |
|
|
Originally posted by: Eregil
On Sun, 27 Nov 2005 21:40:20 +0000, iAN CooG wrote:
>> Version 1.18 of VICE, the Versatile Commodore Emulator, has been
>> released.
>
> Run/stop restore does not work more than once now.
> Winvice x64.exe and x128.exe from viceteam site, default settings, no matter
> which *.vkm I set.
For what it's worth, I can confirm that it's not a platform-specific
issue, I experience the same problem on a linux (debian) box after
compiling from source.
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141735 is a reply to message #141732] |
Mon, 28 November 2005 12:08 |
|
|
Originally posted by: Eregil
Il Mon, 28 Nov 2005 12:20:29 +0000, Lars Haugseth ha scritto:
> As a workaround I split each line into two statements, thus:
>
> *((unsigned int*)bufptr) = current_event->type;
> bufptr += sizeof(unsigned int*);
>
> etc.
Shouldn't this be
bufptr += sizeof(unsigned int);
(note the absence of *) and so on? I understand that we're supposedly
trying to increment butptf (a char*) by the size of the datum that we've
"stuffed" into it, so that the next datum is positioned at the next empty
byte. In this case the size of an unsigned int, and after the next
assignment, the size of a CLOCK, etc.; NOT the size of a pointer to
unsigned int, and then of a pointer to CLOCK - pointers are equally sized,
and you'd end up overwriting data when you're inserting a datum that is
sized larger than a pointer.
> After this, it compiles fine, and seems to run without problems,
> however I haven't done any networking from within VICE, so it could
> be erroneous. My C is a bit rusty, and I'm not sure whether the
> buffer pointer should be increased before or after the assignments
> in this case.
Definitely after the assignment - in the original code the ++ operator
goes after the operand, which means it's a post-increment.
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141736 is a reply to message #141730] |
Mon, 28 November 2005 12:56 |
Michael Klein
Messages: 17
Registered: February 2005
Karma: 0
|
Junior Member |
|
|
On Mon, 28 Nov 2005, silverdr wrote:
> P.S. I also know about a true OS X port coming. I saw the alpha running
> really fine - x64 only ATM :-( but very promising.
x128 is there as well (VICE->Machine) ;-)
And if you take a close look at VICE.app/Contents/MacOS/VICE you'll see
how you can even start all the other machines (which are unusable ATM,
mostly because of missing keyboard maps).
--
Michael
Thank you for not using Microsoft products
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141737 is a reply to message #141730] |
Mon, 28 November 2005 13:50 |
Golan Klinger
Messages: 559
Registered: December 2004
Karma: 0
|
Senior Member |
|
|
I feel silly about the last sentence of my post because I understand that
making a binary release is going to require more effort than compiling VICE
and gzipping up the results. It was the frustration talking. The reaosn I'm
so frustrated is that I'm not new to UNIX and compiling my own software. I
have never been stymied like this before. I'm a determined person so I gave
it another try last night and I finally got it to work. I removed quite a
few things and this was my first attempt at compiling 1.18 so I don't know
what it was I did that made it work. All that matters (for now) is that it
did work. I'm happy. I was inspired so I tinkered with the RS-232 settings
and managed to get connected to Quantum Link. Double happiness.
In exchange for the patience you've shown me, I would be glad to test any
thing packages you put together. I'm also going to sort out what I did and
make a detailed post on the offchance it helps someone else.
As for a true OS X port, that would be great. I would be equally willing
and interested to test that. :)
--
Golan Klinger
Dark is the suede that mows like a harvest.
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141738 is a reply to message #141735] |
Mon, 28 November 2005 14:30 |
David Horrocks
Messages: 34
Registered: December 2012
Karma: 0
|
Member |
|
|
"Eregil" <eregil@excite.com> wrote in message
news:pan.2005.11.28.17.08.42.531998@excite.com...
> Il Mon, 28 Nov 2005 12:20:29 +0000, Lars Haugseth ha scritto:
>
>> As a workaround I split each line into two statements, thus:
>>
>> *((unsigned int*)bufptr) = current_event->type;
>> bufptr += sizeof(unsigned int*);
>>
this code would be ok aslong as sizeof(unsigned int*) is always equal to
sizeof(unsigned int) which happens to be the case on 32 bit architectures
such as Windows 9x NT XP etc. There is a risk of failure with other
arhitectures or if sizeof(CLOCK) is not the same as sizeof(unsigned int *)
>> etc.
>
> Shouldn't this be
>
> bufptr += sizeof(unsigned int);
>
yes, i agree this is the correct translation.
*((unsigned int*)bufptr) = current_event->type;
bufptr += sizeof(unsigned int);
> (note the absence of *) and so on? I understand that we're supposedly
> trying to increment butptf (a char*) by the size of the datum that we've
> "stuffed" into it, so that the next datum is positioned at the next empty
> byte. In this case the size of an unsigned int, and after the next
> assignment, the size of a CLOCK, etc.; NOT the size of a pointer to
> unsigned int, and then of a pointer to CLOCK - pointers are equally sized,
> and you'd end up overwriting data when you're inserting a datum that is
> sized larger than a pointer.
>
>> After this, it compiles fine, and seems to run without problems,
>> however I haven't done any networking from within VICE, so it could
>> be erroneous. My C is a bit rusty, and I'm not sure whether the
>> buffer pointer should be increased before or after the assignments
>> in this case.
>
> Definitely after the assignment - in the original code the ++ operator
> goes after the operand, which means it's a post-increment.
>
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141739 is a reply to message #141727] |
Mon, 28 November 2005 15:22 |
iAN CooG
Messages: 613
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
iAN CooG <iancoog@despammed.com> wrote:
> Run/stop restore does not work more than once now.
Here is a quick'n'dirty workaround.
------8<------8<------8<------8<------8<------8<------8 <------8<------
--- keyboard.c Sat Nov 12 15:02:26 2005
+++ vice-1.18.mod\src\keyboard.c Mon Nov 28 11:42:03 2005
@@ -282,6 +282,7 @@
return;
/* Restore */
+ machine_set_restore_key(0); /* workaround 1.18 iAN CooG/HF */
if (((key == key_ctrl_restore1) || (key == key_ctrl_restore2))
&& machine_has_restore_key())
{
------8<------8<------8<------8<------8<------8<------8 <------8<------
--
-=[]=--- iAN CooG/HokutoForce ---=[]=-
Backup not found: (A)bort (R)etry (S)lap nearest innocent bystander.
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141740 is a reply to message #141736] |
Mon, 28 November 2005 17:57 |
Patryk 'Silver Dream
Messages: 737
Registered: July 2003
Karma: 0
|
Senior Member |
|
|
Michael Klein wrote:
> On Mon, 28 Nov 2005, silverdr wrote:
>
>> P.S. I also know about a true OS X port coming. I saw the alpha
>> running really fine - x64 only ATM :-( but very promising.
>
>
> x128 is there as well (VICE->Machine) ;-)
Yes, sure! I actually meant that but I wrote inaccurately. Sorry for that.
|
|
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141742 is a reply to message #141735] |
Tue, 29 November 2005 05:35 |
Lars Haugseth
Messages: 231
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
* Eregil <eregil@excite.com> wrote:
|
| Il Mon, 28 Nov 2005 12:20:29 +0000, Lars Haugseth ha scritto:
|
| > As a workaround I split each line into two statements, thus:
| >
| > *((unsigned int*)bufptr) = current_event->type;
| > bufptr += sizeof(unsigned int*);
| >
| > etc.
|
| Shouldn't this be
|
| bufptr += sizeof(unsigned int);
|
| (note the absence of *) and so on? I understand that we're supposedly
| trying to increment butptf (a char*) by the size of the datum that we've
| "stuffed" into it, so that the next datum is positioned at the next empty
| byte. In this case the size of an unsigned int, and after the next
| assignment, the size of a CLOCK, etc.; NOT the size of a pointer to
| unsigned int, and then of a pointer to CLOCK - pointers are equally sized,
| and you'd end up overwriting data when you're inserting a datum that is
| sized larger than a pointer.
You're absolutely correct, thanks for pointing it out.
| > After this, it compiles fine, and seems to run without problems,
| > however I haven't done any networking from within VICE, so it could
| > be erroneous. My C is a bit rusty, and I'm not sure whether the
| > buffer pointer should be increased before or after the assignments
| > in this case.
|
| Definitely after the assignment - in the original code the ++ operator
| goes after the operand, which means it's a post-increment.
Good, then my assumption was right in this regard. I haven't seen the
increment operator used on the left hand side of an assignment before,
hence my uncertainty of what happens first.
--
Lars Haugseth
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141743 is a reply to message #141742] |
Tue, 29 November 2005 05:44 |
Martijn van Buul
Messages: 326
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
It occurred to me that Lars Haugseth wrote in comp.emulators.cbm:
> Good, then my assumption was right in this regard. I haven't seen the
> increment operator used on the left hand side of an assignment before,
> hence my uncertainty of what happens first.
In case of
*(ptr++) = foo;
ptr gets increased after the assignment[1], in case of
*(++ptr) = foo;
it gets increased *before* the assigment.
Martijn
[1] For all nitpickers out there: Actually, it gets increased *before* the
assignment, but the old value of ptr is dereferenced.
--
Martijn van Buul - pino@dohd.org - http://www.stack.nl/~martijnb/
Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...' Isaac Asimov
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141858 is a reply to message #141739] |
Tue, 29 November 2005 05:50 |
Lars Haugseth
Messages: 231
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
* "iAN CooG" <iancoog@despammed.com> wrote:
|
| iAN CooG <iancoog@despammed.com> wrote:
| > Run/stop restore does not work more than once now.
|
| Here is a quick'n'dirty workaround.
| ------8<------8<------8<------8<------8<------8<------8 <------8<------
| --- keyboard.c Sat Nov 12 15:02:26 2005
| +++ vice-1.18.mod\src\keyboard.c Mon Nov 28 11:42:03 2005
| @@ -282,6 +282,7 @@
| return;
>
| /* Restore */
| + machine_set_restore_key(0); /* workaround 1.18 iAN CooG/HF */
| if (((key == key_ctrl_restore1) || (key == key_ctrl_restore2))
| && machine_has_restore_key())
| {
| ------8<------8<------8<------8<------8<------8<------8 <------8<------
Thanks!
Suggestion:
The function machine_set_restore_key() should probably not be called
unless machine_has_restore_key() is true, thus:
if (machine_has_restore_key())
{
machine_set_restore_key(0);
if ((key == key_ctrl_restore1) || (key == key_ctrl_restore2))
{
...
}
}
--
Lars Haugseth
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141859 is a reply to message #141743] |
Tue, 29 November 2005 13:19 |
David Horrocks
Messages: 34
Registered: December 2012
Karma: 0
|
Member |
|
|
One neat thing to note is that post fix operators ++ and -- have higher
precedence than pointer dereference.
Therefore
*(ptr++) = foo
is the same as
*ptr++ = foo
David
"Martijn van Buul" <pino@dohd.org> wrote in message
news:slrndooc8n.2ugi.pino@mud.stack.nl...
> It occurred to me that Lars Haugseth wrote in comp.emulators.cbm:
>> Good, then my assumption was right in this regard. I haven't seen the
>> increment operator used on the left hand side of an assignment before,
>> hence my uncertainty of what happens first.
>
> In case of
>
> *(ptr++) = foo;
>
> ptr gets increased after the assignment[1], in case of
>
> *(++ptr) = foo;
>
> it gets increased *before* the assigment.
>
> Martijn
>
> [1] For all nitpickers out there: Actually, it gets increased *before* the
> assignment, but the old value of ptr is dereferenced.
> --
> Martijn van Buul - pino@dohd.org - http://www.stack.nl/~martijnb/
> Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333
> The most exciting phrase to hear in science, the one that heralds new
> discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...' Isaac
> Asimov
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141860 is a reply to message #141859] |
Tue, 29 November 2005 14:34 |
Martijn van Buul
Messages: 326
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
It occurred to me that David Horrocks wrote in comp.emulators.cbm:
> One neat thing to note is that post fix operators ++ and -- have higher
> precedence than pointer dereference.
> Therefore
> *(ptr++) = foo
> is the same as
> *ptr++ = foo
I know, but experience at my job has shown me that many people *don't*
know the precedence rules as good as they should've (and some precendence
rules don't make sense). In addition to that, valid C++ can get rather
nasty and cryptical. So I accepted the habit of adding braces, if I think
it will increase readability for others. It's not as if those braces add
any additional run-time.
In this case, one could say that
*ptr++ = foo
really can't be read as
(*ptr)++ = foo
since this would be an illegal lvalue. But hey - never assume an overdose
of intelligence in cow-orkers ;)
Martijn
--
Martijn van Buul - pino@dohd.org - http://www.stack.nl/~martijnb/
Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...' Isaac Asimov
|
|
|
|
| Re: [ANNOUNCE] VICE 1.18 [message #141862 is a reply to message #141858] |
Wed, 30 November 2005 17:14 |
iAN CooG
Messages: 613
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Lars Haugseth <njus@larshaugseth.com> wrote:
> Suggestion:
> The function machine_set_restore_key() should probably not be called
> unless machine_has_restore_key() is true, thus:
Nicer that way ;)
Here are all the modifications applied so far, including a .tap file
selector fix to allow headers shorter than 193 bytes to be displayed.
http://iancoog.altervista.org/Winvice.htm
--
-=[]=--- iAN CooG/HokutoForce ---=[]=-
Un impegno concreto: piu' pleistescion per tutti
|
|
|
|
Members
Search
Help
Register
Login
Home
