Class objects work like built-in types, but is it worth it?

[Erik Wikström]

Ha! C++ is complexity incarnate! Pushing stuff into the compiler is
not reducing complexity, it's just moving it elsewhere.

First of all I do not agree that the complexity for the compiler is
increased by any significan amount (after all, every abstraction that
takes you away from assembly-language is added complexity) but
constructors and such are relatively simple.

Probably because you were more interested in "objects" being in
contiguous memory and performance. That's why I said built-in arrays
are different from "containers". Sure you can slap an interface on
anything, but the implementation issues are what this thread is
about, rather than just abstractions.

No, I was interested in storing a variable number of values and
accessing them in various ways. Sure, I could have used arrays instead
but then I would have to do all the book-keeping myself. By using pre-
existing containers I reduced the complexity of my code significantly,
and probably got better performance too.

The one who said "it means you need two sets of code" above someone
with the paradigm that containers are value-based things, probably
because of some kind of derivation of what a container is based upon
built-in arrays, which leads to "hence, class objects need to behave
like built-in types to be used by value-based containers", was why I
posed the "how many linked lists of integers..." question and
"theory" that value-based containers aren't even desireable mostly.

I will not speculate about his reasoning but I can say this: The fact
that the container can also handle class-types have been useful in some
situations (for example I can switch to debugging by just changing a
#define/typedef).

No what?

No, using linked list would not be a better example.

I would hope not.


Built in arrays are different beasts. It would probably not be
prudent to make the "raw materials of composition" (built-ins), class
objects. One can wrap those for more specific purposes.

Not sure what you mean here.

My original
question is still open. Maybe there are 2 (or more) types of classes:
those that behave like built-ins and those that are something else.
That "something else" being lightweight and not nearly as complex as
requiring compiler-called constructors and then exceptions to solve
the "problem" with constructors.

In my experience its the classes that do not behave as built-in types
that are the more complex ones (singletons, non-value semantics, etc.).

That's not topical though, and is paradigmical and a very
high-level/abstract "definition" (and even moreso, a definition of
"container interface" rather than "container").

No, definitely not a definition of a container interface. It's a
definition of a container in terms of an interface, i.e. the interface
specifies what a container is and everything that implements the
interface is a container.

Containers were brought into the discussion when someone said that
built-in-type-behavior of class objects is required so that
containers can be implemented, which of course is wrong in the
general sense.

Of course, but he only said that it is necessary to implement practical
and useful containers. As pointed out there are other ways of doing it,
such as using boxing and typecasting (generics can hide some of this
from the user but that is all).

 

[tonytech08]

First of all I do not agree that the complexity for the compiler is
increased by any significan amount (after all, every abstraction that
takes you away from assembly-language is added complexity) but
constructors and such are relatively simple.

It's not just compiler-called constructors. The compiler-called
constructors give rise to implementing exceptions, mentioned earlier
in this thread (probably more than once).

No, I was interested in storing a variable number of values and
accessing them in various ways. Sure, I could have used arrays instead
but then I would have to do all the book-keeping myself. By using pre-
existing containers I reduced the complexity of my code significantly,
and probably got better performance too.


I will not speculate about his reasoning but I can say this:  The fact
that the container can also handle class-types have been useful in some
situations (for example I can switch to debugging by just changing a
#define/typedef).

I was suggesting that handling built-ins as value-based containers was
probably the wrong design paradigm for containers and that shoehorns
class objects into a requirement to behave like built-ins (which is
not necessarily lucrative).

No, using linked list would not be a better example.

I disagree, just because of the characteristics that built-in arrays
exhibit which gives potential confusion. Indeed, I posed that value-
based container designs are probably a result of deriving,
conceptually, "container" from built-in array concepts.

Not sure what you mean here.

2 separate thoughts, should have been separated with paragraphs. 1.)
Built-in arrays and "containers" are not synonymous at a practical
level (sure if you wanted to be way abstract and talk about algoritms,
it might make sense, but in this thread, no.). 2.)Getting back to the
thread topic, making built-ins class objects is probably a bad idea.
But the topic ponders is making class objects behave like built-ins a
bad idea at some level also (?).

In my experience its the classes that do not behave as built-in types
that are the more complex ones (singletons, non-value semantics, etc.).

