By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,723 Members | 1,298 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,723 IT Pros & Developers. It's quick & easy.

references and pointers

P: n/a
MQ
Can someone tell me where I should use pointers and where I should use
references? In his book, Stroustrup says that you should use pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices in
this respect?

regards,
B.

Nov 4 '07 #1
Share this Question
Share on Google+
19 Replies


P: n/a
MQ wrote:
Can someone tell me where I should use pointers and where I should use
references? In his book, Stroustrup says that you should use pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices in
this respect?
Think about the basic difference between references and pointers:
Pointers can be made to point to something else than what they were
initialized to point to (including null) while references can't.

This, IMO, gives a good rule of thumb for the decision: If you don't
need to change where the thing is pointing, use references, else use
pointers.
Nov 4 '07 #2

P: n/a
On Nov 4, 11:20 am, Juha Nieminen <nos...@thanks.invalidwrote:
MQ wrote:
Can someone tell me where I should use pointers and where I should use
references? In his book, Stroustrup says that you should use pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices in
this respect?

Think about the basic difference between references and pointers:
Pointers can be made to point to something else than what they were
initialized to point to (including null) while references can't.

This, IMO, gives a good rule of thumb for the decision: If you don't
need to change where the thing is pointing, use references, else use
pointers.
Why then does Stroustrup make the following statement in his book:

"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"

This says to me that we in fact should *not* use references in this
way


Nov 4 '07 #3

P: n/a
bo*******@gmail.com wrote:
On Nov 4, 11:20 am, Juha Nieminen <nos...@thanks.invalidwrote:
>MQ wrote:
>>Can someone tell me where I should use pointers and where I should use
references? In his book, Stroustrup says that you should use pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices in
this respect?
Think about the basic difference between references and pointers:
Pointers can be made to point to something else than what they were
initialized to point to (including null) while references can't.

This, IMO, gives a good rule of thumb for the decision: If you don't
need to change where the thing is pointing, use references, else use
pointers.

Why then does Stroustrup make the following statement in his book:

"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"
He made a mistake? Or possibly idiomatic style has changed over time.

--
Ian Collins.
Nov 4 '07 #4

P: n/a
On Nov 4, 12:00 pm, Ian Collins <ian-n...@hotmail.comwrote:
boroph...@gmail.com wrote:
On Nov 4, 11:20 am, Juha Nieminen <nos...@thanks.invalidwrote:
MQ wrote:
Can someone tell me where I should use pointers and where I should use
references? In his book, Stroustrup says that you should use pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices in
this respect?
Think about the basic difference between references and pointers:
Pointers can be made to point to something else than what they were
initialized to point to (including null) while references can't.
This, IMO, gives a good rule of thumb for the decision: If you don't
need to change where the thing is pointing, use references, else use
pointers.
Why then does Stroustrup make the following statement in his book:
"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"

He made a mistake? Or possibly idiomatic style has changed over time.

--
Ian Collins.
Are you serious? This is in the most recent version of "The C++
programming language", and he mentions this point in several
locations. Hardly an editing mistake. Let me just state that I am
not debating that the point he makes seems right, it does not seem
right to me, but it seems to be more than just a mistake.

Nov 4 '07 #5

P: n/a
bo*******@gmail.com wrote:
On Nov 4, 12:00 pm, Ian Collins <ian-n...@hotmail.comwrote:
>boroph...@gmail.com wrote:
>>Why then does Stroustrup make the following statement in his book:
"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"
He made a mistake? Or possibly idiomatic style has changed over time.
*Please* don't quote signatures.
>
Are you serious? This is in the most recent version of "The C++
programming language", and he mentions this point in several
locations. Hardly an editing mistake. Let me just state that I am
not debating that the point he makes seems right, it does not seem
right to me, but it seems to be more than just a mistake.
http://www.research.att.com/~bs/bs_f...and-references

Puts a different view across, so one of my guesses was probably true.

I'd only recommend using pointers when the argument can meaningfully be
NULL, or when interfacing with legacy code.

--
Ian Collins.
Nov 4 '07 #6

P: n/a
On Nov 3, 8:15 pm, Ian Collins <ian-n...@hotmail.comwrote:
I'd only recommend using pointers when the argument can meaningfully be
NULL, or when interfacing with legacy code.
Or when you need to store a "reference" (for lack of a better term) to
a shared object in a class that must be STL container-compatible
(assignable).

I admit that I am newish to C++, but the pattern I have found is that
I only use references when passing arguments. I try hard never to use
"out" variables, but when I do, I use pointers.

Nov 4 '07 #7

P: n/a

