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!
55  3894 
On Oct 23, 2:41*pm, tonytech08 <tonytec...@gmail.comwrote:
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!
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).
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?
--
Erik Wikström
On Oct 23, 12:13*pm, Erik Wikström <Erik-wikst...@telia.comwrote:
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?
On Oct 23, 10:38*am, tonytech08 <tonytec...@gmail.comwrote:
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();
Fat fingers! :) The post went out incomplete.
On Oct 23, 10:44 am, acehr...@gmail.com wrote:
On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.comwrote:
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();
[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
On 2008-10-23 19:38, tonytech08 wrote:
On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
>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?
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
On 23 Okt., 19:38, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 12:13*pm, Erik Wikström <Erik-wikst...@telia.comwrote:
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? 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
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
On Oct 23, 12:44*pm, acehr...@gmail.com wrote:
On Oct 23, 10:38*am, tonytech08 <tonytec...@gmail.comwrote:
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?
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)).
On Oct 23, 2:09 pm, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 12:44 pm, acehr...@gmail.com wrote:On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.comwrote:
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
On 23 Okt., 23:09, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 12:44*pm, acehr...@gmail.com wrote:On Oct 23, 10:38*am, tonytech08 <tonytec...@gmail.comwrote:
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
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.
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.
On Oct 23, 4:09*pm, tonytech08 <tonytec...@gmail.comwrote:
(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.
On Oct 23, 12:49*pm, acehr...@gmail.com wrote:
Fat fingers! :) The post went out incomplete.
On Oct 23, 10:44 am, acehr...@gmail.com wrote:
On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.comwrote:
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();
[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- Hide quoted text -
- 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).
On Oct 23, 1:12*pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-10-23 19:38, tonytech08 wrote:
On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
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?
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).
>
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.
On Oct 23, 2:13*pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 23 Okt., 19:38, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 12:13*pm, Erik Wikström <Erik-wikst...@telia.comwrote:
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).
On Oct 23, 4:01*pm, Hendrik Schober <spamt...@gmx.dewrote:
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.
On Oct 23, 4:35*pm, acehr...@gmail.com wrote:
On Oct 23, 2:09 pm, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 12:44 pm, acehr...@gmail.com wrote:On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.comwrote:
* 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?
On Oct 23, 5:05*pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 23 Okt., 23:09, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 12:44*pm, acehr...@gmail.com wrote:On Oct 23, 10:38*am, tonytech08 <tonytec...@gmail.comwrote:
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. ;)
On Oct 23, 5:42*pm, Juha Nieminen <nos...@thanks.invalidwrote:
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!
>
* 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.
On Oct 24, 10:11*am, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 4:01*pm, Hendrik Schober <spamt...@gmx.dewrote:
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 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
On Oct 23, 10:54*pm, "Road.Tang" <roadt...@gmail.comwrote:
On Oct 24, 10:11*am, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 4:01*pm, Hendrik Schober <spamt...@gmx.dewrote:
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. :)
tonytech08 wrote:
On Oct 23, 1:12 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
>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
tonytech08 wrote:
On Oct 23, 4:01 pm, Hendrik Schober <spamt...@gmx.dewrote:
>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
On Oct 23, 1:41 pm, tonytech08 <tonytec...@gmail.comwrote:
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
On 2008-10-24 02:01, tonytech08 wrote:
On Oct 23, 1:12 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
>On 2008-10-23 19:38, tonytech08 wrote:
On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
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
On 24 Okt., 04:38, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 5:05*pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 23 Okt., 23:09, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 12:44*pm, acehr...@gmail.com wrote:On Oct 23, 10:38*am, tonytech08 <tonytec...@gmail.comwrote:
"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
On 24 Okt., 02:15, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 2:13*pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 23 Okt., 19:38, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 12:13*pm, Erik Wikström <Erik-wikst...@telia.comwrote:
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 befor
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.
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.
tonytech08 wrote:
On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalidwrote:
>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).
On Oct 24, 7:14*am, Bart van Ingen Schenau
<Bart.van.Ingen.Sche...@ict.nlwrote:
On Oct 23, 1:41 pm, tonytech08 <tonytec...@gmail.comwrote:
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).
On Oct 24, 11:39*am, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-10-24 02:01, tonytech08 wrote:
On Oct 23, 1:12 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-10-23 19:38, tonytech08 wrote:
On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
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 befor
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.
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).
On Oct 24, 1:02*pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 24 Okt., 02:15, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 2:13*pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 23 Okt., 19:38, tonytech08 <tonytec...@gmail.comwrote:
On Oct 23, 12:13*pm, Erik Wikström <Erik-wikst...@telia.comwrote:
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.
But you stated that exceptions were built for constructors, implying
that without them, their use would not be justified
That doesn't imply that so I will ignore your thought process on that.
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!
On Oct 24, 4:25*pm, Juha Nieminen <nos...@thanks.invalidwrote:
tonytech08 wrote:
On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalidwrote:
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).
On Oct 24, 1:47*am, Hendrik Schober <spamt...@gmx.dewrote:
tonytech08 wrote:
On Oct 23, 4:01 pm, Hendrik Schober <spamt...@gmx.dewrote:
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?
On 2008-10-26 04:29, tonytech08 wrote:
On Oct 24, 11:39 am, Erik Wikström <Erik-wikst...@telia.comwrote:
>On 2008-10-24 02:01, tonytech08 wrote:
On Oct 23, 1:12 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-10-23 19:38, tonytech08 wrote:
On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia.comwrote:
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.
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).
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
On 2008-10-26 05:07, tonytech08 wrote:
On Oct 24, 4:25 pm, Juha Nieminen <nos...@thanks.invalidwrote:
>tonytech08 wrote:
On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalidwrote:
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 wrote:
>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.
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.
When a language is "simple", it often means that implementing many
programs with that language becomes complicated.
In this case a "simple language" is more a hindrance than an
advantage. It may be easier to learn, but programming becomes more
complicated.
tonytech08 <to********@gmail.comkirjutas:
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
On Oct 28, 5:57*pm, Juha Nieminen <nos...@thanks.invalidwrote:
tonytech08 wrote:
Linked lists of ints? I guess 'none'. For ints, a std::vector would bea
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.
I guess not: if you contain pointers to objects. When you contain an
object by value though, you impose unnecessary requirements on their
classes.
On Oct 28, 6:00*pm, Juha Nieminen <nos...@thanks.invalidwrote:
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.
>
* When a language is "simple", it often means that implementing many
programs with that language becomes complicated.
* In this case a "simple language" is more a hindrance than an
advantage. It may be easier to learn, but programming becomes more
complicated.
tonytech08 <to********@gmail.comkirjutas:
>>
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
tonytech08 wrote:
On Oct 28, 6:00 pm, Juha Nieminen <nos...@thanks.invalidwrote:
>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.
On 29 Okt., 03:53, tonytech08 <tonytec...@gmail.comwrote:
On Oct 28, 7:05*pm, Paavo Helde <nob...@ebi.eewrote:tonytech08 <tonytec...@gmail.comkirjutas:
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
On 2008-10-29 01:29, tonytech08 wrote:
On Oct 28, 6:00 pm, Juha Nieminen <nos...@thanks.invalidwrote:
>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
On Oct 29, 4:02*pm, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-10-29 01:29, tonytech08 wrote:
On Oct 28, 6:00 pm, Juha Nieminen <nos...@thanks.invalidwrote:
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).
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.
On Oct 29, 3:07*am, Paavo Helde <nob...@ebi.eewrote:
tonytech08 <tonytec...@gmail.comkirjutas:
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.
On Oct 29, 10:31*am, Juha Nieminen <nos...@thanks.invalidwrote:
tonytech08 wrote:
On Oct 28, 6:00 pm, Juha Nieminen <nos...@thanks.invalidwrote:
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.
On Oct 29, 1:13*pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 29 Okt., 03:53, tonytech08 <tonytec...@gmail.comwrote:
On Oct 28, 7:05*pm, Paavo Helde <nob...@ebi.eewrote:tonytech08 <tonytec...@gmail.comkirjutas:
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 seein
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?
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 abilityto
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Franz Steinhaeusler |
last post by:
Hello,
(in wxPython)
I want to redirect the SetStatusText
to an own method (change the text somewhat) and
then call the SetStatusText of wx.Frame.
But I have a little problem of...
|
by: JohanS |
last post by:
Hi
count(v.begin(), v.end(), 5) is easy for a vector of int's.
But how do i make it work with a class object? I have tried a few ways
but can't get it to work since i don't really understand...
|
by: Brian Ross |
last post by:
Hi,
I am trying to do something similar to the following:
int Func1(int x, int y);
double Func2(double x, double y);
template <typename FuncT> // <- What would go here
class CObjectT
{
|
by: sashang |
last post by:
Hi
I'd like to use metaclasses to dynamically generate a class based on a
parameter to the objects init function.
For example:
class MetaThing(type):
def __init__(cls, name, bases, dict,...
|
by: brzozo2 |
last post by:
Hello, anyone knows if there is a way to use pointer notation instead
of
array when it comes to copying one object to another via a pointer of
array to objects?
Here is a very simple code to show...
|
by: Ole Nielsby |
last post by:
I have objects that sometimes overwrite themselves by something else,
using placement new.
I will spare you for the details, but the objects serve as stack frames
and are placed contiguosly, and...
|
by: MattWilson.6185 |
last post by:
Hi, I'm trying to find out if something is possible, I have a few
diffrent lists that I add objects to and I would like to be able to
have a wrapper class that won't affect the internal object, for...
|
by: =?gb2312?B?wfXquw==?= |
last post by:
Hi, folks,
I'm running into a question as below:
template<typename T>
class A {
private:
T _a;
public:
A(T t): _a(t) {
}
|
by: Jonathan Boivin |
last post by:
Hi,
I've got some problems with loading bills using a bill usercontrol I built.
If I load all current bills in my test environment (156) everything is fine
once, but repeating the operation...
|
by: hofer |
last post by:
Hi,
I have multiple objects all belonging to the same class
(which I didn't implement and whose code I don't want to modify)
Now I'd like to change one method for one object only (after it has...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| | |