Maybe even most classes (?). If so, whether the subset of classes that
need built-in-like behavior justifies all the related machinery is the
question. Maybe it does, maybe it doesn't. Value-based containers
require some level of built-in type behavior from class objects and
that seems "too big of a pill to swallow" where simplicity/minimalness
is valued or the goal. I'm probably suggesting that classes should be
designed NOT as built-in types unless "it hurts not to" and that value-
based container "incompatibility" is "bad container design/
architecture" rather than a point to justify built-in behavior from
class objects.

No, definitely not a definition of a container interface.

Closer to that than of "container".

It's a
definition of a container in terms of an interface, i.e. the interface
specifies what a container is and everything that implements the
interface is a container.

Nah, that's just a behavioral specification. A container interface is
not a container just like a remote control is not a television. The
remote just allows interaction with it.

Of course, but he only said that it is necessary to implement practical
and useful containers.

Which also is not true.

 

[Juha Nieminen]

You said "forbid", not me. If you want to paraphrase my thought, it
would go something like the following: "why penalize everything for
the special case?".

Because having support for a vector which directly supports builtin
types as the element type makes it completely *free* for lists to do so
as well. It's not like std::list suffers from C++'s ability to handle
builtin types and user-defined classes in a similar way.

 

[Juha Nieminen]

Ha! C++ is complexity incarnate! Pushing stuff into the compiler is
not
reducing complexity, it's just moving it elsewhere.

It's better to have the complexity in the compiler than in the code
written by the programmer.

When a language is "simple", it often means that implementing many
programs with that language becomes complicated.

In this case a "simple language" is more a hindrance than an
advantage. It may be easier to learn, but programming becomes more
complicated.

 

[tonytech08]

  Because having support for a vector which directly supports builtin
types as the element type makes it completely *free* for lists to do so
as well.

It's not like std::list suffers from C++'s ability to handle
builtin types and user-defined classes in a similar way.

I guess not: if you contain pointers to objects. When you contain an
object by value though, you impose unnecessary requirements on their
classes.

 

[tonytech08]

  It's better to have the complexity in the compiler than in the code
written by the programmer.

It's better to not have the complexity at all.

 

[tonytech08]

If you don't need lists of ints, you just don't use them. It's that
simple. The library implementation of std::list is template code which
could not care less if you instantiate it with int or something else.

When would you _ever_ want to use containers with value semantics
other than
with pointers to objects? Probably containers where the promise is
"contiguous placement in memory" as in built-in arrays.

A std::list implementation handles everything as value objects (I believe
this is what you all mean by talking about behavior of built-in objects).
If the built-in objects and class objects followed different syntax or
semantics, then it would make life harder for both the library writers
and application programmers. So I don't see any penalty here whatsoever,
it's a win-win strategy.

Well the container topic got backed into here. The issue of this
thread are
class objects. Using a container (STL) with value sematics for a
object of
class type imposes unnecessary requirements on the class.

If some kind of objects do not follow value
sematics, one can use a std::list of pointers to them instead - pointers
are built-in objects and std::list works with them fine; if it wasn't it
would be a serious drawback indeed.

Yes. I should have said "use STL containers with class object value
semantics vs. pointer semantics" rather than bring up container
implementation.

Programming is an engineering discipline, and thus it is all about trade-
offs. The ideal languages by some criteria, like assembler or Lisp (or
even Ada) seem to not be so successful. In C++ there are lots of trade-
offs, and these are obviously placed elsewhere than in some other
languages. For example, templated code needs huge compilation times and
produces unreadable error messages, something what you just don't see in
interpreted languages like Javascript. However, I assure that those
tradeoffs have nothing to do with contructors-destructors-assignment
operatore, these are trivial to implement, compared to templates, virtual
inheritance, or exceptions

A point is that exceptions and constructors are pretty much a package
deal because the alternatives are ugly. Hence a reason to consider
"lightweight objects" for at least the common case and leave the
extensive
machinery for "heavyweight" act-like-built-in types classes. Numeric
types
like Complex may be a good case for the "necessity" of built-in
behavior.
How large is that subset of classes where "it hurts not to" have that
behavior? If it is relatively small compared to the entire set of
classes,
maybe in the name of providing good program design, another
abstraction
(like "lightweight class") is in order. At the extreme, of course,
jettisoning built-in-type-behavior could be reanalyzed (not for C++
anymore,
of course, but for a new language implementation).