"Ian Collins" <ia******@hotmail.comwrote in message
news:5p*************@mid.individual.net...
bo*******@gmail.com wrote:
>On Nov 4, 12:00 pm, Ian Collins <ian-n...@hotmail.comwrote:
>>boroph...@gmail.com wrote:
>>>Why then does Stroustrup make the following statement in his book:
"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"
He made a mistake? Or possibly idiomatic style has changed over time.
*Please* don't quote signatures.
>>
Are you serious? This is in the most recent version of "The C++
programming language", and he mentions this point in several
locations. Hardly an editing mistake. Let me just state that I am
not debating that the point he makes seems right, it does not seem
right to me, but it seems to be more than just a mistake.
http://www.research.att.com/~bs/bs_f...and-references

Puts a different view across, so one of my guesses was probably true.

I'd only recommend using pointers when the argument can meaningfully be
NULL, or when interfacing with legacy code.
I was actually debating this with myself 2 days ago. Someone gave me some
code work on, he was using pointers to modify the parameters. I started to
change them to references, then realized that in mainline, there is no
indication if the parameter was going to be changed or not.

Consider.

void foo( int* Val )
{
*Val = 23;
}

void bar( int& Val )
{
Val = 23;
}

int main()
{
int MyInt = 10;
foo( &MyInt );
bar( MyInt );
}

Becaue Foo forces us to take the address of MyInt, it is fairly obvious in
mainline that MyInt is probably going to be changed, else why pass the
address of a simple int? bar however gives no indication in mainline that
MyInt will be changed.

Maybe that is the reasoning behind it.

Reguardless, I did go ahead and change them all to references anyway.
Nov 4 '07 #8

P: n/a
Jim Langston wrote:
"Ian Collins" <ia******@hotmail.comwrote:
>http://www.research.att.com/~bs/bs_f...and-references

Puts a different view across, so one of my guesses was probably true.

I'd only recommend using pointers when the argument can meaningfully be
NULL, or when interfacing with legacy code.

I was actually debating this with myself 2 days ago. Someone gave me some
code work on, he was using pointers to modify the parameters. I started to
change them to references, then realized that in mainline, there is no
indication if the parameter was going to be changed or not.

Consider.

void foo( int* Val )
{
*Val = 23;
}

void bar( int& Val )
{
Val = 23;
}

int main()
{
int MyInt = 10;
foo( &MyInt );
bar( MyInt );
}

Becaue Foo forces us to take the address of MyInt, it is fairly obvious in
mainline that MyInt is probably going to be changed, else why pass the
address of a simple int? bar however gives no indication in mainline that
MyInt will be changed.
A good example of why you should give functions meaningful names.

--
Ian Collins.
Nov 4 '07 #9

P: n/a
On 2007-11-04 01:52:26 -0400, "Jim Langston" <ta*******@rocketmail.comsaid:
>
"Ian Collins" <ia******@hotmail.comwrote in message
news:5p*************@mid.individual.net...
>bo*******@gmail.com wrote:
>>On Nov 4, 12:00 pm, Ian Collins <ian-n...@hotmail.comwrote:
boroph...@gmail.com wrote:
>>>>Why then does Stroustrup make the following statement in his book:
"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"
He made a mistake? Or possibly idiomatic style has changed over time.
*Please* don't quote signatures.
>>>
Are you serious? This is in the most recent version of "The C++
programming language", and he mentions this point in several
locations. Hardly an editing mistake. Let me just state that I am
not debating that the point he makes seems right, it does not seem
right to me, but it seems to be more than just a mistake.
http://www.research.att.com/~bs/bs_f...and-references

Puts a different view across, so one of my guesses was probably true.

I'd only recommend using pointers when the argument can meaningfully be
NULL, or when interfacing with legacy code.

I was actually debating this with myself 2 days ago. Someone gave me some
code work on, he was using pointers to modify the parameters. I started to
change them to references, then realized that in mainline, there is no
indication if the parameter was going to be changed or not.

Consider.

void foo( int* Val )
{
*Val = 23;
}

void bar( int& Val )
{
Val = 23;
}

int main()
{
int MyInt = 10;
foo( &MyInt );
bar( MyInt );
}

Becaue Foo forces us to take the address of MyInt, it is fairly obvious in
mainline that MyInt is probably going to be changed, else why pass the
address of a simple int? bar however gives no indication in mainline that
MyInt will be changed.

Maybe that is the reasoning behind it.

Reguardless, I did go ahead and change them all to references anyway.
I think you made a good call to change them to references anyway.
Otherwise, you would have to worry about people passing invalid pointer
like in foo(0).

