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

[Road.Tang]

How valuable is it that class objects behave like built-in types? [....]

  How valuable do you consider 'std::string'? 'std:fstream?
  'std::complex'? All those container types? Function objects?
  Iterators? Thread classes? Automatic locks? ...?

  Schobi

Is it annoying when someone answers every response here? Is it rude
not to?

Anyway, the question isn't whether OO is good/bad. It's whether making
class objects behave like built-in types is overkill.

OO is OO.
So what does the world look like, if you trim the copy
constructor , assignment operator,etc,..
i can't imagine that if you doesn't supply the enough mechanism to
constructor a well-form object definition(i.e. class),
what such language can do.

Do you mean If C++ doesn't have expection, so when some failure
occurs in the object construction, it must return a value to indicate
error?
That still not solve the problem, constructor is called by compiler .
so how compiler behaviour when it get the error value.

Exception is mechanism to report problem, so we can make some
code, who be able to solve problem , to know the problem, and fix
it.
In most cases, (ok, assume constructor return the error cdoe), the
compiler can know the object problem easily, but it doens't know
who can solve the problem..


-Roadt

 

[tonytech08]

tonytech08 wrote:
How valuable is it that class objects behave like built-in types? [....]
  How valuable do you consider 'std::string'? 'std:fstream?
  'std::complex'? All those container types? Function objects?
  Iterators? Thread classes? Automatic locks? ...?
  Schobi

Is it annoying when someone answers every response here? Is it rude
not to?

Anyway, the question isn't whether OO is good/bad. It's whether making
class objects behave like built-in types is overkill.

OO is OO.

So it is.

So  what does the world look like, if  you trim the  copy
constructor , assignment operator,etc,..
i can't imagine  that if you doesn't supply the enough mechanism to
constructor a well-form object definition(i.e. class),
what such language can do.

Sounds like an "inside the box thought"!

Do you mean If  C++ doesn't have expection,  so when some failure
occurs in the object construction, it must return a value to indicate
error?

Another in the box thought, but no, investigate "all" the other
alternatives.

That still not solve the problem,  constructor is called by compiler .

That is just a C++-ism. And of course (?), in the spirit of C an C++,
YOU decide how to apply the mechanisms that are there and whether to
use them or not (or did the last decade move "language" into
"capitalist" realm. ("Rhetorical" essay question left for the
reader)).

so   how compiler behaviour when it get the error value.

Exception  is mechanism to report problem,  

Yes, one way.

so  we can make  some
code,  who be able to solve problem  ,  to know the problem, and fix
it.

Maybe you can, maybe you can't. Patterns of that scenario curiously
missing? Academics lazy or incompetent or bought off? (I'm not very
trusting).

In most cases, (ok, assume constructor return the error cdoe), the
compiler can know  the object problem easily,  but it doens't know
who can solve the problem..

Apparently, maybe it was a challenge. I'm not giving up my macros here
though.

 

[Bart van Ingen Schenau]

How valuable is it that class objects behave like built-in types?

I find that extremely valuable. It enables me to write drop-in
replacements for native types with some added functionality (for
example restricted or extended range of values).

I appears that the whole "constructor doesn't return a value because
they are called by the compiler" thing is to enable built-in-like
behavior for objects of class type.

Can you explain how "class objects behave like built-ins" and
"constructor does not return a value" are necessarily connected?
I don't see any reason why there could not be a language where class
objects don't behave in the same way as built-ins, but constructors
still don't return a value. In fact, there is such a language: Java.

The whole "compiler implicitly invokes a constructor" thing is there
to ensure that objects of class-type can be properly initialised.
Initialisation is a good thing.

That leads to the "necessity" for
the exception machinery so that errors from constructors can be
handled.

That is not true. Take for example a look as {i|o}fstream. If you pass
an invalid/non-existing file name to its constructor, no exception
will be thrown. Instead, the object goes into an error-state that you
can check for.
Other ways of handling errors in a constructor are also possible
without resorting to exceptions.