mechanisms, and they could be done without
exceptions as well, albeit not so elegantly. I agree there are lot of
"features" in the language which should be better banned, but ability to
define value objects is definitely not one of those.

That concept though gives rise to more machinery though: exceptions.

 

[Juha Nieminen]

It's better to not have the complexity at all.

Too bad that's impossible. Programming is a complex thing.

 

[peter koch]

When would you _ever_ want to use containers with value semantics
other than
with pointers to objects? Probably containers where the promise is
"contiguous placement in memory" as in built-in arrays.

My containers almost always contain values, and it is only rarely that
I care about contiguous placement, although I (in the case of vector)
enjoy the performance benefits I get out of the good locality.

Well the container topic got backed into here. The issue of this
thread are
class objects. Using a container (STL) with value sematics for a
object of
class type imposes unnecessary requirements on the class.

Yes. Your objects must currently be assignable, but this is no big
deal. In my experience, objects that are not will normally not be
placed in a container, and if you have to do so anyway, there are
nice, ready solutions for you - use a shared pointer or a pointer
container from boost, for example.

[snip]

A point is that exceptions and constructors are pretty much a package
deal because the alternatives are ugly. Hence a reason to consider
"lightweight objects" for at least the common case and leave the
extensive
machinery for "heavyweight" act-like-built-in types classes.

I again fail to see your problem. constructors serve very useful
purposes, and so do exceptions, and only very little of it is related
to the fact that construction might fail. I could live with C++ having
no exceptions when it comes to constructors: it would be a little
ackward, but not a big problem. Exceptions have their biggest force
elsewhere, by allowing you to forget about errorhandling in major
parts of your code, allowing your code to be more compact and with a
clear flow. Constructors and destructors allows you to only care about
resource allocation in the design of your class, and not when the
class is used.
So all in all we have two features that allow us to write concise and
maintainable code. There is no cost for the developer, and there is no
runtime cost. So - again - what is the problem?

That concept though gives rise to more machinery though: exceptions.

Yes - and we are happy about this. Because this machinery saves us
from a lot of trouble. If you want a more manual language, there is
nothing wrong with using C, Assembler (or even Java ;-)).

/Peter

 

[Erik Wikström]

It's not just compiler-called constructors. The compiler-called
constructors give rise to implementing exceptions, mentioned earlier
in this thread (probably more than once).

Also mentioned earlier is the fact that constructors does not
necessitate exceptions. Examples of why one would want exceptions
regardless of the presence of constructors (or even objects) have been
given, as has examples of how one could have constructors without
exceptions.

I was suggesting that handling built-ins as value-based containers was
probably the wrong design paradigm for containers and that shoehorns
class objects into a requirement to behave like built-ins (which is
not necessarily lucrative).

And I suggested that it was not true.

In fact, if classes where to behave like built-in types we would not
have a need for constructors (since built-in types are not initialised
on creation) and thus, by your reasoning, no need for exceptions either.

2 separate thoughts, should have been separated with paragraphs. 1.)
Built-in arrays and "containers" are not synonymous at a practical
level (sure if you wanted to be way abstract and talk about algoritms,
it might make sense, but in this thread, no.).

At a practical level I think arrays are containers, you can store
objects in them. Or put another way, arrays contains (hint, hint) objects.

2.)Getting back to the thread topic, making built-ins class objects
is probably a bad idea.

Actually I think it's a good idea, then there will be no distinction
between built-in and user-defined types.

Or did you mean making user-defined types behave like built-ins? You
have been repeatedly claimed it to be a bad idea but I've yet to see any
convincing arguments. You have mentioned constructors and exceptions as
being problematic but as I pointed out earlier in this post that simply
does not hold.

But the topic ponders is making class objects behave like built-ins a
bad idea at some level also (?).

No, reducing the distinction between user-defined types and built-in
types simplifies the logical model, makes it easier to write reusable
code, easier to maintain and change code, and probably makes it easier
to implement also (since compilers and tools does not have to make any
distinction).

Maybe even most classes (?).

Yes, most classes behaves like value types. Especially those that I use
a log. Those that do not have value-semantics are more rarely used and
not so numerous. At least that's my experience.

If so, whether the subset of classes that need built-in-like behavior
justifies all the related machinery is the question.

Since the subset is the majority I think it is safe to assume it does.
Besides, you still have not shown that there is any extra "machinery"
needed (by extra I mean something that can not justify it's own
existence in isolation).