So, like Ian Collins had stated in another post, use pointers only if
there is a need to include NULL as a possible value. But even in that
case, perhaps it is cleaner for the class to implement a singleton
object that represents the "NULL" object of the class anyway.

I'm still a newbie in C++, but I'm getting the sense that proper use of
STL should eliminate all needs of pointers. However, for efficiency
purposes, perhaps pointers should sometimes be employed, just like
'goto' is theoretically not needed but may be practically needed.

--

-kira

Nov 4 '07 #10

P: n/a
bo*******@gmail.com wrote:
:: On Nov 4, 11:20 am, Juha Nieminen <nos...@thanks.invalidwrote:
::: MQ wrote:
:::: Can someone tell me where I should use pointers and where I
:::: should use references? In his book, Stroustrup says that you
:::: should use pointers for passing arguments that are to be
:::: modified, not references. Yet, in an interview, he laments the
:::: overuse of pointers and such in code. It seems contradictory to
:::: me. Why should we not use references instead of pointers? Can
:::: someone give me an idea of best practices in this respect?
:::
::: Think about the basic difference between references and
::: pointers: Pointers can be made to point to something else than
::: what they were initialized to point to (including null) while
::: references can't.
:::
::: This, IMO, gives a good rule of thumb for the decision: If you
::: don't need to change where the thing is pointing, use references,
::: else use pointers.
::
:: Why then does Stroustrup make the following statement in his book:
::
:: "Be suspicious of non-const reference arguments; if you want the
:: function to modify its arguments, use pointers and value return
:: instead"
::
:: This says to me that we in fact should *not* use references in this
:: way

Could you give some context to this statement, like the section number
or something?

It could be that he argues about const against non-const arguments.
Instead of modifyng some part of an argument, like a struct, the
function might be better off just returning the new value.
Bo Persson
Nov 4 '07 #11

P: n/a
On 4 Nov., 02:38, boroph...@gmail.com wrote:
On Nov 4, 11:20 am, Juha Nieminen <nos...@thanks.invalidwrote:


MQ wrote:
Can someone tell me where I should use pointers and where I should use
references? In his book, Stroustrup says that you should use pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices in
this respect?
Think about the basic difference between references and pointers:
Pointers can be made to point to something else than what they were
initialized to point to (including null) while references can't.
This, IMO, gives a good rule of thumb for the decision: If you don't
need to change where the thing is pointing, use references, else use
pointers.

Why then does Stroustrup make the following statement in his book:

"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"

This says to me that we in fact should *not* use references in this
way- Skjul tekst i anførselstegn -
Where does he write that? I've read that book and certainly would have
remembered that statement, so I believe you must be misunderstanding
him.

/Peter

Nov 4 '07 #12

P: n/a
peter koch wrote:
On 4 Nov., 02:38, boroph...@gmail.com wrote:
>On Nov 4, 11:20 am, Juha Nieminen <nos...@thanks.invalidwrote:


MQ wrote:
Can someone tell me where I should use pointers and where I should
use
references? In his book, Stroustrup says that you should use
pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices
in this respect?
Think about the basic difference between references and pointers:
Pointers can be made to point to something else than what they were
initialized to point to (including null) while references can't.
This, IMO, gives a good rule of thumb for the decision: If you don't
need to change where the thing is pointing, use references, else use
pointers.

Why then does Stroustrup make the following statement in his book:

"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"

This says to me that we in fact should *not* use references in this
way- Skjul tekst i anførselstegn -

Where does he write that? I've read that book and certainly would have
remembered that statement, so I believe you must be misunderstanding
him.
See section 7.9, point [1] in the list of advice. There is virtually no
context to the sentence that could change the literal interpretation.
Best

Kai-Uwe Bux
Nov 4 '07 #13

P: n/a
On Nov 4, 7:10 pm, Kai-Uwe Bux <jkherci...@gmx.netwrote:
peter koch wrote:
On 4 Nov., 02:38, boroph...@gmail.com wrote:
On Nov 4, 11:20 am, Juha Nieminen <nos...@thanks.invalidwrote:
MQ wrote:
Can someone tell me where I should use pointers and where I should
use
references? In his book, Stroustrup says that you should use
pointers
for passing arguments that are to be modified, not references. Yet,
in an interview, he laments the overuse of pointers and such in code.
It seems contradictory to me. Why should we not use references
instead of pointers? Can someone give me an idea of best practices
in this respect?
Think about the basic difference between references and pointers:
Pointers can be made to point to something else than what they were
initialized to point to (including null) while references can't.
This, IMO, gives a good rule of thumb for the decision: If you don't
need to change where the thing is pointing, use references, else use
pointers.
Why then does Stroustrup make the following statement in his book:
"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"
This says to me that we in fact should *not* use references in this
way- Skjul tekst i anførselstegn -
Where does he write that? I've read that book and certainly would have
remembered that statement, so I believe you must be misunderstanding
him.