Is all that complexity worth it just to get built-in-like
behavior from class objects? Maybe a better architecture would be for
built-in types and class object types to be accepted as fundamentally
different animals and forego the extensive machinery required to
shoehorn class objects into being something they are not!

If a feature is useful to millions of C++ users, I don't mind a bit of
additional complexity for the dozen or so C++ implementors.

Bart v Ingen Schenau

 

[Erik Wikström]

Apparently though, it's not a should we/shouldn't we implement
exceptions in the language, it's they HAD to (which brings the obvious
question if that is the main reason. I do think it is the main reason,
for many developers don't use exceptions unless they have to, such as
in constructors, operators etc). Not to be argumentative though, I'm
trying to decide whether class objects behaving like built in types is
worth all the complexity that brings. Perhaps only certain (a very
small subset) classes should be coded as "orthodox canonical
form" (Coplien) classes that may need exceptions.

I think most here will agree (you among them) that OO-programming is a
better paradigm than earlier paradigm such as procedural programming. So
if we regard C++ from an OO perspective the question becomes the
reverse: "Should built-in types behave like objects?" Personally I
think that they should and I think that the current state of affairs is
sub-optimal.

Personally I have successfully (in my opinion at least) programmed
object oriented in C++ (and other languages) for a number of years now
and the majority of the exceptions thrown in my code does not come from
constructors or other constructs used to make objects behave like built-
in types. For me exceptions is a practical way of handling errors which
allows me to handle errors in the best place without the extra work
other methods require (such as passing return values back up the call
stack).

 

[peter koch]

It would be interesting to hear the designer expound about the
importance and value of giving class objects the capability to behave
like built-ins, and weighing that against the implementation "costs".

But there has already been loads of examples where the "objects are
values" is necessary. Also, you haven't yet explained to us what you
mean by "implementation costs". I see none. Are you thinking about
runtime costs (cpu, memory) or developer costs? To me this machinery
is necessary to easily write maintainable, robust and fast code. I
don't see the cost at all.

I think I'm convinced that class objects should be allowed to be stack
objects, but I'm no so sure that having class objects behave like
built-ins is that worthwhile.

Again: worthwhile how? What is your problem?

/Peter

 

[peter koch]

That I said that exceptions are a solution to the obvious problem of
handling errors in constructors (and operators, etc.), does not imply
how I feel about their use elsewhere. And discussion of exceptions is
pretty much off topic from the original question.

But you stated that exceptions were built for constructors, implying
that without them, their use would not be justified - and this is
wrong. Also, removing exceptions would indeed be possible, but would
require you to use an other type of errorhandling mechanism, e.g. by
setting a global variable or by having an errorcode contained in the
object. It is just not such a robust mechanism if you want to write
reliable software.

You could still have those though without coding them up to behave
like built-ins. And maybe they should be coded up that way. Maybe
those 2 examples make for good "built-in behavin'" class objects. But
maybe there is a line to be drawn as to where that pattern/paradigm is
used. It's not necessarily true that just because the machinery is
there for special purpose that the machinery should be used everywhere
and all of the time. (Though, which may be obvious, I'm pondering if
it would be painful or just a tad less convenient to use it nowhere
and never and thereby shrinking the implementation of the language way
down).

You don't have to let your classes behave like built-in types, that
would be silly.

 

[Juha Nieminen]

That of course is not correct.

Exactly how would you create code which can handle both builtin types
and user-defined classes if they don't behave in the same way? For
example, if user-defined classes couldn't support assignment (like
built-in types do), it would be rather difficult to create a generic
container which can handle them.

The only way would be to make generic containers only support
references/pointers and nothing else (which is the case in Java), in
which case you basically lose the ability to store built-in types
directly into the data container (you could only store pointers to
built-in values, not the values themselves).

