Re: Class objects work like built-in types, but is it worth it?
On 29 Okt., 03:53, tonytech08 <tonytec...@gmail.com> wrote:
On Oct 28, 7:05 pm, Paavo Helde <nob...@ebi.ee> wrote:> tonytech08 <ton=
ytec...@gmail.com> kirjutas:
So, how many linked lists of integer values have you used in code?
It appears that not supporting built-in types for some containers
would encourage better programming practice (going by just that on=
e
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 belie=
ve
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 trad=
e-
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 i=
n
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, virtu=
al
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 t=
o
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