See section 7.9, point [1] in the list of advice. There is virtually no
context to the sentence that could change the literal interpretation.

Best

Kai-Uwe Bux- Hide quoted text -

- Show quoted text -
The advice seems a bit odd because most elementary texts have a swap-
two-integers problem, and the intended solution is always to use int&
variables -- pointer-to-int are not mentioned in the standard
solution.

Intended solution is to use void swap(int& x, int& y)

This function creates a local tmp variable whose value = x and then
sets x=y, y = tmp. The result is that y now contains the value x held
and x contains the value y held.

Paul Epstein
Nov 4 '07 #14

P: n/a
Kai-Uwe Bux wrote:
:: peter koch wrote:
::
::: On 4 Nov., 02:38, boroph...@gmail.com wrote:
:::: On Nov 4, 11:20 am, Juha Nieminen <nos...@thanks.invalidwrote:
::::
::::
::::
::::
::::
::::: MQ wrote:
:::::: Can someone tell me where I should use pointers and where I
:::::: should use
:::::: references? In his book, Stroustrup says that you should use
:::::: pointers
:::::: for passing arguments that are to be modified, not references.
:::::: Yet, in an interview, he laments the overuse of pointers and
:::::: such in code. It seems contradictory to me. Why should we not
:::::: use references instead of pointers? Can someone give me an
:::::: idea of best practices in this respect?
::::
::::: Think about the basic difference between references and
::::: pointers: Pointers can be made to point to something else than
::::: what they were initialized to point to (including null) while
::::: references can't.
::::
::::: This, IMO, gives a good rule of thumb for the decision: If
::::: you don't need to change where the thing is pointing, use
::::: references, else use pointers.
::::
:::: Why then does Stroustrup make the following statement in his
:::: book:
::::
:::: "Be suspicious of non-const reference arguments; if you want the
:::: function to modify its arguments, use pointers and value return
:::: instead"
::::
:::: This says to me that we in fact should *not* use references in
:::: this way- Skjul tekst i anførselstegn -
:::
::: Where does he write that? I've read that book and certainly would
::: have remembered that statement, so I believe you must be
::: misunderstanding him.
::
:: See section 7.9, point [1] in the list of advice. There is
:: virtually no context to the sentence that could change the literal
:: interpretation.
::

Interesting!

Point 1 also refers to §5.5 where he writes (p 99 in my 5th printing):

"To keep a program readable, it is often best to avoid functions that
modify their arguments. Instead, you can return a value from the
function explicitly or require a pointer argument.

[some code example]

The increment(x) notation doesn't give a clue to the reader that x's
value is being modified, the way x=next(x) and incr(&x) does.
Consequently 'plain' reference arguments should be used only where the
name of the function gives a strong hint that the reference argument
is modified."

That's pretty literal! :-)
So most of us agree that a function should not modifiy its argument,
unless that is clear from the function's name. Generally, a function
name should always tell what the function does. Using a pointer
argument doesn't really solve this problem.

Sometimes even Bjarne gives advice that are not that good. :-)
Bo Persson
Nov 4 '07 #15

P: n/a

On Sun, 2007-11-04 at 12:24 +0000, Erik Wikström wrote:
The latest edition is still almost 10 years old and written when the
standard was new. I would expect that the idioms have developed a bit
since then.
Barne Stroustrup mustn't have had any input into the codecvt facet
then :)

--
Tristan Wibberley

Any opinion expressed is mine (or else I'm playing devils advocate for
the sake of a good argument). My employer had nothing to do with this
communication.

Nov 4 '07 #16

P: n/a
bo*******@gmail.com wrote:
Why then does Stroustrup make the following statement in his book:

"Be suspicious of non-const reference arguments; if you want the
function to modify its arguments, use pointers and value return
instead"

This says to me that we in fact should *not* use references in this
way
Even though he is the creator of the language, that still sounds like
a question of opinion, a question of style.

IMO functions taking references should *always* take const references
for parameters they do not modify, and only take non-const references
for parameters they might modify. Thus, as a rule of thumb, if you are
calling a function which takes a non-const reference you must assume
that it may change it.

Of course there may be badly-designed third-party C++ libraries which
take non-const references even though they never modify them, but OTOH
even if they took pointers that wouldn't change anything: You still
couldn't be certain whether the function modifies it or not. You must
assume that it may.
Nov 5 '07 #17