Java people will tell you that Java generics do support built-in
types, but that's just a lie. They only support classes, period.

Maybe, if you adhere to one specific way of designing containers (?).

I want containers which can store built-in types without overhead. Of
course you can create other types of containers if you don't care about
the overhead.

The way STL containers are designed is not the only possibility. You
seem to be fixated on STL container designs/architecture. (?)

Well, tell me how you would implement a generic data container which
efficiently supports both built-in types and user-defined classes.

I don't know what that means or what you mean by it.

Maybe you should study a bit of object-oriented programming then?

It wouldn't change built-in efficiency in the least or in any way.

Exactly how would you create a generic data container which supports
both built-in types in the most efficient way possible *and*
user-defined classes if, as you suggest, the latter do not behave like
built-in types?

Did
you mean using those things from containers? Perhaps you are thinking
built-in arrays and not containers at all?

Built-in arrays *are* containers. The only difference is that they are
not dynamic, but that's irrelevant.

Anyways, I was not talking about arrays exclusively (nor did I have
them in mind at all when I wrote my post).

Whoa, I think you are overscoping the the original topic by a mile by
bringing in dynamic binding and loadable libraries!

I brought the issue because there are some programming languages where
built-in types behave exactly like classes: They are dynamically
allocated and dynamically bound, they can be specialized, and you can
perform delegation on them. Yet in most cases if you use built-in types
exclusively, without inheritance/delegation/whatever, the compiler is
able to optimize all that away and generate code which works with pure
built-in types. However, that kind of optimization is not possible in
C++ because of precompiled libraries, which is why it would be so
difficult to have builtins working like classes in C++ (while keeping
them efficient).

 

[tonytech08]

I find that extremely valuable. It enables me to write drop-in
replacements for native types with some added functionality (for
example restricted or extended range of values).

Yes, for things like numerical types, such as a Money class. Numerical
types seem to fit the mold moreso than other types, say string, but
string is probably an "in betweener" in that regard.

Can you explain how "class objects behave like built-ins" and
"constructor does not return a value" are necessarily connected?

Probably. But refering you to Coplien's "Advanced C++" book is
probably better. Stroustrup's books surely discuss the reasoning also.

I don't see any reason why there could not be a language where class
objects don't behave in the same way as built-ins, but constructors
still don't return a value. In fact, there is such a language: Java.

So, you're assuming that "constructors" are a given, and if so, then
you have already constrained your design choices.

The whole "compiler implicitly invokes a constructor" thing is there
to ensure that objects of class-type can be properly initialised.
Initialisation is a good thing.

Consider though, if one does that manually and constrains class object
usage somewhat, exceptions are not then a necessity.

That is not true. Take for example a look as {i|o}fstream. If you pass
an invalid/non-existing file name to its constructor, no exception
will be thrown. Instead, the object goes into an error-state that you
can check for.

Hmmm. I keep thinking about all the behind the scenes cases where
value types are passed as args to a function and copy constructors are
called. Yes, there are ways to avoid exceptions in certain cases as
you have said. But the reason C++ constructors don't return a value is
for those other cases where it is impossible (or nearly so?) to do
error handling at the point of the error. (Guru chat required here in
place of my practicianer perspective probably).

Other ways of handling errors in a constructor are also possible
without resorting to exceptions.

Yes. But a return value is not possible in C++, so that traditional
method is out the window.

If a feature is useful to millions of C++ users, I don't mind a bit of
additional complexity for the dozen or so C++ implementors.

Given the industry directions/acceptance today, has C++ hindered
progress as far as tools go? (Never mind, that is a separate thread).
I not pondering much, if anything, "new", indeed, Stroustrup
"pondered" in his own books along the same lines (kinda?). I think C++
is the best language out there today and has been for quite awhile. Do
I think it was ever as good as it could be? No. Do I think there is
room for yet another programming language? Yes. A "general purpose"
one? Maybe (probably). (Just thinking out loud).

 