Maybe it does, maybe it doesn't. Value-based containers require some
level of built-in type behavior from class objects and that seems
"too big of a pill to swallow" where simplicity/minimalness is valued
or the goal.

Most programmers find it very intuitive and you usually don't have to do
anything to get the behaviour. On the other hand any other behaviour is
less intuitive and requires more manual labour. So it seems to me like
value-semantics is the simpler approach. Besides, you have to look at
the full picture. Having two classes of types is not minimalistic.

I'm probably suggesting that classes should be designed NOT as
built-in types unless "it hurts not to" and that value- based
container "incompatibility" is "bad container design/ architecture"
rather than a point to justify built-in behavior from class objects.

In general it does hurt not do have value-semantics for types. Even in
Java and C# where most types have reference-semantics people program as
if they had value-semantics, and the GC makes this transparent to the user.

If you want something else you will end up with a very different
programming paradigm. Perhaps you should try functional programming,
usually those languages does not allow you to change the value of an
object once it has been assigned.

Nah, that's just a behavioral specification. A container interface is
not a container just like a remote control is not a television. The
remote just allows interaction with it.

In my work we design nodes in networks (some might call them servers but
I don't think that's a good description) which communicate with each
other and other nodes in networks. The requirements on these nodes are
specified by a standardisation organisation and the way they are
specified are in they way they interact with other nodes in the
networks. In other words the specification of a node is a description of
its interfaces. What I want to say with this is that a specification of
behaviour can be a sufficient definition of a thing. So an interface
description of a container can be a definition of a container.

Which also is not true.

Says you, but who should I believe? A regular who's skills are
programming in general and C++ in particular I've witnessed, or you who
has so far only questioned what is more or less the collective opinion
among C++ programmers?

 

[Erik Wikström]

It's better to not have the complexity at all.

Show us a solution without complexity (or even just without the
complexity you claim comes from allowing user-defined types to behave
like built-in types).

 

[tonytech08]

Show us a solution without complexity (or even just without the
complexity you claim comes from allowing user-defined types to behave
like built-in types).

But I've given my train of thought on it a number of times already:
when you decide that class objects should have the capability to
behave like built-in types, that gives rise to compiler-called methods
(like constructors) which gives rise to exceptions.

 

[tonytech08]

tonytech08 <[email protected]> kirjutas:




Basically whenever when the objects are not polymorphic. Using pointers
instead of objects themselves adds a level of indirection with its own
complexity and problems, this should be avoided when not needed.

We'll have to agree to disagree on that.

Nah, you still have it backwards; if the class supports value semantics
one can have value-based containers of the objects (with simplified
semantics), *in addition* to pointer-based containers, which are still
there.

We'll have to agree to disagree on that also.

It appears you are claiming that if there are two good features fitting
nicely with each other, they should be both banned, for unfair
competition ;-)

Nothing like that.

One things I'd miss if there wasn't class objects that behave like
built-in types are those objects you can code up to do something like
release a lock no matter how the enclosing scope gets exited. What are
those things called? I'd probably be satisfied with only one of those
things though that I could wrap around other objects to get the same
effect.

 

[tonytech08]

  Too bad that's impossible.

For C++ it is, but not for some other language.

Programming is a complex thing.

With C++ it is. It doesn't have to be nearly so though.

 

[tonytech08]

When would you _ever_ want to use containers with value semantics
other than
with pointers to objects? Probably containers where the promise is
"contiguous placement in memory" as in built-in arrays.

My containers almost always contain values, and it is only rarely that
I care about contiguous placement, although I (in the case of vector)
enjoy the performance benefits I get out of the good locality.

Well the container topic got backed into here. The issue of this
thread are
class objects. Using a container (STL) with value sematics for a
object of
class type imposes unnecessary requirements on the class.

Yes. Your objects must currently be assignable, but this is no big
deal. In my experience, objects that are not will normally not be
placed in a container, and if you have to do so anyway, there are
nice, ready solutions for you - use a shared pointer or a pointer
container from boost, for example.

[snip]

A point is that exceptions and constructors are pretty much a package
deal because the alternatives are ugly. Hence a reason to consider
"lightweight objects" for at least the common case and leave the
extensive
machinery for "heavyweight" act-like-built-in types classes.

