Re: 6502 illegal opcodes questions

[pausch@saaf.se (Paul Schlyter)]

In article <1149381913.929713.169160@i40g2000cwc.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Paul Schlyter wrote:
> 
> How so?

By making it possible to give a subroutine an argument of one type
while it expected that argument to be of another type.

>>> It's still frowned upon, in favour of using a constant plus
>>> if/else/switch constructs to do conditional compilation.
>>
>> That causes a problem: a source line which shouldn't be used in some
>> particular environment can also be a syntax error in such an environment.
> 
> Exactly. The point is to avoid these situations by design. There's no
> good reason to have machine dependencies within the same class in a OO
> language. That's poor design.

If you were to write your application from scratch today, that's the
way to go of course.  But have you ever heard about legacy code?  Code
reuse?  If not, welcome to the real world!  If an old working piece of
code can be made to run on a new platform with only some small changes
here and there, that might be preferable to rewriting it all from
scratch.  If so, conditional compilation is a better way to maintain
that code than to create two versions of what's essentially the same
code.

>> I dondt think one can talk about namespaces at all regarding macros in
>> preprocessors.  The preprocessor does not know what a namespace is. It
>> hardly knows anything about the underlying source language.  Heck, you
>> can even replace reserved words with macros -- try to do THAT using
>> the global namespace in a normal way.....
> 
> Why?

Because namespeces belong to the programming language, and macros know
nothing about the underlying language.  Macros is nothing by text
substitution.

> Namespaces are a natural extension present in most modern languages
> to avoid collisions that occur frequently in larger programs.
> Macro's being redefined by included headers from an unrelated piece of
> code is a real problem in C/C++ programs.

Macros by themselves don't generate external symbols though.  The linker
never sees the macro names.

I believe the biggest problem here is the mind of those programmers
who don't realize that they're acutally using two different languages
simultaneously when using C (or C++) with macros.  They believe they
program only in C (or C++), without realizing that the preprocessor really
is a language of itself, which obeys different rules.  Line breaks are
for instance insignificant in C and C++ - it's just another kind of
whitespace, nothing more.  But to the preprocessor in C and C++, line breaks
are quite significant since they terminate the preprocessor statement
(unless that line end with the "line continuation character" \).


> Of course, most good programmers utilise some form of poor-mans
> namespacing by prefixing their preprocessor names with something that's
> likely to be unique. This illustrates the point that the feature would
> be useful.

Note that the macros are "global" only over the source file, not over
the entire application.

>>> But then, many people want to treat Java as if it's C++ minus features,
>>> rather than the very different language that it is.
>>
>> These peope are wrong of course.  Java resembles C++ only
>> superficially, mostly by having similar syntax.  But the semantics
>> under that syntax is quite different, and more resembles
>> "strait-jacket languages" like Pascal --- of course with a lot of
>> features not available in Pascal.  I usually think of Java as "the
>> UCSD Pascal of our times": it has portable object code which must be
>> run on a virtual machine.  However, it is object oriented, it is net
>> aware, and it is 32-bit rather than 16-bit.  And Java is also a
>> subsystem, not a whole OS like UCSD Pascal was.
> 
> Straightjacket is a little harsh :-) If we're comparing Java to C++,
> it's really C++ that's the straightjacket language, by forcing you to
> make all binding decisions at compile time.
> 
> Semantically speaking Java is a lot more like Smalltalk than C++. It's
> a nice bridge between the dynamic world and the static world.

The other extreme could be represented by Javascript, where all typing
and binding is done at runtime, and where all objects are polymorphic.
 
> To me it's more like this: C++ is C, but with stricter type checking,
> and object oriented like extensions, staying within the realm of a
> static language with no runtime system or typing.
> 
> Java is C++ like in syntax, but is underneath a 'real' OO language,
> allowing dynamic binding, loading, etc, within a C++ like typing
> system. It's actually far more flexible than it first appears, but you
> have to think like an OO programmer.

The most important difference here is not what Java allows you to to,
but what Java prevents you to do.  In Java OO is mandatory while in
C++ it's an option.  You can even do OO programming in plain C,
although it means more work for the programmers -- e.g. the "this"
pointer must always be passed explicitly to methods, constructors and
destructors must be called explicitly, etc.

But there are ways out of OO in Java too, just wrap your
non-OO-program like this:

class programname
{
    <your non-OO-program, in one single source file, goes here>
}


> The only time the typing system annoys me is when I want to do
> something REALLY OO, with some fairly heavy reflection. The lack of
> syntactic sugar in the reflection API is at times most tedious, and
> results in code being very hard to read where it should be simple and
> concise.
> 
> To this day, I don't miss the implicit conversion between integer and
> boolean type that C/C++ programs use. This is the only area where
> Java's type checking is stricter. Other differences are feature
> removals as mentioned previously
> 
> Matt
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/