Class objects work like built-in types, but is it worth it?
tonytech08
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. That leads to the "necessity" for
the exception machinery so that errors from constructors can be
handled. 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!
Cupu
If I understand your question correctly I'd like to ask what values
would you like to get returned from a constructor?
Obviously since the constructor constructs an object you can receive
either a success or a failure?
Following that logic what happens to the object if the constructor
fails?
The answer to that should be that there is no object ... it couldn't
be constructed thus you have no object which a situation where an
exception looks like exactly the thing you'd want have.
That is, if there's no object force the user to treat that error
(rather than him forgetting to check the return value and segfault
sometime later for no apparent reason).
Erik Wikström
And what would you like "new MyClass()" to return?
--
Erik Wikström
tonytech08
OK, 2 responses and both are missing my question so I'll try to
rephrase and clarify. The question is about the value of class objects
behaving like built-in types: How valuable/beneficial/desireable is
that? Or more specifically, was it worth introducing all that
ancillary machinery (exceptions) to get that feature?
aceh...@gmail.com
> The question is about the value of class objects
> behaving like built-in types: How valuable/beneficial/desireable is
> that? Or more specifically, was it worth introducing all that
> ancillary machinery (exceptions) to get that feature?
I am not convinced that exceptions were introduced so that we could
say
MyType m;
I read the Design and Evolution of C++ a long time ago but don't
remember registering anything like that. Perhaps all objects could be
pointers and NULL could be returned?
MyType * m = new MyType();
aceh...@gmail.com
[I was going to add...]
Then we would have to check every object creation:
if (!m) // cannot continue
We wouldn't be able to chain function calls:
calculate(make_first(), make_second());
It should be done noisily:
FirstType * f = make_first();
if (!f) goto bail;
SecondType * s = make_second();
if (!s) goto bail;
calculate(f, s);
That would be C-like in a bad way. :)
Can you think of a better way without exceptions from constructors?
Ali
Erik Wikström
Yes, it is desirable to have objects look like built-in types. But you
do not have to have exceptions to do this, you could instead requiring a
failing constructor to construct the object into a failed state which
can be checked after construction:
MyObject obj;
if (obj.invalid())
{
// Handle situation
}
The reason for exceptions is that they allow for a much better and
simpler error handling than to old way of return-codes. In fact even
languages which does not have object might have exceptions (such as ML,
a functional language).
--
Erik Wikström
peter koch
What makes you believe that exceptions are useful only for catching
errors in constructors? On the contrary, exceptions are a general and
useful error-handling mechanism.
As for your original question, classes behaving like ordinary built-in
types are quite useful. Imagine not being able to have all the many
useful types available that naturally are perceived as value-types:
std::string, complex and the many containers such as std::vector.
/Peter
Hendrik Schober
> How valuable is it that class objects behave like built-in types? [...]
How valuable do you consider 'std::string'? 'std::ofstream?
'std::complex'? All those container types? Function objects?
Iterators? Thread classes? Automatic locks? ...?
Schobi
tonytech08
> On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.com> wrote:
>
> > The question is about the value of class objects
> > behaving like built-in types: How valuable/beneficial/desireable is
> > that? Or more specifically, was it worth introducing all that
> > ancillary machinery (exceptions) to get that feature?
>
> I am not convinced that exceptions were introduced so that we could
> say
>
> MyType m;
>
> I read the Design and Evolution of C++ a long time ago but don't
> remember registering anything like that.
example. Think about the following group of special "things" in a
class implemented to behave like a built-in type: default constructor,
copy constructor, assignment operator, destructor. Think about what
happens when you pass an object by value as a function argument.
Somehow, you have to handle potential errors from the copy
constructor. Solution: exceptions.
So more machinery than just exception to get built-in-type behavior:
default constructor, copy constructor, assignment operator,
destructor, compiler machinery to call these member functions. Is it
built-in-type behavior that lucrative to be worth all that?
> Perhaps all objects could be
> pointers and NULL could be returned?
>
> MyType * m = new MyType();
(Aside/separate topic: That would be Simula then, right? That would
bring up the question of whether class objects can be of local (stack)
objects (which performance and convenience decidedly agree they should
be able to be)).
aceh...@gmail.com
> On Oct 23, 12:44 pm, acehr...@gmail.com wrote:> On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.com> wrote:
> > MyType m;
>
> > I read the Design and Evolution of C++ a long time ago but don't
> > remember registering anything like that.
>
> "Behaving like built-in type" means much more than "MyType m;"
> example. Think about the following group of special "things" in a
> class implemented to behave like a built-in type: default constructor,
> copy constructor, assignment operator, destructor.
Because of some of those, classes are better than built-in types.
That's part of the reasons why built-in types are referred to as
"second class" types:
- default constructor: missing for built-in types
- assignment operator: not always what we want for built-in types
- destructor: empty for built-in types; not always what we want
> Think about what
> happens when you pass an object by value as a function argument.
> Somehow, you have to handle potential errors from the copy
> constructor. Solution: exceptions.
Yes, exceptions are a mechanism of handling errors. The alternative of
handing error codes from layer to layer is not better.
They are not for built-in type behavior.
> So more machinery than just exception to get built-in-type behavior:
> default constructor, copy constructor, assignment operator,
> destructor, compiler machinery to call these member functions. Is it
> built-in-type behavior that lucrative to be worth all that?
They are all very important features without any connection to trying
to be like built-in types. Those are basic operations on types that we
need. The reason that built-in types have those operations is because
they are fundamental operations.
If those features are not important enough, one could always use C for
a while and come back to C++. ;)
Ali
peter koch
> On Oct 23, 12:44 pm, acehr...@gmail.com wrote:> On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.com> wrote:
>
> > > The question is about the value of class objects
> > > behaving like built-in types: How valuable/beneficial/desireable is
> > > that? Or more specifically, was it worth introducing all that
> > > ancillary machinery (exceptions) to get that feature?
>
> > I am not convinced that exceptions were introduced so that we could
> > say
>
> > MyType m;
>
> > I read the Design and Evolution of C++ a long time ago but don't
> > remember registering anything like that.
>
> "Behaving like built-in type" means much more than "MyType m;"
> example. Think about the following group of special "things" in a
> class implemented to behave like a built-in type: default constructor,
> copy constructor, assignment operator, destructor. Think about what
> happens when you pass an object by value as a function argument.
> Somehow, you have to handle potential errors from the copy
> constructor. Solution: exceptions.
>
> So more machinery than just exception to get built-in-type behavior:
> default constructor, copy constructor, assignment operator,
> destructor, compiler machinery to call these member functions. Is it
> built-in-type behavior that lucrative to be worth all that?
These features are there to enable you to write solid code. Without
these, there is no easy way to write readable, robust code. For one
thing, the assignment operators and constructors ensure that your
objects remain consistent.
Also note that none of these are really needed: you could remove e.g.
the assignment operator and exceptions and still write something that
would look like C++ code, but the prize you pay is the burden you put
on all users of your classes. They would e.g. have to remember that
objects of your class should not be assigned to but should use a
special assignment function call, and they would have to be aware that
a constructed object might not have a valid state and might be
unusable and so on. It is a very high prize to pay for nothing but
some saved time for the compiler developers.
>
> > Perhaps all objects could be
> > pointers and NULL could be returned?
>
> > MyType * m = new MyType();
>
They could. But why would you want to impose such a large overhead on
us poor programmers?
/Peter
Juha Nieminen
> How valuable is it that class objects behave like built-in types?
Without that behavior you couldn't create, for example, generic data
containers which work with both built-in types and user-defined classes.
But since user-defined classes can be made to behave like built-in
types, that simplifies generic programming a great deal.
Without this feature there would be only two possible choices:
1) Generic containers cannot support built-in types, only user-defined
classes. This would not only seriously cripple the usefulness of such
containers, it would be a major setback in efficiency when you want to
use the container for built-in types. (Basically you would have to write
wrappers for all built-in types, with all of their drawbacks. AFAIK this
is the case in Java.)
2) Make built-in types work like classes. This means that all objects
are allocated dynamically and are dynamically bound (like they are in
some languages). While in some cases this would be a useful thing (which
is the reason why those some languages do it in the first place), this
would seriously hinder the efficiency of built-in types.
(And no, the compiler would not be able to optimize dynamic binding
etc. out of the built-in types in C++ because, among other things, it
must support precompiled and dynamically loadable libraries.)
Another somewhat related benefit is that it makes it easier to
abstract your code. For example:
typedef int MyIntegral;
If you use that type consistently for a specific role in your code,
and later you need to change it to something else, you can change just
that line and that's it. No need to change anything else.
If the type you need to change it to is too complex to be a built-in
type, you can replace it with a class, no problem.
tonytech08
> (Aside/separate topic: That would be Simula then, right? That would
> bring up the question of whether class objects can be of local (stack)
> objects (which performance and convenience decidedly agree they should
> be able to be)).
Which is, of course, info direct from D&E.
tonytech08
>
> - Show quoted text -
Surely you are not suggesting that constructors lack return values
other than because of the "ctors enable class objects to behave like
built-in types", are you? Because, I think, that is default
constructors main purpose (i.e., the reason they were implemented as
part of the language).
tonytech08
That's the simple case though. I'm sure the gurus here will be able to
come up with object temporary creation/lifetime where you as a
developer would not have even the opportunity to do such checking.
(And no, I'm not arguing the opposite of what I asked originally).
>
> The reason for exceptions is that they allow for a much better and
> simpler error handling than to old way of return-codes. In fact even
> languages which does not have object might have exceptions (such as ML,
> a functional language).
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.
tonytech08
> On 23 Okt., 19:38, tonytech08 <tonytec...@gmail.com> wrote:
>
>
>
>
>
> > On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
>
> > > On 2008-10-23 13:41, tonytech08 wrote:
>
> > > > How valuable is it that class objects behave like built-in types? 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. That leads to the "necessity" for
> > > > the exception machinery so that errors from constructors can be
> > > > handled. 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!
>
> > > And what would you like "new MyClass()" to return?
>
> > OK, 2 responses and both are missing my question so I'll try to
> > rephrase and clarify. The question is about the value of class objects
> > behaving like built-in types: How valuable/beneficial/desireable is
> > that? Or more specifically, was it worth introducing all that
> > ancillary machinery (exceptions) to get that feature?
>
> What makes you believe that exceptions are useful only for catching
> errors in constructors?
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.
> As for your original question, classes behaving like ordinary built-in
> types are quite useful. Imagine not being able to have all the many
> useful types available that naturally are perceived as value-types:
> std::string, complex and the many containers such as std::vector.
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).
tonytech08
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.
tonytech08
> On Oct 23, 2:09 pm, tonytech08 <tonytec...@gmail.com> wrote:
>
> > On Oct 23, 12:44 pm, acehr...@gmail.com wrote:> On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.com> wrote:
> > > MyType m;
>
> > > I read the Design and Evolution of C++ a long time ago but don't
> > > remember registering anything like that.
>
> > "Behaving like built-in type" means much more than "MyType m;"
> > example. Think about the following group of special "things" in a
> > class implemented to behave like a built-in type: default constructor,
> > copy constructor, assignment operator, destructor.
>
> Because of some of those, classes are better than built-in types.
> That's part of the reasons why built-in types are referred to as
> "second class" types:
>
> - default constructor: missing for built-in types
>
> - assignment operator: not always what we want for built-in types
>
> - destructor: empty for built-in types; not always what we want
>
> > Think about what
> > happens when you pass an object by value as a function argument.
> > Somehow, you have to handle potential errors from the copy
> > constructor. Solution: exceptions.
>
> Yes, exceptions are a mechanism of handling errors. The alternative of
> handing error codes from layer to layer is not better.
>
> They are not for built-in type behavior.
I'm going to ignore the tangent topic of exceptions for now.
>
> > So more machinery than just exception to get built-in-type behavior:
> > default constructor, copy constructor, assignment operator,
> > destructor, compiler machinery to call these member functions. Is it
> > built-in-type behavior that lucrative to be worth all that?
>
> They are all very important features without any connection to trying
> to be like built-in types. Those are basic operations on types that we
> need. The reason that built-in types have those operations is because
> they are fundamental operations.
You could be right, but I'm not sure what you are trying to say. I
suggested that the set of class functions known as default
constructor, copy constructor, assignment operator and destructor are
a direct result of the goal to enable class objects to behave like
built-in types. Further, that those are not even enough: then you have
to figure out a way to handle errors from those kinds of things, and
that leads directly to why exception handling is used in those.
>
> If those features are not important enough, one could always use C for
> a while and come back to C++. ;)
Or as few C++ COMPLEX features as possible unless it "hurts to bad"
not to while still using C++ features that are a bit more elegant?
tonytech08
> On 23 Okt., 23:09, tonytech08 <tonytec...@gmail.com> wrote:
>
>
>
>
>
> > On Oct 23, 12:44 pm, acehr...@gmail.com wrote:> On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.com> wrote:
>
> > > > The question is about the value of class objects
> > > > behaving like built-in types: How valuable/beneficial/desireable is
> > > > that? Or more specifically, was it worth introducing all that
> > > > ancillary machinery (exceptions) to get that feature?
>
> > > I am not convinced that exceptions were introduced so that we could
> > > say
>
> > > MyType m;
>
> > > I read the Design and Evolution of C++ a long time ago but don't
> > > remember registering anything like that.
>
> > "Behaving like built-in type" means much more than "MyType m;"
> > example. Think about the following group of special "things" in a
> > class implemented to behave like a built-in type: default constructor,
> > copy constructor, assignment operator, destructor. Think about what
> > happens when you pass an object by value as a function argument.
> > Somehow, you have to handle potential errors from the copy
> > constructor. Solution: exceptions.
>
> > So more machinery than just exception to get built-in-type behavior:
> > default constructor, copy constructor, assignment operator,
> > destructor, compiler machinery to call these member functions. Is it
> > built-in-type behavior that lucrative to be worth all that?
>
> These features are there to enable you to write solid code.
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".
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. I use the machinery too, but that's
because I learned it that way. Maybe it's just not all that necessary
and I don't know just because I haven't tried to build stuff without
it (maybe to answer my own question I'll have to build something,
avoid the heavy-lifting C++ features, come up with some new ways of
doing stuff and sit back and evaluate it afterwards). I was thinking
though that with all the experience in these rooms, someones have
already "been there, done that". But but by "been there, done that", I
don't mean "have C coding background", that's where I started too. I
mean someone who has used C++ for quite a few years and then
reassessed and tried other ways to "skin the cat".
> Without
> these, there is no easy way to write readable, robust code.
(I'll let everyone jump on you for that statement).
> For one
> thing, the assignment operators and constructors ensure that your
> objects remain consistent.
> Also note that none of these are really needed: you could remove e.g.
> the assignment operator and exceptions and still write something that
> would look like C++ code, but the prize you pay is the burden you put
> on all users of your classes. They would e.g. have to remember that
> objects of your class should not be assigned to but should use a
> special assignment function call, and they would have to be aware that
> a constructed object might not have a valid state and might be
> unusable and so on. It is a very high prize to pay for nothing but
> some saved time for the compiler developers.
At least that would be the "inside the box" perspective. ;)
tonytech08
> tonytech08 wrote:
> > How valuable is it that class objects behave like built-in types?
>
> Without that behavior you couldn't create, for example, generic data
> containers which work with both built-in types and user-defined classes.
That of course is not correct.
> But since user-defined classes can be made to behave like built-in
> types, that simplifies generic programming a great deal.
Maybe, if you adhere to one specific way of designing containers (?).
>
> Without this feature there would be only two possible choices:
>
> 1) Generic containers cannot support built-in types, only user-defined
> classes.
The way STL containers are designed is not the only possibility. You
seem to be fixated on STL container designs/architecture. (?)
> 2) Make built-in types work like classes. This means that all objects
> are allocated dynamically
That may not be a bad idea though if you say "container objects are
allocated from the heap" rather than as you said it which seems to
imply that ALL object everywhere and all the time must be heap
allocated.
> and are dynamically bound
I don't know what that means or what you mean by it.
> (like they are in
> some languages). While in some cases this would be a useful thing (which
> is the reason why those some languages do it in the first place), this
> would seriously hinder the efficiency of built-in types.
It wouldn't change built-in efficiency in the least or in any way. Did
you mean using those things from containers? Perhaps you are thinking
built-in arrays and not containers at all?
> (And no, the compiler would not be able to optimize dynamic binding
> etc. out of the built-in types in C++ because, among other things, it
> must support precompiled and dynamically loadable libraries.)
Whoa, I think you are overscoping the the original topic by a mile by
bringing in dynamic binding and loadable libraries!
Road.Tang
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
> On Oct 24, 10:11 am, tonytech08 <tonytec...@gmail.com> wrote:
>
>
>
>
>
> > On Oct 23, 4:01 pm, Hendrik Schober <spamt...@gmx.de> wrote:
>
> > > tonytech08 wrote:
> > > > How valuable is it that class objects behave like built-in types? [...]
>
> > > How valuable do you consider 'std::string'? 'std::ofstream?
> > > '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. :)
Hendrik Schober
> On Oct 23, 4:01 pm, Hendrik Schober <spamt...@gmx.de> wrote:
>> tonytech08 wrote:
>>> How valuable is it that class objects behave like built-in types? [...]
>> How valuable do you consider 'std::string'? 'std::ofstream?
>> '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.
> Anyway, the question isn't whether OO is good/bad. It's whether making
> class objects behave like built-in types is overkill.
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. That you can use to complex values
just as two built-in integer values doesn't logical follow
from OO alone. (Other OO langauges don't have this feature.)
It follows from ctors, dtors, operator overloading etc. -- in
short: all the machinery that makes it possible to create
types which behave like built-in types.
IME this is very valuable.
Schobi
Hendrik Schober
> On Oct 23, 1:12 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
>> On 2008-10-23 19:38, tonytech08 wrote:
>> Yes, it is desirable to have objects look like built-in types. But you
>> do not have to have exceptions to do this, you could instead requiring a
>> failing constructor to construct the object into a failed state which
>> can be checked after construction:
>>
>> MyObject obj;
>> if (obj.invalid())
>> {
>> // Handle situation
>> }
>
> That's the simple case though. I'm sure the gurus here will be able to
> come up with object temporary creation/lifetime where you as a
> developer would not have even the opportunity to do such checking.
> (And no, I'm not arguing the opposite of what I asked originally).
This doesn't need a guru. Just wrap a bunch of those in some
other class and write a ctor for the latter which explicitly
initializes the whole bunch in its initializer list. Then
check them all manually.
> [...]
Schobi
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
> On Oct 23, 1:12 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
>> On 2008-10-23 19:38, tonytech08 wrote:
>>
>>
>>
>>
>>
>> > On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
>> >> On 2008-10-23 13:41, tonytech08 wrote:
>>
>> >> > How valuable is it that class objects behave like built-in types? 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. That leads to the "necessity" for
>> >> > the exception machinery so that errors from constructors can be
>> >> > handled. 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!
>> The reason for exceptions is that they allow for a much better and
>> simpler error handling than to old way of return-codes. In fact even
>> languages which does not have object might have exceptions (such as ML,
>> a functional language).
>
> 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).
--
Erik Wikström
peter koch
> On Oct 23, 5:05 pm, peter koch <peter.koch.lar...@gmail.com> wrote:
> > On 23 Okt., 23:09, tonytech08 <tonytec...@gmail.com> wrote:
>
> > > On Oct 23, 12:44 pm, acehr...@gmail.com wrote:> On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.com> wrote:
> > > "Behaving like built-in type" means much more than "MyType m;"
> > > example. Think about the following group of special "things" in a
> > > class implemented to behave like a built-in type: default constructor,
> > > copy constructor, assignment operator, destructor. Think about what
> > > happens when you pass an object by value as a function argument.
> > > Somehow, you have to handle potential errors from the copy
> > > constructor. Solution: exceptions.
>
> > > So more machinery than just exception to get built-in-type behavior:
> > > default constructor, copy constructor, assignment operator,
> > > destructor, compiler machinery to call these member functions. Is it
> > > built-in-type behavior that lucrative to be worth all that?
>
> > These features are there to enable you to write solid code.
>
> 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
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.
>
> > As for your original question, classes behaving like ordinary built-in
> > types are quite useful. Imagine not being able to have all the many
> > useful types available that naturally are perceived as value-types:
> > std::string, complex and the many containers such as std::vector.
>
> 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
> On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> tonytech08 wrote:
>>> How valuable is it that class objects behave like built-in types?
>> Without that behavior you couldn't create, for example, generic data
>> containers which work with both built-in types and user-defined classes.
>
> 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.
>> But since user-defined classes can be made to behave like built-in
>> types, that simplifies generic programming a great deal.
>
> 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.
>> Without this feature there would be only two possible choices:
>>
>> 1) Generic containers cannot support built-in types, only user-defined
>> classes.
>
> 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.
>> and are dynamically bound
>
> I don't know what that means or what you mean by it.
Maybe you should study a bit of object-oriented programming then?
>> (like they are in
>> some languages). While in some cases this would be a useful thing (which
>> is the reason why those some languages do it in the first place), this
>> would seriously hinder the efficiency of built-in types.
>
> 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).
>> (And no, the compiler would not be able to optimize dynamic binding
>> etc. out of the built-in types in C++ because, among other things, it
>> must support precompiled and dynamically loadable libraries.)
>
> 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
<Bart.van.Ingen.Sche...@ict.nl> wrote:
> On Oct 23, 1:41 pm, tonytech08 <tonytec...@gmail.com> wrote:
>
> > 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).
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.
>
> > 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?
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 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.
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.
>
> > 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.
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
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
> On 24 Okt., 04:38, tonytech08 <tonytec...@gmail.com> wrote:
>
>
>
>
>
> > On Oct 23, 5:05 pm, peter koch <peter.koch.lar...@gmail.com> wrote:
> > > On 23 Okt., 23:09, tonytech08 <tonytec...@gmail.com> wrote:
>
> > > > On Oct 23, 12:44 pm, acehr...@gmail.com wrote:> On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.com> wrote:
> > > > "Behaving like built-in type" means much more than "MyType m;"
> > > > example. Think about the following group of special "things" in a
> > > > class implemented to behave like a built-in type: default constructor,
> > > > copy constructor, assignment operator, destructor. Think about what
> > > > happens when you pass an object by value as a function argument.
> > > > Somehow, you have to handle potential errors from the copy
> > > > constructor. Solution: exceptions.
>
> > > > So more machinery than just exception to get built-in-type behavior:
> > > > default constructor, copy constructor, assignment operator,
> > > > destructor, compiler machinery to call these member functions. Is it
> > > > built-in-type behavior that lucrative to be worth all that?
>
> > > These features are there to enable you to write solid code.
>
> > 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.
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?
>
> > 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?
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
That doesn't imply that so I will ignore your thought process on that.
> > > As for your original question, classes behaving like ordinary built-in
> > > types are quite useful. Imagine not being able to have all the many
> > > useful types available that naturally are perceived as value-types:
> > > std::string, complex and the many containers such as std::vector.
>
> > 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.
Indeed. But there's probably another programming language (sub)concept
in that thought!
tonytech08
> tonytech08 wrote:
> > On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> tonytech08 wrote:
> >>> How valuable is it that class objects behave like built-in types?
> >> Without that behavior you couldn't create, for example, generic data
> >> containers which work with both built-in types and user-defined classes.
>
> > 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.
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.
>
> >> But since user-defined classes can be made to behave like built-in
> >> types, that simplifies generic programming a great deal.
>
> > 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.
"Overhead"? You are programming F15 realtime software? "General
purpose programming language" is obsolete?
>
> >> Without this feature there would be only two possible choices:
>
> >> 1) Generic containers cannot support built-in types, only user-defined
> >> classes.
>
> > 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.
Why is that important?
>
> >> and are dynamically bound
>
> > I don't know what that means or what you mean by it.
>
> Maybe you should study a bit of object-oriented programming then?
Slam noted. (Not nice, btw).
>
> >> (like they are in
> >> some languages). While in some cases this would be a useful thing (which
> >> is the reason why those some languages do it in the first place), this
> >> would seriously hinder the efficiency of built-in types.
>
> > 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?
Why is that important?
>
> > 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.
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).
>
> >> (And no, the compiler would not be able to optimize dynamic binding
> >> etc. out of the built-in types in C++ because, among other things, it
> >> must support precompiled and dynamically loadable libraries.)
>
> > 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.
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:
> > On Oct 23, 4:01 pm, Hendrik Schober <spamt...@gmx.de> wrote:
> >> tonytech08 wrote:
> >>> How valuable is it that class objects behave like built-in types? [...]
> >> How valuable do you consider 'std::string'? 'std::ofstream?
> >> '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.
>
> > Anyway, the question isn't whether OO is good/bad. It's whether making
> > class objects behave like built-in types is overkill.
>
> 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
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
>> 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).
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.
>> 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.
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
Erik Wikström
> On Oct 24, 4:25 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> tonytech08 wrote:
>> > On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> >> tonytech08 wrote:
>> >>> How valuable is it that class objects behave like built-in types?
>> >> Without that behavior you couldn't create, for example, generic data
>> >> containers which work with both built-in types and user-defined classes.
>>
>> > 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.
>
> 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.
>> 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".
Which latter? The is only one.
>> Java people will tell you that Java generics do support built-in
>> types, but that's just a lie. They only support classes, period.
>>
>> >> But since user-defined classes can be made to behave like built-in
>> >> types, that simplifies generic programming a great deal.
>>
>> > 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.
>
> "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.
>> >> Without this feature there would be only two possible choices:
>>
>> >> 1) Generic containers cannot support built-in types, only user-defined
>> >> classes.
>>
>> > 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.
>
> Why is that important?
Because we use use such containers every day and have found them really
useful.
>> >> and are dynamically bound
>>
>> > I don't know what that means or what you mean by it.
>>
>> Maybe you should study a bit of object-oriented programming then?
>
> Slam noted. (Not nice, btw).
>
>>
>> >> (like they are in
>> >> some languages). While in some cases this would be a useful thing (which
>> >> is the reason why those some languages do it in the first place), this
>> >> would seriously hinder the efficiency of built-in types.
>>
>> > 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?
>
> 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.
>> > 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.
>
> 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.
>> Anyways, I was not talking about arrays exclusively (nor did I have
>> them in mind at all when I wrote my post).
>>
>> >> (And no, the compiler would not be able to optimize dynamic binding
>> >> etc. out of the built-in types in C++ because, among other things, it
>> >> must support precompiled and dynamically loadable libraries.)
>>
>> > 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.
>
> 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).
--
Erik Wikström
tonytech08
> On 2008-10-26 05:07, tonytech08 wrote:
>
>
>
>
>
> > On Oct 24, 4:25 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> tonytech08 wrote:
> >> > On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> >> tonytech08 wrote:
> >> >>> How valuable is it that class objects behave like built-in types?
> >> >> Without that behavior you couldn't create, for example, generic data
> >> >> containers which work with both built-in types and user-defined classes.
>
> >> > 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.
>
> > 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.
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.
>
> >> 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".
>
> Which latter? The is only one.
"the latter" being value-based containers.
>
> >> Java people will tell you that Java generics do support built-in
> >> types, but that's just a lie. They only support classes, period.
>
> >> >> But since user-defined classes can be made to behave like built-in
> >> >> types, that simplifies generic programming a great deal.
>
> >> > 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.
>
> > "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.
>
> >> >> Without this feature there would be only two possible choices:
>
> >> >> 1) Generic containers cannot support built-in types, only user-defined
> >> >> classes.
>
> >> > 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.
>
> > Why is that important?
>
> 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.
> >> >> and are dynamically bound
>
> >> > I don't know what that means or what you mean by it.
>
> >> Maybe you should study a bit of object-oriented programming then?
>
> > Slam noted. (Not nice, btw).
>
> >> >> (like they are in
> >> >> some languages). While in some cases this would be a useful thing (which
> >> >> is the reason why those some languages do it in the first place), this
> >> >> would seriously hinder the efficiency of built-in types.
>
> >> > 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?
>
> > 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.
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).
>
> >> > 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.
>
> > 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.
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).
> >> Anyways, I was not talking about arrays exclusively (nor did I have
> >> them in mind at all when I wrote my post).
>
> >> >> (And no, the compiler would not be able to optimize dynamic binding
> >> >> etc. out of the built-in types in C++ because, among other things, it
> >> >> must support precompiled and dynamically loadable libraries.)
>
> >> > 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.
>
> > 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).
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
> On Oct 26, 2:49 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
>> On 2008-10-26 05:07, tonytech08 wrote:
>>> On Oct 24, 4:25 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>>>> 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".
>> Which latter? The is only one.
>
> "the latter" being value-based containers.
Whats wrong (or "bad") with value-based containers?
We use them all the time.
>>>>>> Without this feature there would be only two possible choices:
>>>>>> 1) Generic containers cannot support built-in types, only user-defined
>>>>>> classes.
>>>>> 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.
>>> Why is that important?
>> 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.
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?
>>>>>> and are dynamically bound
>>>>> I don't know what that means or what you mean by it.
>>>> Maybe you should study a bit of object-oriented programming then?
>>> Slam noted. (Not nice, btw).
>>>>>> (like they are in
>>>>>> some languages). While in some cases this would be a useful thing (which
>>>>>> is the reason why those some languages do it in the first place), this
>>>>>> would seriously hinder the efficiency of built-in types.
>>>>> 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?
>>> 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.
>
> 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.
>> 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).
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>?
>>>>> 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.
>>> 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.
>
> 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?
>>>> Anyways, I was not talking about arrays exclusively (nor did I have
>>>> them in mind at all when I wrote my post).
>>>>>> (And no, the compiler would not be able to optimize dynamic binding
>>>>>> etc. out of the built-in types in C++ because, among other things, it
>>>>>> must support precompiled and dynamically loadable libraries.)
>>>>> 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.
>>> 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).
>
> 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.
--
Thomas
Erik Wikström
> On Oct 26, 2:49 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
>> On 2008-10-26 05:07, tonytech08 wrote:
>> > On Oct 24, 4:25 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> >> tonytech08 wrote:
>> >> > On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> >> >> tonytech08 wrote:
>> >> >>> How valuable is it that class objects behave like built-in types?
>> >> >> Without this feature there would be only two possible choices:
>>
>> >> >> 1) Generic containers cannot support built-in types, only user-defined
>> >> >> classes.
>>
>> >> > 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.
>>
>> > Why is that important?
>>
>> 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.
Says you, allow me to disagree.
>> >> >> (like they are in
>> >> >> some languages). While in some cases this would be a useful thing (which
>> >> >> is the reason why those some languages do it in the first place), this
>> >> >> would seriously hinder the efficiency of built-in types.
>>
>> >> > 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?
>>
>> > 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.
>
> 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.
>> 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).
Linked lists? None in any non-trivial program, but I've used vectors
(lots of them), heaps, stacks, and queues with integers.
>> >> > 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.
>>
>> > 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.
>
> 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.
--
Erik Wikström
tonytech08
> On 2008-10-28 16:00, tonytech08 wrote:
>
>
>
>
>
> > On Oct 26, 2:49 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> >> On 2008-10-26 05:07, tonytech08 wrote:
> >> > On Oct 24, 4:25 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> >> tonytech08 wrote:
> >> >> > On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> >> >> tonytech08 wrote:
> >> >> >>> How valuable is it that class objects behave like built-in types?
> >> >> >> Without this feature there would be only two possible choices:
>
> >> >> >> 1) Generic containers cannot support built-in types, only user-defined
> >> >> >> classes.
>
> >> >> > 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.
>
> >> > Why is that important?
>
> >> 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.
>
> Says you, allow me to disagree.
OK. (But you are wrong! Na-na! ;) ).
> >> >> >> (like they are in
> >> >> >> some languages). While in some cases this would be a useful thing (which
> >> >> >> is the reason why those some languages do it in the first place), this
> >> >> >> would seriously hinder the efficiency of built-in types.
>
> >> >> > 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?
>
> >> > 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.
>
> > 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.
Ha! C++ is complexity incarnate! Pushing stuff into the compiler is
not
reducing complexity, it's just moving it elsewhere.
> >> 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).
>
> 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.
> >> >> > 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.
>
> >> > 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.
>
> > 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.
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.
> > 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.
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
wrote:
> tonytech08 wrote:
> > On Oct 26, 2:49 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> >> On 2008-10-26 05:07, tonytech08 wrote:
> >>> On Oct 24, 4:25 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >>>> 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".
> >> Which latter? The is only one.
>
> > "the latter" being value-based containers.
>
> 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.
>
> >>>>>> Without this feature there would be only two possible choices:
> >>>>>> 1) Generic containers cannot support built-in types, only user-defined
> >>>>>> classes.
> >>>>> 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.
> >>> Why is that important?
> >> 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.
>
> 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.
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.
> >> 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).
>
> 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?".
> >>>>> 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.
> >>> 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.
>
> > 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.
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.
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).
Erik Wikström
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.
>> >> 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).
>>
>> 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.
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).
>> >> >> > 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.
>>
>> >> > 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.
>>
>> > 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.
>
> No what?
No, using linked list would not be a better example.
>> 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.
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.).
>> > 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.
>
> 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).
--
Erik Wikström
tonytech08
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).
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).
>
> >> >> >> > 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.
>
> >> >> > 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.
>
> >> > 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.
>
> > No what?
>
> 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.
>
> >> 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.
>
> 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 (?).
>
> > 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.).
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.
>
> >> > 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.
>
> > 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.
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.
>
> > 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.
Which also is not true.
Juha Nieminen
>> 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?".
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.
Paavo Helde
>> > 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).
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.
>>
>> 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 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. 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.
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 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.
Paavo
tonytech08
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
> tonytech08 wrote:
> > 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.
It's better to not have the complexity at all.
tonytech08
> tonytech08 <tonytec...@gmail.com> kirjutas:
>
> >> > 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).
>
> 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.
>
other than
with pointers to objects? Probably containers where the promise is
"contiguous placement in memory" as in built-in arrays.
>
> >> 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 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.
Paavo Helde
>>
> When would you _ever_ want to use containers with value semantics
> other than
> with pointers to objects?
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.
>
> 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.
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.
>
> A point is that exceptions and constructors are pretty much a package
> deal because the alternatives are ugly.
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 ;-)
Paavo
Juha Nieminen
> On Oct 28, 6:00 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> tonytech08 wrote:
>>> 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.
>
> It's better to not have the complexity at all.
Too bad that's impossible. Programming is a complex thing.
peter koch
> On Oct 28, 7:05 pm, Paavo Helde <nob...@ebi.ee> wrote:> tonytech08 <tonytec...@gmail.com> kirjutas:
>
> > >> > 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).
>
> > 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.
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.
>
>
>
> > >> 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 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.
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]
> > 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.
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?
>
> > 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.
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
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.
>> >> >> 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).
>>
>> >> Linked lists? None in any non-trivial program, but I've used vectors
>> >> (lots of them), heaps, stacks, and queues with integers.
>> > 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).
>
> 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.
>>>> 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.
>>
>> 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.).
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).
>> > 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.).
>
> 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.
>> >> > 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.
>>
>> > 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").
>> 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.
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.
>> > 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.
>
> 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
Erik Wikström
> On Oct 28, 6:00 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> tonytech08 wrote:
>> > 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.
>
> 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).
--
Erik Wikström
tonytech08
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 <tonytec...@gmail.com> kirjutas:
>
>
>
> > When would you _ever_ want to use containers with value semantics
> > other than
> > with pointers to objects?
>
> 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.
>
>
>
> > 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.
>
> 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.
>
>
>
> > A point is that exceptions and constructors are pretty much a package
> > deal because the alternatives are ugly.
>
> 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
> tonytech08 wrote:
> > On Oct 28, 6:00 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> tonytech08 wrote:
> >>> 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.
>
> > It's better to not have the complexity at all.
>
> 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
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.
>
> > > 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.
>
> 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
>> Too bad that's impossible.
>
> For C++ it is, but not for some other language.
What language? Haskell? Haha.
tonytech08
I'm not buying those arguments though.
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.
>
> >>>> 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.
>
> >> 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.).
>
> 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.
>
> > 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.
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.
>
> > 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).
Well that's one opinion, good. Thanks. It's kind of "lofty" though
rather than scientific.
>
> >> > 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.).
>
> > Maybe even most classes (?).
>
> 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.
>
> > 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.
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".
>
> > 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.
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.
>
> > 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.
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.
>
> >> >> > 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.
>
> >> > 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").
> >> 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.
>
> 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
But would be an incorrect definition given the context of this thread.
Context matters.
>
> >> > 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.
>
> > Which also is not true.
>
> 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.
Paavo Helde
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.
Paavo
Hendrik Schober
> [...]
> 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?
I haven't done any close-to-hardware programming. Yet I've come
across software that stressed very good desktop computers to their
limits. If "everything is an object" costs, I don't want to have
it. (And if it doesn't, why was there a need to invent C++?)
Schobi
tonytech08
+ 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.
Paavo Helde
>
> 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
I believe these people were a little insulted if you suggested that feature
XXX should be left out of the language because they would not be able to
implement it.
> 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.
Deleting existing features also does not bring anything new. If you want to
throw out exceptions and RAII, you have to offer something in place of
them.
Paavo
LR
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
tonytech08
> tonytech08 <tonytec...@gmail.com> kirjutas:
>
>
>
> > 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
>
> I believe these people were a little insulted if you suggested that feature
> XXX should be left out of the language because they would not be able to
> implement it.
I meant as in: "shouldn't be implemented" rather than "cannot be
implemented".
>
> > 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.
>
> Deleting existing features also does not bring anything new.
Yes, it does. (Exercise left for the reader).
> If you want to
> throw out exceptions and RAII, you have to offer something in place of
> them.
I like RAII concepts. As far as exceptions, an alternative would be
good, yes.
tonytech08
As this thread is already more chaff than wheat, I suggest you start a
new thread on "the complexity of C++" if you want to.