I again fail to see your problem. constructors serve very useful
purposes, and so do exceptions, and only very little of it is related
to the fact that construction might fail. I could live with C++ having
no exceptions when it comes to constructors: it would be a little
ackward, but not a big problem. Exceptions have their biggest force
elsewhere, by allowing you to forget about errorhandling in major
parts of your code, allowing your code to be more compact and with a
clear flow. Constructors and destructors allows you to only care about
resource allocation in the design of your class, and not when the
class is used.
So all in all we have two features that allow us to write concise and
maintainable code. There is no cost for the developer, and there is no
runtime cost. So - again - what is the problem?

I'm just wondering what minimum of features one could implement in a
language and still have something highly useable and approachable from
usage to tool implementation. The complexity in C++ seems to build
upon itself. And there are other tradeoffs too: the moment you put a
constructor in a class (other than a default one?), you no longer have
a POD.

Yes - and we are happy about this.

Not me.

Because this machinery saves us
from a lot of trouble.

It's only trouble because of the built-in type behavior. Otherwise it
would be handleable.

If you want a more manual language, there is
nothing wrong with using C, Assembler (or even Java ;-)).

Or a subset of C++, I know. I guess I should just build something
using the minimalist approach and then sit back and assess good or
bad.

 

[Juha Nieminen]

For C++ it is, but not for some other language.

What language? Haskell? Haha.

 

[tonytech08]

Also mentioned earlier is the fact that constructors does not
necessitate exceptions. Examples of why one would want exceptions
regardless of the presence of constructors (or even objects) have been
given, as has examples of how one could have constructors without
exceptions.

I'm not buying those arguments though.

And I suggested that it was not true.

We'll have to agree to disagree on that then probably.

In fact, if classes where to behave like built-in types we would not
have a need for constructors (since built-in types are not initialised
on creation) and thus, by your reasoning, no need for exceptions either.

Well let's not pick nits. The "built-in type-like behavior" then.

At a practical level I think arrays are containers, you can store
objects in them. Or put another way, arrays contains (hint, hint) objects..

That's not what I had in mind for the discussion in this thread
because the definition is too broad to be useful here. I'd like to
stop anymore discussion here about built-in arrays as I do plan on
letting this thread end in a reasonable amount of time without
bringing in "the meaning of life" and everything else.

Actually I think it's a good idea, then there will be no distinction
between built-in and user-defined types.

I think built-in types arise out of being things that are "native" to
hardware and are therefor fundamentally different than class types.
But that's a discussion for compiler writers and hardware engineers
rather than me. (Feel free to start another thread about that and I
will lurk there as I am curious to know more about that).

Or did you mean making user-defined types behave like built-ins? You
have been repeatedly claimed it to be a bad idea

No I haven't. I'm just trying to work out whether I can live without
that or not.

but I've yet to see any
convincing arguments. You have mentioned constructors and exceptions as
being problematic but as I pointed out earlier in this post that simply
does not hold.

I didn't call them problematic. I just said they may be more icing
than I want on the cake. I'm weighing the pros and cons and at this
point I'm not convinced I need compiler-called functions in certain
classes or any for that matter.

No, reducing the distinction between user-defined types and built-in
types simplifies the logical model, makes it easier to write reusable
code, easier to maintain and change code, and probably makes it easier
to implement also (since compilers and tools does not have to make any
distinction).

Well that's one opinion, good. Thanks. It's kind of "lofty" though
rather than scientific.

Yes, most classes behaves like value types.

Oh, I thought you were saying the opposite: tha most classes are not
value-type-like (which is what I think). I gave class Money and class
Complex as typical value-type-like classes and postulated that the
entire set of those kinds of classes was small relative to other
classes.

Especially those that I use
a log. Those that do not have value-semantics are more rarely used and
not so numerous. At least that's my experience.

It probably depends on the domain you program for. Obviously if you
are doing numerical programming you'd have a lot of those things.

Since the subset is the majority I think it is safe to assume it does.

I'm not convinced it is. Actually, I think it is the opposite (for
me). But really depends on what kind of software one is writing.

Besides, you still have not shown that there is any extra "machinery"
needed (by extra I mean something that can not justify it's own
existence in isolation).

I consider exceptions as "extra machinery" or at least that I have it
"on trial".

Most programmers find it very intuitive and you usually don't have to do
anything to get the behaviour.

you have to give up PODness.

On the other hand any other behaviour is
less intuitive and requires more manual labour.

Well have to agree to disagree on that.