P: n/a
Kira Yamato <ki*****@earthlink.netwrote in
news:2007110402083216807-kirakun@earthlinknet:
[...]
I'm still a newbie in C++, but I'm getting the sense that proper use
of STL should eliminate all needs of pointers. However, for
efficiency purposes, perhaps pointers should sometimes be employed,
just like 'goto' is theoretically not needed but may be practically
needed.
References are usually implemented by pointers anyway, so there is no
efficiency gain (except that you don't (shouldn't) need to check for
NULL-ness, but that's more a design issue and costs next to nothing
anyway on current hardware).

Pointers are not good for out parameters IMHO, because pointers can be
NULL. If I call some function for retrieving some data and passing NULL
pointer, what I'm saying? Do I want to get this data after all or not? If
not, why I call this function? I should call another function or overload
instead if I don't want to get any data back. In case of references I am
obliged to provide the space for data and the meaning of the operation is
much clearer.

You are right that raw pointers should generally not be used in C++ code.
If pointer semantics are required, for example for storing in STL
containers, some kind of smartpointers should be used instead.
Paavo
Nov 8 '07 #18

P: n/a
On Nov 8, 6:24 pm, Paavo Helde <nob...@ebi.eewrote:
Kira Yamato <kira...@earthlink.netwrote innews:2007110402083216807-kirakun@earthlinknet:
[...]
References are usually implemented by pointers anyway, so there is no
efficiency gain (except that you don't (shouldn't) need to check for
NULL-ness, but that's more a design issue and costs next to nothing
anyway on current hardware).
It depends. A reference cannot be reseated. The compiler knows
this. That may open up some additional optimization
possibilities, or make them simpler.
Pointers are not good for out parameters IMHO, because
pointers can be NULL.
C++ doesn't allow out parameters, at least not for class types,
so the question is moot:-).

For inout parameters (or parameters which are conceptually out,
even if you can't call the function without actually having
given them a value), it's a question of convention---I prefer
references, too, but I'll adapt to the local convention.

Pointers are required, on the other hand, if the out parameter
is optional---things like the second parameter to functions in
the strtoxxx family (strtod, etc.).
If I call some function for retrieving some data and passing NULL
pointer, what I'm saying?
That you're not interested in the data, only in the side effects
of looking for it.

Out parameters are not all that frequent. Except in some very
rare cases of optimization, they only occur when a function has
more than one value to return. In that case, it's a fairly
common idiom to pass the address of the second return value as a
pointer, with the convention that a null pointer means that
you're only interested in the primary return value. There are a
number of examples of this in the C standard, for example.
Do I want to get this data after all or not? If
not, why I call this function?
Because if it has an out parameter, it also has a return value,
and you're only interested in the return value.
I should call another function or overload instead if I don't
want to get any data back.
That's another alternative---provide two functions. But what is
the real difference between:
Type1 function( Type2* out = NULL ) ;
and
Type1 function() ;
Type1 function( Type2& out ) ;
(The only real difference I can see is that some older compilers
might still accept a temporary as argument in the second case.
Which is an argument for using the first alternative---and for
using pointers in general for out parameters. But you should
probably update such compilers, rather than adapting your coding
standards to them.)
In case of references I am obliged to provide the space for
data and the meaning of the operation is much clearer.
You are right that raw pointers should generally not be used
in C++ code. If pointer semantics are required, for example
for storing in STL containers, some kind of smart pointers
should be used instead.
This is simply false. There are times when smart pointers are
appropriate, but most use of pointers is for navigation, and raw
pointers are still the best solution for that.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Nov 9 '07 #19

P: n/a
James Kanze wrote:
On Nov 8, 6:24 pm, Paavo Helde <nob...@ebi.eewrote:
>You are right that raw pointers should generally not be used
in C++ code. If pointer semantics are required, for example
for storing in STL containers, some kind of smart pointers
should be used instead.

This is simply false. There are times when smart pointers are
appropriate, but most use of pointers is for navigation, and raw
pointers are still the best solution for that.
Whether most use of pointers is for navigation depends heavily on the
application domain. You are presumably correct for event-driven programs.
However, there is a whole lot of other stuff out there where pointers are
used for other purposes (e.g., COW-optimization for large objects,
implementation of container-like data structures, working with incomplete
types to meet conceptual requirements, interfacing legacy code, ...).
Without a qualification of the type of program you are talking about,
statements about the fraction of pointers that are used for navigation
compared to what is used for other purposes seem to be a matter of pure
speculation. On the other hand, if you have some significant data on this,
I would be interested.
Best

Kai-Uwe Bux
Nov 10 '07 #20

This discussion thread is closed

Replies have been disabled for this discussion.