[tonytech08]

I think most here will agree (you among them) that OO-programming is a
better paradigm than earlier paradigm such as procedural programming.

Well I like having objects (classes) available, yes. That's not to say
I don't also program procedurally. I just evaluate the problem and
create appropriately. Every C++ program starts up procedurally of
course (calls main, a function not belonging to an object).

So
if we regard C++ from an OO perspective the question becomes the
reverse: "Should built-in types behave like objects?"  

Good point. If it means deriving everything from "Object" as in
Smalltalk, I think the answer is no. I don't know enough about
representations of things like integers at the machine level to
address that. I am curious to know though (read, I wish I had that
knowledge).

? Personally I

think that they should and I think that the current state of affairs is
sub-optimal.

Well if fundamental inquiries don't bore you or aren't unworthy of
your time, do tell a little bit if it can be conveyed concisely (some
subjects can be short-circuite like that, I know). Not that I have
time to learn assembly or microcode, but that I can relate to it and
"get it" (as others may want to also).

Personally I have successfully (in my opinion at least) programmed
object oriented in C++ (and other languages) for a number of years now
and the majority of the exceptions thrown in my code does not come from
constructors or other constructs used to make objects behave like built-
in types.

My guess is that you probably avoid that situation, as do I which
kinda brought up the topic.

For me exceptions is a practical way of handling errors which
allows me to handle errors in the best place without the extra work
other methods require (such as passing return values back up the call
stack).

I was going to say something, but that would be off-topic and be yet
another topic about exeptions and error handling which has yet to be
perfected (a separate thread).

 

[tonytech08]

But there has already been loads of examples where the "objects are
values" is necessary.

And that's fine. But maybe those are now a known category of object
and reanalysis of what class objects are or should/should not be is in
order. Apparently _I'm_ thinking about it.

Also, you haven't yet explained to us what you
mean by "implementation costs". I see none. Are you thinking about
runtime costs (cpu, memory) or developer costs? To me this machinery
is necessary to easily write maintainable, robust and fast code. I
don't see the cost at all.

OK (facetiously): 'Write me a C++ compiler for your homework (due next
week)'. That's one. But that's not even the "main" one. I don't think
"it" has been obsessed over enough yet. C++ is very successful, but it
can still be "stillborn" in history relative to the potential.
Consider that a thing like variadic macros (yes, a thing from the
"dark side" preprocessor) could make an impact on the language. Is the
language "deficiant" that macros can correct it? Or is more expected
from a "general purpose" language today than was a decade++ ago?

Again: worthwhile how? What is your problem?

Well, my reasoning at the start followed this path: objects are to be
capable of behaving like built-in types, therefore constructors can't
return values, therefore exceptions are necessary. I may be picking
nits, I mean, I don't have to use constructors of course. But maybe
the whole "objects behaving like built-in types" has not been
thoroughly analyzed (or at least conveyed).

 

[tonytech08]

But you stated that exceptions were built for constructors, implying
that without them, their use would not be justified

That doesn't imply that so I will ignore your thought process on that.

You don't have to let your classes behave like built-in types, that
would be silly.

Indeed. But there's probably another programming language (sub)concept
in that thought!

 

[tonytech08]

  Exactly how would you create code which can handle both builtin types
and user-defined classes if they don't behave in the same way? For
example, if user-defined classes couldn't support assignment (like
built-in types do), it would be rather difficult to create a generic
container which can handle them.

It's up to you what you define "container" as. If you want to do "the
container owns the objects it contains" thing, that's fine. There's
more than one way to skin a cat and why is it so important to make
people boarding an airplane the same as cattle going to slaughter?

  The only way would be to make generic containers only support
references/pointers and nothing else (which is the case in Java), in
which case you basically lose the ability to store built-in types
directly into the data container (you could only store pointers to
built-in values, not the values themselves).