So it seems to me like
value-semantics is the simpler approach. Besides, you have to look at
the full picture. Having two classes of types is not minimalistic.

In quantity (yes 2 is more than 1) but that is hardly an analysis. If
I can live without exceptions, that's a big potential deletion from a
compiler I'll bet. I'll bet something like that permeates compiler
code all over the place.

In general it does hurt not do have value-semantics for types.

Maybe. But having constructors, destructors, exceptions etc. like it
is in C++ is not the only way to do that. Whether an alternative will
give only a 80% but workable solution is not known (to me, yet).

Even in
Java and C# where most types have reference-semantics people program as
if they had value-semantics, and the GC makes this transparent to the user.

If you want something else you will end up with a very different
programming paradigm.

Not necessarily. Perhaps just a different implementation.

In my work we design nodes in networks (some might call them servers but- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -...

read more »

Ooops, a Google hiccup?

 

[tonytech08]

On 2008-10-28 23:21, tonytech08 wrote:


In my work we design nodes in networks (some might call them servers but
I don't think that's a good description) which communicate with each
other and other nodes in networks. The requirements on these nodes are
specified by a standardisation organisation and the way they are
specified are in they way they interact with other nodes in the
networks. In other words the specification of a node is a description of
its interfaces. What I want to say with this is that a specification of
behaviour can be a sufficient definition of a thing. So an interface
description of a container can be a definition of a container.

But would be an incorrect definition given the context of this thread.
Context matters.

Says you, but who should I believe?

I'm not here to convince you. I do things my own way and I have
containers that I use that are practical and useful. And obviously I
think they are more practical and useful than their STL equivalents.

A regular who's skills are
programming in general and C++ in particular I've witnessed, or you who
has so far only questioned what is more or less the collective opinion
among C++ programmers?

I just wanted to know what people though on the topic. I was hoping to
get some response from people who actually implement the language
rather than just users of it. And from people who are also good
inventors and have found other ways to skin the proverbial cat. (As in
"a better C++"). Surely if one just says "C++ is just fine" that
doesn't add anything toward discovery of anything new.

 

[tonytech08]

tonytech08 <[email protected]> kirjutas:












It seems that what you want is some kind of scripting language. At least
the scripting language developed by our company fulfills almost all
criteria. It has no means for defining new data types, so all types are
built-in. The built-in types include things like Image, Table and
Container. There are no script-defined constructors or destructors. There
is no pointer type. In the script everything looks value-based, but under
the hood almost everything is accessed via pointers. There are exceptions
though, and try/catch. And recently I added exactly what appears to be
your last wish: a MakeDestructor operation which just prepares a function
to be launched when exiting the current scope.

Curiously enough, the script language is itself implemented by quite a
large amount of C++ code, making heavy use of constructors, destructors,
inheritance, exceptions, templates and whatever. I cannot imagine of
doing it in some other language, the full C++ is just a *bare minimum*
for implementing this kind of project.

Actually, I have a bunch of macros that I use regularly to clean up C+
+ syntax. I'm probably going to have a bunch more in short order.
Eventually I may harness C++ enough to design a new language, probably
using C++ as the generated intermediate code.

I'm going to go to the D (language) site to remember what it was that
caused me to reject that over C++ (other than GC). I think it might
have been that everything is derived from Object (?). Certainly there
are some good ideas there that I may want to implement also.

 

[LR]

For C++ it is, but not for some other language.


With C++ it is. It doesn't have to be nearly so though.

I'm pretty sure that I do not understand this. I think I may not
understand because I may not understand what you mean by complexity.
Could you please explain what you mean by complexity?

Also:

How might it be possible to not have any complexity? Is this limited to
either the programming language itself, or the problem domain?

Why, according to you, is programming more complex with C++?

Is complexity bad? Why? And under what circumstances? Always?

Which computer language would be simpler in your estimation?

1) A single instruction: Flip the bit at <address1> and if the result is
zero branch to <address2> (Note this doesn't require an opcode.)

2) Two instructions:
a) Flip the bit at <address>
b) If the bit at <address1> is zero goto <address2>

If you had to program in one of the above languages, would you want to
add a macro language of some sort? Would this add or remove complexity
from the programs that you'd write?


Would you prefer to use a slide rule or an electronic calculator? Which
one is more complex? To implement? To use?

Is:
a += 3;
more complex or less than:
a = a + 3;


TIA


LR