Re: 6502 illegal opcodes questions

["mdj" <mdj.mdj@gmail.com>]

Paul Schlyter wrote:

> However, an Object parameter requires to be given an actual object as
> its argument, right?  So you cannot pass it a primitive data type, such
> as an int or a double.

You can, thanks to autoboxing. What's actually going on is this:

void foo(Obect j ...) {}

is in reality

void foo(Object[] j)

if you then call foo with primitives, what actually happens is this:

int x = 1; int y = 2;

foo(x, y) actually translates to

foo({new Integer(x), new Integer(y)});

(Syntax might not be exact, I don't use the varargs myself that often,
and couldn't be bothered looking it up. but you get the point)

> That's the way to go if you want to integrate a piece of old code in a new,
> larger, application of course.  But I was more thinking of code which shouldn't
> be expanded but merely moved to a new platform and there behave as it did
> on the old platform.  It doesn't seem particularly productive to wrap your
> old C code into a Java wrapper which does nothing but executes that old C code...

Indeed. If you have a large application that's already written to a
standard that allows it to be portable, you keep maintaining it until
end of life. Unless the language it's written in becomes end of life
first :-)

My concern is the manner in which small libraries or copy/paste chunks
of code pollute the relatively portable space of newer languages. In
.NET, you can issue a keyword and switch into old-school mode. It
doesn't exactly provide an environment that encourages good design. Why
you would include features that good developers won't use is beyond me,
unless of course it's lousy developers you're catering to, which may
well be the point.

> I suppose you mean "the commercial world" when you say "the real
> world".  Yes, the commerical world is a continuous hectic race where
> there's not really any time to do solid work.  It's more important
> that the product is flashy and that it appears early.  Buggy?  Of
> course, but so what?  Let customer support take care of the
> complaining customers while we're developing the next product to
> appear early and being flashier still .... the lifetime of a software
> product is nowadays so short anyway.....

It's actually irrelevant what sector we speak of - productivity
enhancements are productivity enhancements. While there are sectors
where you can 'afford' the extra time investment required to develop in
legacy languages, there's little reason to do so.

> In such an environment it's probably best to throw away old code and
> let everyone reinvent their wheels once more .... with humps and bumps
> that there's no time to polish away.

In this case, the old wheel has humps and bumps with regards to
portability and security. Should we throw those away? Absolutely.

> > This is the real world effect of Microsofts design decision (pollute
> > the new language with old problems) versus the Java model. Still
> > hobbling with legacy for no reason whatsoever than a couple of very
> > poorly concieved design ideas. And ones that history has already shown
> > has a simple, clean solution.
> >
> > "Those who cannot learn from history are doomed to repeat it...."
>
> Actually, there are lots of people who do this, for their enjoyment.
> I'm referring to vintage computing of course, and this very newsgroup is
> part of that movement.
>
> Yep, it belongs to "the real world" too....

Of course, but when your platform isn't evolving you don't need
evolving development methodologies. The older techniques are adequate,
and in the case of the Apple II, a great deal of fun on such a
constrained environment. However, old techniques only scale so high,
and hit those limits. In the case of C/C++, those limits have been hit,
or close to it. There's still a large problem domain you use these
tools for, as it's the most appropriate. But many new problem domains
demand tools that have less restrictions, particularly in terms of
development time. Sometimes this involves using a slightly more
constrained language. Less is more!

> If C/C++ macros should be made aware of namespaces, should they also be
> made aware of other parts of the underlying langauge?  If so, which
> parts?  I think you'll have a can of worms there if you open that one....

This is precisely why it is advocated that constants, plus language
constructs be used for conditional compilation.

> Only if you're sloppy about your macro definitions.  If the macro is to
> have effect in only one source file, then you'll of course define it
> *after* all your #include's.  But what if that macro had been defined
> somewhere else already?  The compiler will immediately complain so you'll
> notice it soon enough - it can be handled in this way:

Sure. Eventually you reach the point where the manual on good coding
convention and style is larger than the language specification. At that
point, it's time to rethink, and use more appropriate tools.

> Unfortunately, Ruby interpreters aren't particularly common in web browsers.. :-)

Yeah, and Java VM's as well :-(

> Are you trying to say one can do something in C that cannot be done in C++ ?  :-)

:-) No, just that C++ style OO is 'broken'

But for the sake of being anal and including yet another example:

int x = 1;
void *p = &x;
int *i = p;
printf("The number was %d ", *i);

Won't work in C++ :-)

> > The things you're prevented from doing in Java are prevented because
> > they've proven to be more trouble than they're worth, and there are
> > other techniques which allow the same things to be implemented without
> > rehashing error-prone on non-portable paradigms.
>
> Such as unsigned integers or complex arithmetic?   <g>

unsigned types have error prone issues when casting from signed to
unsigned types of the same size in C/C++, as no conversion takes place.
You lose a little space efficiency without them but little else.

The case for operator overloading has been argued over and over.
Originally, it was argued that they unnecessarily complicated the
language, and the number of legitimate use cases for them is relatively
small. I tend to agree that the feature is overused in C++, but I don't
think that justifies removing it.

Many features originally left out have made appearances recently, and
it's likely to continue. I'd expect to see operator overloading appear.

Matt