So? The latter is probably "bad".

  Java people will tell you that Java generics do support built-in
types, but that's just a lie. They only support classes, period.



  I want containers which can store built-in types without overhead. Of
course you can create other types of containers if you don't care about
the overhead.

"Overhead"? You are programming F15 realtime software? "General
purpose programming language" is obsolete?

  Well, tell me how you would implement a generic data container which
efficiently supports both built-in types and user-defined classes.

Why is that important?

  Maybe you should study a bit of object-oriented programming then?

Slam noted. (Not nice, btw).

  Exactly how would you create a generic data container which supports
both built-in types in the most efficient way possible *and*
user-defined classes if, as you suggest, the latter do not behave like
built-in types?

Why is that important?

  Built-in arrays *are* containers. The only difference is that they are
not dynamic, but that's irrelevant.

Ah, the "built-in type" arrays ARE containers. Well if you have a
paradigm about what a container is, then all thing will look like a
nail I guess.

  Anyways, I was not talking about arrays exclusively (nor did I have
them in mind at all when I wrote my post).



  I brought the issue because there are some programming languages where
built-in types behave exactly like classes: They are dynamically
allocated and dynamically bound, they can be specialized, and you can
perform delegation on them.

To me it sounds like you are saying that there are languages that
don't have ANY built-in types (which may not be a bad idea, I dunno).

 

[tonytech08]

tonytech08 wrote:
How valuable is it that class objects behave like built-in types? [....]
  How valuable do you consider 'std::string'? 'std:fstream?
  'std::complex'? All those container types? Function objects?
  Iterators? Thread classes? Automatic locks? ...?
  Schobi

Is it annoying when someone answers every response here? Is it rude
not to?

  I don't knwo what you're trying to say here.

I wasn't talking to you per se.

  You missed my point. All these are very convenient to use not
  because they're classes, but because they are designed to
  behave like built-in types.

But after pondering the responses here, maybe built-in types are the
"problem" (!). "Everything is an object" (but not a cosmic one), may
be the way to go. I know enough "low level" programming to hinder my
own progress probably. Maybe my initial question was wrong. Maybe I
should have asked: "Why do we still need built-in types?". Which of
course brings in the "hardware" folks. Software that programs the
hardware has been the paradigm. Time for software to influence
hardware?

 

[Erik Wikström]

Well I like having objects (classes) available, yes. That's not to say
I don't also program procedurally. I just evaluate the problem and
create appropriately. Every C++ program starts up procedurally of
course (calls main, a function not belonging to an object).


Good point. If it means deriving everything from "Object" as in
Smalltalk, I think the answer is no. I don't know enough about
representations of things like integers at the machine level to
address that. I am curious to know though (read, I wish I had that
knowledge).

Having every object derive from an Object base class is not necessary,
for some languages it makes things much easier such as C# and Java
(though they did not go all the way). I don't see the need for it in C++
and I do not think it is desirable either.

? Personally I

Well if fundamental inquiries don't bore you or aren't unworthy of
your time, do tell a little bit if it can be conveyed concisely (some
subjects can be short-circuite like that, I know). Not that I have
time to learn assembly or microcode, but that I can relate to it and
"get it" (as others may want to also).

It is not about machine code representations and stuff like that. What
I'm talking about is the fact the you have to write stuff like

std::numeric_limits<int>::max()

to get the highest representable value of an int, instead of just writing

int::max

just as if int was a class with a const static public member with the
largest representable value. I think that with modern compilers the
amount of work required to make something like the following perform
just as well as built-in types should be minimal.

class Int
{
int Val;
public:
static const int max;
static const int min;

Int() { }
Int(const int& i) : Val(i) {}
Int(const Int& i) : Val(i.Val) { }
Int& operator=(const int i) { Val = i; return *this; }
Int& operator=(const Int i) { Val = i.Val; return *this; }
operator int() { return Val; }

friend Int operator+(const Int& a, const Int& b)
{
return Int(a.Val + b.Val);
}
};

