About reference
newbiecpp
reference has size?
int myInt;
int& myRef = myInt;
myRef is just another name of myInt? My confusion is that if myRef is not
an object, where is myRef reside in memory? Compiler has to keep
information about myRef, but where is this information?
Thanks in advance.
Francis Glassborow
writes
A reference is (in general) just a name that is bound to an already
existing object, how the program tracks the relationship between names
and objects is entirely its concern.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Ben Cottrell
Try not to think of a reference as something with a physical presence..
it doesn't need one, and won't necessarily have one either.
(So Unlike with a pointer, obtaining the address of a reference will
just get you the address of the object it refers to.)
a reference is basically a "nickname". (I guess the proper word would be
'alias'.)
in the same way that you might nickname a work colleague.. the nickname
won't be officially recorded anywhere, although, that nickname always
refers to that person - and obviously you can't give that nickname to
someone else. Other colleagues will always know exactly who you're
referring to when you use their nickname - their nickname and real name
can be used interchangably in conversation.
So, continuing from your example, writing:
int newInt = myRef;
is exactly the same as writing:
int newInt = myInt;
--
Ben Cottrell AKA Bench
Disclaimer:
This post may contain explicit depictions of things which are "real".
These "real" things are commonly known as 'life'! So, if it sounds
sarcastic, don't take it seriously. If it sounds hazardous, Do not try
this at home or at all. And if it offends you, just don't read it.
jeffc
"newbiecpp" <newb...@yahoo.com> wrote in message
news:lGORc.1914$Po1.49@trndny08...
You're right it has to keep the information, but it's supposed to be hidden
from you. It will probably do it with a pointer, but it's designed so
you're not supposed to have to think about that. Just like you said - myRef
is just another naem of myInt.
newbiecpp
char c;
char& rc = c;
struct A {
A() : i(c) {}
char i;
int j;
};
int main()
{
std::cout << sizeof(rc) << std::endl << sizeof(A) << std::endl;
return 0;
}
The sizeof(rc) is 1 and sizeof(A) is 8. The first looks like the reference
doesn't have a size but the second looks like the reference just like a
point and has a size. Can someone explain this to me? I appreciate!
"newbiecpp" <newb...@yahoo.com> wrote in message
news:lGORc.1914$Po1.49@trndny08...
newbiecpp
> I got more confused regarding the size of a reference. I wrote the
program:
>
> char c;
> char& rc = c;
>
> struct A {
> A() : i(c) {}
> char i;
> int j;
> };
>
> int main()
> {
> std::cout << sizeof(rc) << std::endl << sizeof(A) << std::endl;
> return 0;
> }
>
> The sizeof(rc) is 1 and sizeof(A) is 8. The first looks like the
reference
> doesn't have a size but the second looks like the reference just like a
> point and has a size. Can someone explain this to me? I appreciate!
I made a typo. The struct is:
struct A {
A() : i(c) {}
char& i;
int j;
};
Karl Heinz Buchegger
>
> I got more confused regarding the size of a reference. I wrote the program:
>
> char c;
> char& rc = c;
>
> struct A {
> A() : i(c) {}
> char i;
> int j;
> };
>
> int main()
> {
> std::cout << sizeof(rc) << std::endl << sizeof(A) << std::endl;
> return 0;
> }
>
> The sizeof(rc) is 1 and sizeof(A) is 8. The first looks like the reference
> doesn't have a size but the second looks like the reference just like a
> point and has a size.
How do you conclude that. In struct A there is no reference involved :-)
(I guess this is a typo in posting which also shows, that you should
always use cut&paste to copy your real code to the newsreader instead
of retyping it. I gues the above should read:
struct A {
A() : i(c) {}
char& i;
int j;
};
)
> Can someone explain this to me? I appreciate!
First of all: A reference is another name for an already existing object.
So what does that mean in practice?
It means there are situations where the compiler can do the substitution
on its own. Just like in your example for rc. The compiler tracks that
rc is just another name for c and whatever you do to rc it applies to c.
So this reference doesn't take up space in the final executable. The compiler
simply uses c whenever you write rc.
But then: The situation isn't always like this. There are situations where
the compiler doesn't know to what other object the reference is another
name for. So it has to implement the reference semantics somehow. Most
often (as far as we know: always), the compiler does this by the means
of a pointer. So in your case of the struct, the compiler puts a pointer
underneath of i and adjust the code in such a way that whenever you use
i somewhere, it dereferences that pointer.
So the conclusion is: A reference may or may not take up space in the
final executable. It all depends in which way the reference is used and
how the compiler implements things.
But for you, the programmer, all of this should not care. For you a reference
is simply: another name for an otherwise existing object. How the compiler
implements this, is none of your business.
--
Karl Heinz Buchegger
kbuc...@gascad.at
newbiecpp
"Karl Heinz Buchegger" <kbuc...@gascad.at> wrote in message
news:411A0867...@gascad.at...
Thanks for your excellent explanation. But my concern is that some senior
programmers told me that you should use references instead of pointers in
function parameters (in case you need null, than you have to use pointers).
If a reference doesn't have a size, than that makes a sense. However, in
function prototype:
void foo(int&);
based on your explanation, the reference is implemented as a pointer (since
the compiler doesn't know the object yet). So, passing a reference or a
pointer doesn't matter. They are the same. Then, I think these senior
programmers were wrong.
Karl Heinz Buchegger
>
[snip]
>
> Thanks for your excellent explanation. But my concern is that some senior
> programmers told me that you should use references instead of pointers in
> function parameters
Ah. That's where the wind is blowing from :-)
(Sorry: This is a literal translation of a german saying. Don't
know how some english speaking people would say instead. Basically
I am saying: 'Ah, Now we are getting to the core of your real problem'
with an emphasis on 'real'. )
> (in case you need null, than you have to use pointers).
> If a reference doesn't have a size, than that makes a sense. However, in
> function prototype:
>
> void foo(int&);
>
> based on your explanation, the reference is implemented as a pointer (since
> the compiler doesn't know the object yet). So, passing a reference or a
> pointer doesn't matter. They are the same.
For the produced code, they *might* be the same. If the compiler inlines the
function, then things might change. With a reference the compiler can still
use the substitution: original object for reference and thus eliminate
the reference at all.
> Then, I think these senior
> programmers were wrong.
Why don't you ask them for their reason to prefer references?
I bet that saving space is among them, but at very low priority.
Usually one uses references to not clutter up the code with pointer
syntax and constantly having dereference operations all over
the place.
Francis Glassborow
<newb...@yahoo.com> writes
>I got more confused regarding the size of a reference. I wrote the program:
>
>char c;
>char& rc = c;
>
>struct A {
> A() : i(c) {}
> char i;
> int j;
>};
>
>int main()
>{
> std::cout << sizeof(rc) << std::endl << sizeof(A) << std::endl;
> return 0;
>}
>
>The sizeof(rc) is 1 and sizeof(A) is 8. The first looks like the reference
>doesn't have a size but the second looks like the reference just like a
>point and has a size. Can someone explain this to me? I appreciate!
A reference is a very special entity in C++. There are no objects of
reference type. Names can have a reference type which means that at the
point of definition of the name it has to be bound to an already
existing object. This is the way that references are fundamentally
different to all other C++ types which will be bound to a new instance
of the appropriate type at the point of definition.
int i; //binds i to storage for an int
int * i_ptr; // binds i_ptr to storage for a pointer to int
int & i_ref(i); // binds i_ref to the object bound to i
Note that one indication of the difference is that references have to be
initialised. Because other types get their own objects created at the
point of definition, they can be (but generally, should not be) left
uninitialised. But the meaning of uninitialised is that the new object
is in an indeterminate state. References have to be initialised because
they have to know what object they are to be bound to (note that this is
quite different to the concept of a reference in languages such as
Java).
Now sizeof applied to a type gives the amount of storage for an object
of that type. In the case of reference types, there are no such objects
so sizeof returns the storage requirements for the non-reference type.
Francis Glassborow
writes
>Thanks for your excellent explanation. But my concern is that some senior
>programmers told me that you should use references instead of pointers in
>function parameters (in case you need null, than you have to use pointers).
>If a reference doesn't have a size, than that makes a sense. However, in
>function prototype:
>
>void foo(int&);
>
>based on your explanation, the reference is implemented as a pointer (since
>the compiler doesn't know the object yet). So, passing a reference or a
>pointer doesn't matter. They are the same. Then, I think these senior
>programmers were wrong.
It most certainly matters because in one case a real accessible object
is created (an int*) whereas in the other case only a name is created.
Make the above function inline and the difference can be important. The
senior programmers are right to ignore implementation details. How a
reference is implemented is outside the domain of the programmer.
newbiecpp
"Francis Glassborow" <fra...@robinton.demon.co.uk> wrote in message
news:xh1DG+Xg...@robinton.demon.co.uk...
To summarize your points and Mr. Buchegger's points, programmers should
treat references as aliases, or other names of objects, but not objects and
don't have sizes. How compilers implement references is none of
programmers' business. So, in case of function passing and returning,
programmers should use references instread of pointers (other than using
pointers providing you need useing null or transfer objects). Am I right?
Karl Heinz Buchegger
>
> To summarize your points and Mr. Buchegger's points, programmers should
> treat references as aliases, or other names of objects, but not objects and
> don't have sizes. How compilers implement references is none of
> programmers' business. So, in case of function passing and returning,
> programmers should use references instread of pointers (other than using
> pointers providing you need useing null or transfer objects). Am I right?
Adressing the point you are specifically concerned about:
Parameter passing.
I use the following 'algorithm' to choose the parameter passing
method:
do I need to express 'no value passed' ?
|
+--> yes: pass a pointer
|
+--> no:
is it of builtin type like char, int, double, etc ... ?
|
+--> yes: pass per value
|
+--> no:
does the function need to modify the callers argument ?
|
+--> yes: pass a reference
|
+--> no: pass a const reference
Francis Glassborow
<newb...@yahoo.com> writes
>To summarize your points and Mr. Buchegger's points, programmers should
>treat references as aliases, or other names of objects, but not objects and
>don't have sizes. How compilers implement references is none of
>programmers' business. So, in case of function passing and returning,
>programmers should use references instread of pointers (other than using
>pointers providing you need useing null or transfer objects). Am I right?
Yes, only use a pointer if you want to change which object is pointed to
rather than read or write to a particular object (or pass it around)
Francis Glassborow
<kbuc...@gascad.at> writes
The only refinements I would add is
1) move up the question about wanting to modify the original (use
references for all cases where you want to modify an object through
calling a function.
2) Consider pass by value for small udts (including enums)
Gary Labowitz
news:xh1DG+Xg...@robinton.demon.co.uk...
. References have to be initialised because
> they have to know what object they are to be bound to (note that this is
> quite different to the concept of a reference in languages such as
> Java).
Not so. Java reference variables are similar to pointers in that they have
to be seated to refer to some object. Otherwise, they are default
initialized to null.
It is possible (and common) to write
A aRef;
in Java to get a reference to an A class object without specifying any
particular instance. aRef in this case is null.
[Or are we saying the same thing???]
--
Gary
Gary Labowitz
> Yes, only use a pointer if you want to change which object is pointed to
> rather than read or write to a particular object (or pass it around)
I presume you mean here to pass a reference to a pointer. Yes?
--
Gary
Francis Glassborow
<glab...@comcast.net> writes
Not really. But it is true that if you want to change the value stored
in a pointer rather than change the thing pointed to you should pass a
reference to the pointer. Remember that pointers are objects whose
values are the addresses of other objects.
Francis Glassborow
<glab...@comcast.net> writes
We are saying the same thing. Java references share some characteristics
with C++ pointers. In particular Java references can refer to different
objects during their lifetime, C++ references cannot. In C++ objects are
bound immutably to names until the name goes out of scope.
Uwe Schnitker
[ First checking if my lightning rod is properly installed ... ]
I'm no longer sure if the common advice "Use references if you can, and
pointers only if you must" is a really good one.
Reading "Domain-Driven Design" piqued - or better: renewed - my interest in
the "modelling" aspect of C++ design as opposed - or rather: complementary -
to its "dependency-management" aspect as per "Principles, Patterns and
Practices".
One of the central ideas of domain modelling is to make a very clear
distinction between Value Objects and Entity Ojects. Entity Objects are
those that are characterized by identity foremost - a person is still the
same person even if the name changes, e.g. due to marriage - and Value Objects
are those that are characterized by state alone - the person's name is
different, even if its characters may still be saved in the same memory block.
In C++, it is often most natural to allocate Entity Objects with new - and
manage them with smart pointers - but to create Value Objects directly, either
as local objects or as class members of other Entity or Value Objects.
Make this distiction - which is often neccessary due to lifetime
considerations, i.e. it is often impossible to create Entity Objects directly -
explicit is an idiom recommended by some. When conflicts arise, e.g. you need
polymorphic implementations for a Value Object, or you need operator syntax
for what you consider an Entity Object, they can be solved by using some
variant of the Handle/Body or Envelope/Letter idioms.
Now I'm starting to think that it makes sense to always use a pointer if you
want to get/give access an Entity Object - given the idiomatic rule described
above, this essentially means never to have to pass a (dereferenced) pointer
argument to a reference parameter - even if the pointer can never be zero (use
an assertion to document this fact).
The practical issue that convinced me that these thinking isn't just ivory
tower elaboration - after all, I'm (trying hard to be) a Pragmatic Programmer -
was that code that should look similar looks very different just because of
such "possible nullness" considerations, e.g factories either returning
pointers or references, in a way that I found quite inconsistent.
Ok, this is obviously not a full-fledged defence of my ideas, but maybe just
enough to get some responses.
Uwe
Alwyn
Schnitker <schnitkerAf...@sigma-c.com> wrote:
> In C++, it is often most natural to allocate Entity Objects with new - and
> manage them with smart pointers - but to create Value Objects directly, either
> as local objects or as class members of other Entity or Value Objects.
'It is often most natural' is a very weak proposition to build your
argument on. I would argue that, on the contrary, so-called entity
objects are often stored 'expanded' or 'by value' in an STL container.
Alwyn
Francis Glassborow
<dt015...@mac.com.invalid> writes
Actually I expected a different conclusion as I read the article;
pointers for value based and references for entities. Not that I would
agree with that either :-)
Uwe Schnitker
> In article <120820041304396561%dt015...@mac.com.invalid>, Alwyn
> <dt015...@mac.com.invalid> writes
> >In article <30381f67.0408...@posting.google.com>, Uwe
> >Schnitker <schnitkerAf...@sigma-c.com> wrote:
> >
> >> In C++, it is often most natural to allocate Entity Objects with new - and
> >> manage them with smart pointers - but to create Value Objects directly, either
> >> as local objects or as class members of other Entity or Value Objects.
> >
> >'It is often most natural' is a very weak proposition to build your
> >argument on.
[ First respondig to Alwyn ]
It's not a proposition, it is part of the argument (or conjecture?).
Also, you seem to silently agree on the second part, that Value Objects are
"often most naturally" created as local objects or direct class members?
> I would argue that, on the contrary, so-called entity
> >objects are often stored 'expanded'
What do you mean by "expanded"?
> or 'by value' in an STL container.
Well, my point is that Entity Objects "typically" cannot be created as local
objects since their lifetime is longer than any specific processing last -
otherwise, why would they be entities? And if they are direct members of
another class - btw., please understand that I'm not confusing class and
object anywhere, I'm just saving a little space by neglecting to use utmost
precision - and thus tied to the lifetime of their owner, their entity-ship
might also be questioned.
Okay, they might be stored in an STL container that is a member of some
object that serves as a kind of repository of entities. I concede that this
may be a better solution.
OTOH, I suspect - please note that my lack of assuredness comes from the fact
that I'm just now trying to adapt the ideas of DDD that are explained in a
Java context to the many things what I know about C++ idioms - that Entity
Objects are more likely to be polymorphic, or that their polymorphism is more
likely to be relevant to the model (as opposed to being just an implementation
detail), or are at the very least it is less likely that their polymorphism
gets into your way - ever tried to work with unadapted polymorphic iterators? -
than it would be the case with Value objects.
This would lead to using STL containers of smart pointers to Entity Objects.
(Compared to the use of STL containers of handle classes for polymorphic
Value Objects.)
> Actually I expected a different conclusion as I read the article;
> pointers for value based and references for entities. Not that I would
> agree with that either :-)
Well, of course I expected disagreement (after all, I was asking for trouble),
but I'm quite astonished about the direction of that disagreement.
But I'm also happy: You can learn even more from a discussion if there is
unexpected disagreement.
Uwe
Alwyn
Schnitker <schnitkerAf...@sigma-c.com> wrote:
> Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message
> news:<SFKL$lVfH2...@robinton.demon.co.uk>...
> > In article <120820041304396561%dt015...@mac.com.invalid>, Alwyn
> > <dt015...@mac.com.invalid> writes
> > >In article <30381f67.0408...@posting.google.com>, Uwe
> > >Schnitker <schnitkerAf...@sigma-c.com> wrote:
> > >
> > >> In C++, it is often most natural to allocate Entity Objects with new -
> > >> and
> > >> manage them with smart pointers - but to create Value Objects directly,
> > >> either
> > >> as local objects or as class members of other Entity or Value Objects.
> > >
> > >'It is often most natural' is a very weak proposition to build your
> > >argument on.
>
> [ First respondig to Alwyn ]
>
> It's not a proposition, it is part of the argument (or conjecture?).
Simply put, a proposition is a statement that can be either true or
false. If the judgment of the truth or falsity of a proposition has
small consequences, then that proposition can be called weak. You
surely cannot build an argument without using propositions, and the
stronger the propositions, if they are true, the stronger the argument,
as long as the deductive logic is correct.
> Also, you seem to silently agree on the second part, that Value Objects are
> "often most naturally" created as local objects or direct class members?
Again, that is so weak that I find it difficult to disagree. I did once
create a complex hierarchy of value-type classes that were meant to be
addressed through pointers because they had to behave polymorphically.
It's a pain to do in C++, even with 'smart-pointer' type wrappers, but
it's often demanded by the design. I suggest that people who design for
a C++-based implementation tend to avoid this because it makes a
correct program harder to write.
> > I would argue that, on the contrary, so-called entity
> > >objects are often stored 'expanded'
>
> What do you mean by "expanded"?
Sorry, that's a term they use in Eiffel, not C++. It means that when
you write the name of the object, it indicates the actual object, not a
reference to it.
> > or 'by value' in an STL container.
>
> Well, my point is that Entity Objects "typically" cannot be created as local
> objects since their lifetime is longer than any specific processing last -
> otherwise, why would they be entities? And if they are direct members of
> another class - btw., please understand that I'm not confusing class and
> object anywhere, I'm just saving a little space by neglecting to use utmost
> precision - and thus tied to the lifetime of their owner, their entity-ship
> might also be questioned.
Well, 'lifetime' is not an unambiguous term. For instance, a program
might retrieve a Person object from a database, modify it, write it
back and then forget about it. What's the lifetime of such an object?
> Okay, they might be stored in an STL container that is a member of some
> object that serves as a kind of repository of entities. I concede that this
> may be a better solution.
>
> OTOH, I suspect - please note that my lack of assuredness comes from the fact
> that I'm just now trying to adapt the ideas of DDD that are explained in a
> Java context to the many things what I know about C++ idioms - that Entity
> Objects are more likely to be polymorphic, or that their polymorphism is more
> likely to be relevant to the model (as opposed to being just an implementation
> detail), or are at the very least it is less likely that their polymorphism
> gets into your way - ever tried to work with unadapted polymorphic iterators?
It's an unfortunate fact that the programming language you use dictates
your design to some extent. As I have indicated above, it's sometimes
been my experience that an implementation in C++ can sometimes force
design decisions that in the abstract do not seem ideal.
> than it would be the case with Value objects.
>
> This would lead to using STL containers of smart pointers to Entity Objects.
> (Compared to the use of STL containers of handle classes for polymorphic
> Value Objects.)
That's where I disagree with you. There often is a mismatch between the
requirements of an idealised design (architectural specification, if
you will) and the way the design will actually be implemented (detailed
design). I would not want to force implementations to conform willy
nilly to theoretical notions of correctness - there has to be some
benefit in the actual implementation of doing it that way.
Alwyn
Uwe Schnitker
> In article <30381f67.04081...@posting.google.com>, Uwe
> Schnitker <schnitkerAf...@sigma-c.com> wrote:
>
> > Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message
> > news:<SFKL$lVfH2...@robinton.demon.co.uk>...
> > > In article <120820041304396561%dt015...@mac.com.invalid>, Alwyn
> > > <dt015...@mac.com.invalid> writes
> > > >In article <30381f67.0408...@posting.google.com>, Uwe
> > > >Schnitker <schnitkerAf...@sigma-c.com> wrote:
> > > >
> > > >> In C++, it is often most natural to allocate Entity Objects with new -
> > > >> and
> > > >> manage them with smart pointers - but to create Value Objects directly,
> > > >> either
> > > >> as local objects or as class members of other Entity or Value Objects.
> > > >
> > > >'It is often most natural' is a very weak proposition to build your
> > > >argument on.
> >
> > [ First respondig to Alwyn ]
> >
> > It's not a proposition, it is part of the argument (or conjecture?).
>
> Simply put, a proposition is a statement that can be either true or
> false. If the judgment of the truth or falsity of a proposition has
> small consequences, then that proposition can be called weak.
Ok, now I see what you mean by a "weak proposition". I misunderstood the term.
> You
> surely cannot build an argument without using propositions, and the
> stronger the propositions, if they are true, the stronger the argument,
> as long as the deductive logic is correct.
>
> > Also, you seem to silently agree on the second part, that Value Objects are
> > "often most naturally" created as local objects or direct class members?
>
> Again, that is so weak that I find it difficult to disagree. I did once
> create a complex hierarchy of value-type classes that were meant to be
> addressed through pointers because they had to behave polymorphically.
> It's a pain to do in C++, even with 'smart-pointer' type wrappers, but
> it's often demanded by the design. I suggest that people who design for
> a C++-based implementation tend to avoid this because it makes a
> correct program harder to write.
Well, when I'm running into such a problem, I prefer to use 'handle' wrappers
instead of smart pointers, which may be slightly more work, but more easy to
get correct.
> > > I would argue that, on the contrary, so-called entity
> > > >objects are often stored 'expanded'
> >
> > What do you mean by "expanded"?
>
> Sorry, that's a term they use in Eiffel, not C++. It means that when
> you write the name of the object, it indicates the actual object, not a
> reference to it.
>
> > > or 'by value' in an STL container.
> >
> > Well, my point is that Entity Objects "typically" cannot be created as local
> > objects since their lifetime is longer than any specific processing last -
> > otherwise, why would they be entities? And if they are direct members of
> > another class - btw., please understand that I'm not confusing class and
> > object anywhere, I'm just saving a little space by neglecting to use utmost
> > precision - and thus tied to the lifetime of their owner, their entity-ship
> > might also be questioned.
>
> Well, 'lifetime' is not an unambiguous term. For instance, a program
> might retrieve a Person object from a database, modify it, write it
> back and then forget about it. What's the lifetime of such an object?
Good question.
> > Okay, they might be stored in an STL container that is a member of some
> > object that serves as a kind of repository of entities. I concede that this
> > may be a better solution.
> >
> > OTOH, I suspect - please note that my lack of assuredness comes from the fact
> > that I'm just now trying to adapt the ideas of DDD that are explained in a
> > Java context to the many things what I know about C++ idioms - that Entity
> > Objects are more likely to be polymorphic, or that their polymorphism is more
> > likely to be relevant to the model (as opposed to being just an implementation
> > detail), or are at the very least it is less likely that their polymorphism
> > gets into your way - ever tried to work with unadapted polymorphic iterators?
>
> It's an unfortunate fact that the programming language you use dictates
> your design to some extent. As I have indicated above, it's sometimes
> been my experience that an implementation in C++ can sometimes force
> design decisions that in the abstract do not seem ideal.
I'm not sure it's really unfortunate. "Design without context is meaningless"
(Kevlin Henney), and the context includes the programming language, too, IMHO.
> > than it would be the case with Value objects.
> >
> > This would lead to using STL containers of smart pointers to Entity Objects.
> > (Compared to the use of STL containers of handle classes for polymorphic
> > Value Objects.)
>
> That's where I disagree with you. There often is a mismatch between the
> requirements of an idealised design (architectural specification, if
> you will) and the way the design will actually be implemented (detailed
> design). I would not want to force implementations to conform willy
> nilly to theoretical notions of correctness - there has to be some
> benefit in the actual implementation of doing it that way.
Oh, we are not in disagreement over that.
I don't care about "theoretical notions of correctness ... of an idealised
design" too much.
I just like it to express more abstract design "models" consistently as more
concrete design "idioms", when a good alignment between those two is possible.
And I believe that when there is a tension between the abstract model and the
more concrete software design, you can often find a better model that fits
as well with the abstract view as with the more concrete view.
Maybe I'm just too optimistic?
Anyway, the problem I was thinking about initially was a quite concrete issue,
namely that I dislike the standard advice on pointer vs. reference usage, i.e.
in some cases I'd prefer to use a pointer where others would advise me to use
a reference instead. I thought I had found the nucleus of a possible high-level
justification for such preferences, but it didn't turn out this way.
> Alwyn
Uwe
Alwyn
> > It's an unfortunate fact that the programming language you use dictates
> > your design to some extent. As I have indicated above, it's sometimes
> > been my experience that an implementation in C++ can sometimes force
> > design decisions that in the abstract do not seem ideal.
>
> I'm not sure it's really unfortunate. "Design without context is meaningless"
> (Kevlin Henney), and the context includes the programming language, too, IMHO.
I've no idea who Kevlin Henney is, and I can only comment that a remark
without a context is meaningless. :-)
Now, there are many ways of designing a system. Here's one I'm familiar
with (assuming 'waterfall model' for clarity):
1. draw up use-cases, interaction diagrams, activity diagrams, state
diagrams etc. based on requirements, preferably with customer
participation
2. produce an object model of the system
3. refine and amend this model as necessary, specifying algorithms and
other implementation details
4. tell the CASE tool to generate the code
OK, stage 4 was something of a joke. The point is that the output of
stage 3 should be a design specification that is detailed enough to
code from. Obviously, at this stage, one needs to take the programming
language into consideration. Ideally, stage 2 should not be concerned
with low-level details like what can be done with a particular
programming language, and they are absolutely excluded from stage 1.
Alwyn