Re: 6502 illegal opcodes questions

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

Paul Schlyter wrote:

> > 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.
>
> The point isn't whether the developers are lousy or good - the point
> (to the management) is whether one can get the product out the door
> more quickly.  Pasting old code in old-school mode is often quicker
> than reimplementing the old code in new-school mode.  That's what
> matters in a commercial situation: to meet the deadline - a deadline
> which often is quite tight because your company won the contract over
> its competitors.  Basically it's about promising amost more than you
> can keep later.

Pasting code in old-school mode is only very slightly more time
efficient that wrapping it with a method call (which you'd do anyway
with the old school approach) at the cost of allowing new school code
to be written old school ways. There's not much difference either way,
except long term cost.

> >> 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.
>
> Then you'll have to choose a language which indeed supports conditional
> compilation, and which e.g. doesn't enforce correct syntax on those pieces
> which shouldn't be compiled at that time.  In C and C++ you'll need
> the preprocessor for this. In Java, your only option is regular if statements.

No. In C++ you can leave C code as C, as you have link level
compatibility. There is no reason whatsoever to use the preprocessor in
C++ code.

> C++ isn't a pure OO langauge, and it never pretended to be.

It doesn't even support most of the features that make a language OO.
You've got OO like encapsulation, but this is more akin to ADT's on
steroids than OO.

> C++ tries to be a "do-everything" language.  You can do OO development
> in it and it works if you keep the discipline.  You can do non-OO
> development - that works too.  And you're quite backwards compatible
> to C.

Many would argue that you can't do everything with it. You can't do
dynamic binding (only late), you can't do reflection or introspection
or any other OO feature that requires runtime typing, which is to say,
all of the good ones :-)

I major annoyance to me is the hackery you have to pull to get dynamic
class loading to work.

> > 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++ :-)
>
> That's because you're trying to voilate the C++ type checking here.
> You must either switch to C, or do one of the following:

I'm not trying at all, it's a bit of legacy code that I need to use in
a C++ application ...

You can either update the code to suit the more modern language, or
compile the old code with a C compiler and link it. If it's well tested
code, that's what I'd do. This is the same approach as Java essentially
- you can link against C/C++ code if you must, or you can rewrite it.
It works in principle.

> >>> 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.
>
> In Java one could add some code for checking here, since efficiency
> isn't such a big concern anyway, and throw an exception in case the
> conversion caused an overflow.

I agree - there's a lot of things they could've added to make the
discrete type aspects of the langauge safer. Too late now - too much
code in the wild.

Matt