const int Int::max = std::numeric_limits<int>::max();
const int Int::min = std::numeric_limits<int>::min();

Some experimenting shows only small differences in the produces assembly
for addition of two Int objects and addition of two ints.

My guess is that you probably avoid that situation, as do I which
kinda brought up the topic.

No, I just do not end up in those kinds of situations, but I do suppose
it depends on what kinds of applications you are writing, and how you
wish to handle allocation-errors (I generally do not handle them).

 

[Erik Wikström]

It's up to you what you define "container" as. If you want to do "the
container owns the objects it contains" thing, that's fine. There's
more than one way to skin a cat and why is it so important to make
people boarding an airplane the same as cattle going to slaughter?

Meaning what? I see no connection between your proverbs and what Juha
Nieminen wrote.

So? The latter is probably "bad".

Which latter? The is only one.

"Overhead"? You are programming F15 realtime software? "General
purpose programming language" is obsolete?

If you can not program F15 realtime software (whatever that means) *and*
business software interfaces (and a lot of other types of software) in
the same language it is *not* a general purpose language. Performance
always matters.

Why is that important?

Because we use use such containers every day and have found them really
useful.

Slam noted. (Not nice, btw).


Why is that important?

Consistency is very important when writing software, we do not need the
additional complexity of having different containers for different
types. If you need to different containers (one for built-in types and
one for others) it means you need two sets of code, which meant you
double the amount of bugs, double the maintenance const, double the
things to keep track of, etc.

Ah, the "built-in type" arrays ARE containers. Well if you have a
paradigm about what a container is, then all thing will look like a
nail I guess.

Again the messed up proverbs. Yes, we have a definition of what a
container is. In short it is something which can contain one or more
other things and there are ways of accessing these things. Such as an array.

To me it sounds like you are saying that there are languages that
don't have ANY built-in types (which may not be a bad idea, I dunno).

Yes, that is what he is saying. Ruby is one such language (I think, I
have not studied it in detail), C# is another (it has value-types and
reference-types, but not built-in types).

 

[tonytech08]

Meaning what? I see no connection between your proverbs and what Juha
Nieminen wrote.

Simply, that there is more than one definition of "container". One is
free to architect them as they see fit. The "interfaces" and
implementations of differently architected container paradigms will
be, well, different! There need not be a copy constructor for a
pointer of course, for instance.

Which latter? The is only one.

"the latter" being value-based containers.

If you can not program F15 realtime software (whatever that means) *and*
business software interfaces (and a lot of other types of software) in
the same language it is *not* a general purpose language. Performance
always matters.



Because we use use such containers every day and have found them really
useful.

It may be mildly convenient, but hardly necessary or even important.

Consistency is very important when writing software, we do not need the
additional complexity of having different containers for different
types.

Pushing complexity to another area is just pushing it around rather
than finding an elegant solution. And yes, sometimes the elegant
solution has some amount of compromise to avoid that complexity. If
one is real anal about it, well, C++ the language may be what you end
up with? "Refactoring" the language may be in order (on alternative).

If you need to different containers (one for built-in types and
one for others) it means you need two sets of code, which meant you
double the amount of bugs, double the maintenance const, double the
things to keep track of, etc.

So, how many linked lists of integer values have you used in code? It
appears that not supporting built-in types for some containers would
encourage better programming practice (going by just that one
example).

Again the messed up proverbs. Yes, we have a definition of what a
container is. In short it is something which can contain one or more
other things and there are ways of accessing these things. Such as an array.

Array is a tricky one because there are built-in arrays which are
fundamentally different from a array "container". So to not muddle the
discussion with "corner cases", a different container abstraction,
such as linked list, would probably be better to use as an example.

I think I've noted before or above that if you start with the thought
that "a built-in array is a container", a perverted definition of
"container" will result. A built-in array is a type rather than a
container (by "my" definition of container anyway).

Yes, that is what he is saying. Ruby is one such language (I think, I
have not studied it in detail), C# is another (it has value-types and
reference-types, but not built-in types).

That may not be a bad idea, I don't have enough info on it yet to make
up my mind on it. Perhaps because it hasn't existed in isolation from
other paradigms. If JUST that was implemented in a language, and not
"high-leveling" of everything else (read, garbage collection, dynamic
typing etc) that might make those languages more palatable as GP
languages and give insight to the question whether built-in types are
necessary or at least whether they are necessary to expose.

 

[Thomas J. Gritzan]

"the latter" being value-based containers.

Whats wrong (or "bad") with value-based containers?
We use them all the time.

It may be mildly convenient, but hardly necessary or even important.

classes also are convenient, but not necessary/important. There are many
wide-spread languages without classes.

You question value-based containers in C++ but you didn't tell us what
you would propose as an alternative. How would you design a container?

Pushing complexity to another area is just pushing it around rather
than finding an elegant solution. And yes, sometimes the elegant
solution has some amount of compromise to avoid that complexity. If
one is real anal about it, well, C++ the language may be what you end
up with? "Refactoring" the language may be in order (on alternative).

Whats the complexity you want to avoid in the first place? The copy
constructors and copy assignment? You only need to define them, if the
compiler generated ones don't fit. If you can't define a copy
constructor (because the class is logically non-copyable), you can
forbid copying.

So, how many linked lists of integer values have you used in code? It
appears that not supporting built-in types for some containers would
encourage better programming practice (going by just that one
example).

Linked lists of ints? I guess 'none'. For ints, a std::vector would be a

Array is a tricky one because there are built-in arrays which are
fundamentally different from a array "container". So to not muddle the
discussion with "corner cases", a different container abstraction,
such as linked list, would probably be better to use as an example.

I think I've noted before or above that if you start with the thought
that "a built-in array is a container", a perverted definition of
"container" will result. A built-in array is a type rather than a
container (by "my" definition of container anyway).

A container is an abstract concept. An array is a specific instance of
this concept. A linked list is another kind of container.
What do you think a container is?

That may not be a bad idea, I don't have enough info on it yet to make
up my mind on it. Perhaps because it hasn't existed in isolation from
other paradigms. If JUST that was implemented in a language, and not
"high-leveling" of everything else (read, garbage collection, dynamic
typing etc) that might make those languages more palatable as GP
languages and give insight to the question whether built-in types are
necessary or at least whether they are necessary to expose.

To discuss this further, you would have to tell us what makes something
a "built-in type". What would be different, if an int in C++ wouldn't be
a built-in type?
In Ruby, for example, an integer (called Fixnum) is a class (because
every type is a class), but it is also a built-in type:

a = 5
c = a+7 # addition
5.to_s # converts 5 to string
7.type # evaluates to "Fixnum"

You can make classes feel like built-in types as in C++ by overloading
operators.

 

[Erik Wikström]

It may be mildly convenient, but hardly necessary or even important.

Says you, allow me to disagree.

Pushing complexity to another area is just pushing it around rather
than finding an elegant solution. And yes, sometimes the elegant
solution has some amount of compromise to avoid that complexity. If
one is real anal about it, well, C++ the language may be what you end
up with? "Refactoring" the language may be in order (on alternative).

To me it seems like we pushed the complexity all the way out of existence.

So, how many linked lists of integer values have you used in code? It
appears that not supporting built-in types for some containers would
encourage better programming practice (going by just that one
example).

Linked lists? None in any non-trivial program, but I've used vectors
(lots of them), heaps, stacks, and queues with integers.

Array is a tricky one because there are built-in arrays which are
fundamentally different from a array "container". So to not muddle the
discussion with "corner cases", a different container abstraction,
such as linked list, would probably be better to use as an example.

Sorry, but no. I use neither array or linked list as the definition of
what a container is, I think that both arrays and lists (as used in
functional languages) are containers.

I think I've noted before or above that if you start with the thought
that "a built-in array is a container", a perverted definition of
"container" will result. A built-in array is a type rather than a
container (by "my" definition of container anyway).

Actually if we say that an array is a container we say that it fulfils
the requirements of a container, not the the requirements of a container
is to be like an array. Or in OO terms: an array implements the
interface container, but there might be many other implementations of
the same interface.

 

[tonytech08]

Says you, allow me to disagree.

OK. (But you are wrong! Na-na! ).

To me it seems like we pushed the complexity all the way out of existence..

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

Linked lists? None in any non-trivial program, but I've used vectors
(lots of them), heaps, stacks, and queues with integers.

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.

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.

Sorry, but no.

No what?

I use neither array or linked list as the definition of
what a container is,

I would hope not.

I think that both arrays and lists (as used in
functional languages) are containers.

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. 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.

Actually if we say that an array is a container we say that it fulfils
the requirements of a container, not the the requirements of a container
is to be like an array. Or in OO terms: an array implements the
interface container, but there might be many other implementations of
the same interface.

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"). 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.

 

[tonytech08]

Whats wrong (or "bad") with value-based containers?
We use them all the time.

Well, as pertaining to the topic of this thread, they require some
level of built-in type behavior of class objects to be "contained" by
them.

classes also are convenient, but not necessary/important. There are many
wide-spread languages without classes.

I think the class concept IS important (read, it is to me in the OO
style of programming I choose to use). Why bring that up though? If
you want to be extreme, as you no doubt wanted to be, only life or
death situations are ever important, so please try not to post just to
be argumentative not adding anything relevent to the topic at hand,
thx. Every thread in clc++ shouldn't tangent off into endless
directions; rather, efforts should be made to stay on topic.

You question value-based containers in C++ but you didn't tell us what
you would propose as an alternative. How would you design a container?

No, I questioned the value of class objects behaving like built-in
types weighed against the machinery required to get that.

Whats the complexity you want to avoid in the first place? The copy
constructors and copy assignment? You only need to define them, if the
compiler generated ones don't fit. If you can't define a copy
constructor (because the class is logically non-copyable), you can
forbid copying.

That's turning around the question really. I'm out looking for a
simple(st) and (most) elegant solution. As in, "what is the minimum
machinery/mechanism needed to get class objects in support of OO
programming?". If there are "heavyweight" classes and "lightweight"
ones, maybe there are some programming design guidelines to apply at
the minimum, or maybe "refactoring" of the language itself may be a
good idea.

Linked lists of ints? I guess 'none'. For ints, a std::vector would be a
better default choice. But why should we forbid std::list<int>?

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?".

A container is an abstract concept.

A container _interface_ is an abstraction. But any given container
must indeed have an implementation. The interface is not the
container. The interface just allows you to work with the actual
container (the implementation). A remote control is not a television,
it just allows you to control the TV.

An array is a specific instance of
this concept. A linked list is another kind of container.
What do you think a container is?

See above for an idea.

To discuss this further, you would have to tell us what makes something
a "built-in type". What would be different, if an int in C++ wouldn't be
a built-in type?

Those are questions I posed to the lower-level guys in here as needed
elementary information that would help analyze the usefulness/
necessity/or-opposite of class objects behaving like built-in types.
Again though, the way you asked above is to turn around my original
question which is not should built-ins be of class type (which as
noted may work and does work in other languages) but rather how
valuable is it that class objects behave like built in types. Making
built-ins class types would be in the opposite direction of the goal
that spawned my question. If class objects aren't required to behave
like built-ins, or if a certain subset of these things we call "class
objects" don't have to, where is that line to be drawn and what
simplification potential does that bring (or other potential
benefits).