C++ Best practices, OOD, Linked List

[2005]

Hi

In C++, are the following considered best practices or not?
- passing aguments to functions (ie functions do not take any arguments
)
- returning values using return statement

Anything else?

The reason for this question is that I had an assignment in which I was
asked to modify so that the main will call all the functions from main
itself and also do not pass any arguments except the first function.

Another issue was a LinkedList. I was not supposed to pass the Head
pointer or add a global variable. The class only had *m_pLink (the
tail pointer). Would it be ok to assign the head pointer to m_pLink
(m_pLink does take current pointer values as it progress throuhgh the
chain, but assigned the top current pointer value)? I did that and the
code works fine.

Thank you

[Noah Roberts]

Re: C++ Best practices, OOD, Linked List


2005 wrote:

Hi
>
In C++, are the following considered best practices or not?
- passing aguments to functions (ie functions do not take any arguments
)

Huh? Is it good practice to pass arguments to functions that take no
arguments? Is that what you are asking? No, it is not. It won't even
compile. Normally one passes arguments to functions when the functions
need input, or arguments.

- returning values using return statement

How else would you return values?

>
Anything else?

Your post isn't making a lot of sense. Maybe you need to think more
clearly about what you are asking.

>
The reason for this question is that I had an assignment in which I was
asked to modify so that the main will call all the functions from main
itself and also do not pass any arguments except the first function.

Ok.

>
Another issue was a LinkedList. I was not supposed to pass the Head
pointer or add a global variable. The class only had *m_pLink (the
tail pointer). Would it be ok to assign the head pointer to m_pLink
(m_pLink does take current pointer values as it progress throuhgh the
chain, but assigned the top current pointer value)? I did that and the
code works fine.

I have no idea if that follows the guidelines to your assignment. You
would normally keep track of the head in a linked list. If you track
the tail and link back to the head then really you are just reversing
terminology as conceptually your list is still from head to tail.

[2005]

Reposted: C++ Best practices, OOD, Linked List


Noah Roberts wrote:

2005 wrote:

Hi

In C++, are the following considered best practices or not?
- passing aguments to functions (ie functions do not take any arguments
)

>
Huh? Is it good practice to pass arguments to functions that take no
arguments? Is that what you are asking? No, it is not. It won't even
compile. Normally one passes arguments to functions when the functions
need input, or arguments.
>

- returning values using return statement

>
How else would you return values?
>

Anything else?

>
Your post isn't making a lot of sense. Maybe you need to think more
clearly about what you are asking.
>

The reason for this question is that I had an assignment in which I was
asked to modify so that the main will call all the functions from main
itself and also do not pass any arguments except the first function.

>
Ok.
>

Another issue was a LinkedList. I was not supposed to pass the Head
pointer or add a global variable. The class only had *m_pLink (the
tail pointer). Would it be ok to assign the head pointer to m_pLink
(m_pLink does take current pointer values as it progress throuhgh the
chain, but assigned the top current pointer value)? I did that and the
code works fine.

>
I have no idea if that follows the guidelines to your assignment. You
would normally keep track of the head in a linked list. If you track
the tail and link back to the head then really you are just reversing
terminology as conceptually your list is still from head to tail.

Hi

In C++, are the following considered best practices or not?
- passing aguments to functions (ie design functions so that they
better take no arguments)
- returning values using return statement

Anything else?

The reason for this question is that I had an assignment in which I was
asked to modify so that the main will call all the functions from main
itself and also do not pass any arguments except the first function.

Another issue was a LinkedList. I was not supposed to pass the Head
pointer or add a global variable. The class only had *m_pLink (the
tail pointer). Would it be ok to assign the head pointer to m_pLink
(m_pLink does take current pointer values as it progress throuhgh the
chain, but assigned the top current pointer value)? I did that and the
code works fine.

I do Not think that you can get Head if you know the tail?

Thank you

[White Wolf]

Re: Reposted: C++ Best practices, OOD, Linked List

2005 wrote:

Noah Roberts wrote:

>2005 wrote:

>>Hi
>>>
>>In C++, are the following considered best practices or not?
>>- passing aguments to functions (ie functions do not take any arguments
>>)

>>
>Huh? Is it good practice to pass arguments to functions that take no
>arguments? Is that what you are asking? No, it is not. It won't even
>compile. Normally one passes arguments to functions when the functions
>need input, or arguments.
>>

>>- returning values using return statement

>>
>How else would you return values?
>>

>>>
>>Anything else?

>>
>Your post isn't making a lot of sense. Maybe you need to think more
>clearly about what you are asking.
>>

>>>
>>The reason for this question is that I had an assignment in which I was
>>asked to modify so that the main will call all the functions from main
>>itself and also do not pass any arguments except the first function.

>>
>Ok.
>>

>>>
>>Another issue was a LinkedList. I was not supposed to pass the Head
>>pointer or add a global variable. The class only had *m_pLink (the
>>tail pointer). Would it be ok to assign the head pointer to m_pLink
>>(m_pLink does take current pointer values as it progress throuhgh the
>>chain, but assigned the top current pointer value)? I did that and the
>>code works fine.

>>
>I have no idea if that follows the guidelines to your assignment. You
>would normally keep track of the head in a linked list. If you track
>the tail and link back to the head then really you are just reversing
>terminology as conceptually your list is still from head to tail.

>

[SNIP-repeated-post]

When you are asked to clarify please do so. Reposting your original text
verbatim does not help either you, or the people who would like to help.

--
WW aka Attila
:::
How many ears does Mr. Spock have? Three, a left ear, a right ear, and a
final front ear.

[2005]

Modified & Reposted: C++ Best practices, OOD, Linked List


White Wolf wrote:

2005 wrote:

Noah Roberts wrote:

2005 wrote:
>Hi
>>
>In C++, are the following considered best practices or not?
>- passing aguments to functions (ie functions do not take any arguments
>)
>
Huh? Is it good practice to pass arguments to functions that take no
arguments? Is that what you are asking? No, it is not. It won't even
compile. Normally one passes arguments to functions when the functions
need input, or arguments.
>
>- returning values using return statement
>
How else would you return values?
>
>>
>Anything else?
>
Your post isn't making a lot of sense. Maybe you need to think more
clearly about what you are asking.
>
>>
>The reason for this question is that I had an assignment in which I was
>asked to modify so that the main will call all the functions from main
>itself and also do not pass any arguments except the first function.
>
Ok.
>
>>
>Another issue was a LinkedList. I was not supposed to pass the Head
>pointer or add a global variable. The class only had *m_pLink (the
>tail pointer). Would it be ok to assign the head pointer to m_pLink
>(m_pLink does take current pointer values as it progress throuhgh the
>chain, but assigned the top current pointer value)? I did that and the
>code works fine.
>
I have no idea if that follows the guidelines to your assignment. You
would normally keep track of the head in a linked list. If you track
the tail and link back to the head then really you are just reversing
terminology as conceptually your list is still from head to tail.

[SNIP-repeated-post]
>
When you are asked to clarify please do so. Reposting your original text
verbatim does not help either you, or the people who would like to help.

Sorry, the original post - people didn't understand - so I modified it
& posted.

[Mike Wahler]

Re: Reposted: C++ Best practices, OOD, Linked List


"2005" <uws2003@yahoo. comwrote in message
news:1162145259 .156705.238860@ e64g2000cwd.goo glegroups.com.. .

>
Noah Roberts wrote:

>2005 wrote:

Hi
>
In C++, are the following considered best practices or not?
- passing aguments to functions (ie functions do not take any arguments
)

>>
>Huh? Is it good practice to pass arguments to functions that take no
>arguments? Is that what you are asking? No, it is not. It won't even
>compile. Normally one passes arguments to functions when the functions
>need input, or arguments.
>>

- returning values using return statement

>>
>How else would you return values?
>>

>
Anything else?

>>
>Your post isn't making a lot of sense. Maybe you need to think more
>clearly about what you are asking.
>>

>
The reason for this question is that I had an assignment in which I was
asked to modify so that the main will call all the functions from main
itself and also do not pass any arguments except the first function.

>>
>Ok.
>>

>
Another issue was a LinkedList. I was not supposed to pass the Head
pointer or add a global variable. The class only had *m_pLink (the
tail pointer). Would it be ok to assign the head pointer to m_pLink
(m_pLink does take current pointer values as it progress throuhgh the
chain, but assigned the top current pointer value)? I did that and the
code works fine.

>>
>I have no idea if that follows the guidelines to your assignment. You
>would normally keep track of the head in a linked list. If you track
>the tail and link back to the head then really you are just reversing
>terminology as conceptually your list is still from head to tail.

>
Hi
>
In C++, are the following considered best practices or not?
- passing aguments to functions (ie design functions so that they
better take no arguments)

A function's purpose will determine whether it's appropriate
to define parameter(s) for it. So 'best practice' is to
use arguments when necessary, and don't when not.

- returning values using return statement

As far as I know, the only way to return a value from
a function is with a return statement.

>
Anything else?
>
The reason for this question is that I had an assignment in which I was
asked to modify so that the main will call all the functions from main
itself and also do not pass any arguments except the first function.

This could work (or not) depending upon what the program is supposed to do.
Perhaps this is simply a lesson to show you that there's often more than
one way to do something, and perhaps to decide which is 'better'.

>
Another issue was a LinkedList. I was not supposed to pass the Head
pointer

Pass it to what?

>or add a global variable.

Global objects are rarely necessary and best avoided.

>The class only had *m_pLink (the
tail pointer).

Here you say 'm_pLink' represents a tail pointer.

>Would it be ok to assign the head pointer to m_pLink

Then 'm_pLink' would not be a tail pointer anymore (except in
the case of an empty list).

(m_pLink does take current pointer values as it progress throuhgh the
chain,

Now you say 'm_pLink' is a 'current pointer'. WHich is it?

>but assigned the top current pointer value)?

What is a 'top current pointer'?

>I did that and the
code works fine.

What code? Show us.

>
I do Not think that you can get Head if you know the tail?

Whether you traverse a linked list from beginning to end, or
from end to beginning, you'll need some way of telling when
to stop (typically with a 'NULL' pointer value).

-Mike

[2005]

Re: Reposted: C++ Best practices, OOD, Linked List


Mike Wahler wrote:

"2005" <uws2003@yahoo. comwrote in message
news:1162145259 .156705.238860@ e64g2000cwd.goo glegroups.com.. .

Noah Roberts wrote:

2005 wrote:
Hi

In C++, are the following considered best practices or not?
- passing aguments to functions (ie functions do not take any arguments
)
>
Huh? Is it good practice to pass arguments to functions that take no
arguments? Is that what you are asking? No, it is not. It won't even
compile. Normally one passes arguments to functions when the functions
need input, or arguments.
>
- returning values using return statement
>
How else would you return values?
>

Anything else?
>
Your post isn't making a lot of sense. Maybe you need to think more
clearly about what you are asking.
>

The reason for this question is that I had an assignment in which I was
asked to modify so that the main will call all the functions from main
itself and also do not pass any arguments except the first function.
>
Ok.
>

Another issue was a LinkedList. I was not supposed to pass the Head
pointer or add a global variable. The class only had *m_pLink (the
tail pointer). Would it be ok to assign the head pointer to m_pLink
(m_pLink does take current pointer values as it progress throuhgh the
chain, but assigned the top current pointer value)? I did that and the
code works fine.
>
I have no idea if that follows the guidelines to your assignment. You
would normally keep track of the head in a linked list. If you track
the tail and link back to the head then really you are just reversing
terminology as conceptually your list is still from head to tail.

Hi

In C++, are the following considered best practices or not?
- passing aguments to functions (ie design functions so that they
better take no arguments)

>
A function's purpose will determine whether it's appropriate
to define parameter(s) for it. So 'best practice' is to
use arguments when necessary, and don't when not.
>

- returning values using return statement

>
As far as I know, the only way to return a value from
a function is with a return statement.
>

Anything else?

The reason for this question is that I had an assignment in which I was
asked to modify so that the main will call all the functions from main
itself and also do not pass any arguments except the first function.

>
This could work (or not) depending upon what the program is supposed to do.
Perhaps this is simply a lesson to show you that there's often more than
one way to do something, and perhaps to decide which is 'better'.
>

Another issue was a LinkedList. I was not supposed to pass the Head
pointer

>
Pass it to what?
>

or add a global variable.

>
Global objects are rarely necessary and best avoided.
>

The class only had *m_pLink (the
tail pointer).

>
Here you say 'm_pLink' represents a tail pointer.
>

Would it be ok to assign the head pointer to m_pLink

>
Then 'm_pLink' would not be a tail pointer anymore (except in
the case of an empty list).
>

(m_pLink does take current pointer values as it progress throuhgh the
chain,

>
Now you say 'm_pLink' is a 'current pointer'. WHich is it?
>

but assigned the top current pointer value)?

>
What is a 'top current pointer'?
>

I did that and the
code works fine.

>
What code? Show us.
>

I do Not think that you can get Head if you know the tail?

>
Whether you traverse a linked list from beginning to end, or
from end to beginning, you'll need some way of telling when
to stop (typically with a 'NULL' pointer value).

If you only know the m_pLink (ie the tail, NULL pointer or the end),
how can you find/evaluate the Head pointer?

[Noah Roberts]

Re: Reposted: C++ Best practices, OOD, Linked List


2005 wrote:

If you only know the m_pLink (ie the tail, NULL pointer or the end),
how can you find/evaluate the Head pointer?

You cannot iterate a singly linked list backwards. You also cannot
derive anything about a list if the only information you have about it
is a null pointer. If you consider m_pLink the tail of your list,
which you have decided will be null, which you have decided will
represent the end of your list, you will not be able to acomplish
anything with the m_pLink variable. So, in short, if the only thing
you know about your list is that m_pLink contains a null pointer you
will not be able to find/evaluate the Head pointer.

[Marcus Kwok]

Re: Reposted: C++ Best practices, OOD, Linked List

Mike Wahler <mkwahler@mkwah ler.netwrote:

As far as I know, the only way to return a value from
a function is with a return statement.

Well, another way is to return a value through an output parameter. Yet
another is to throw an exception as a return value, though this style is
frowned upon. A third that I can think of is to return a value through
a global variable, also frowned upon.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Noah Roberts]

Re: Reposted: C++ Best practices, OOD, Linked List


Marcus Kwok wrote:

Mike Wahler <mkwahler@mkwah ler.netwrote:

As far as I know, the only way to return a value from
a function is with a return statement.

>
Well, another way is to return a value through an output parameter. Yet
another is to throw an exception as a return value, though this style is
frowned upon. A third that I can think of is to return a value through
a global variable, also frowned upon.

None of those qualify as returning a value; they are all side effects.
Throwing an exception is actually completely outside the normal program
flow and doesn't fit in the function concept at all.

[Marcus Kwok]

Re: Reposted: C++ Best practices, OOD, Linked List

Noah Roberts <roberts.noah@g mail.comwrote:

Marcus Kwok wrote:

>Mike Wahler <mkwahler@mkwah ler.netwrote:

As far as I know, the only way to return a value from
a function is with a return statement.

>>
>Well, another way is to return a value through an output parameter. Yet
>another is to throw an exception as a return value, though this style is
>frowned upon. A third that I can think of is to return a value through
>a global variable, also frowned upon.

>
None of those qualify as returning a value; they are all side effects.

Strictly speaking, yes, but *logically* the effects of the side effects
can be used to return values. For example, a common idiom to "return"
multiple values from a function without introducing things like tuples
is to have them as output parameters:

void foo(int i, int& j, double &d, bool& b);

This prototype could be used for a function that gets passed an int,
does some calculation, then "returns" an int, a double, and a bool.

Throwing an exception is actually completely outside the normal program
flow and doesn't fit in the function concept at all.

In Section 14.5 of _TC++PL_ :

Using exceptions as alternate returns can be an elegant technique for
terminating search functions - especially highly recursive search
functions such as a lookup in a tree. For example:

void fnd(Tree* p, const string& s)
{
if (s == p->str) throw p; // found s
if (p->left) fnd(p->left, s);
if (p->right) fnd(p->right, s);
}

Tree* find(Tree* p, const string& s)
{
try {
fnd(p, s);
}
catch (Tree* q) { // q->str == s
return q;
}
return 0;
}

However, such use of exceptions can easily be overused and lead to
obscure code. Whenever reasonable, one should stick to the
"exception handling is error handling" view.

In the example above, the helper function fnd() returns a pointer
through the exception mechanism.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Victor Bazarov]

Re: Reposted: C++ Best practices, OOD, Linked List

Marcus Kwok wrote:

Mike Wahler <mkwahler@mkwah ler.netwrote:

>As far as I know, the only way to return a value from
>a function is with a return statement.

>
Well, another way is to return a value through an output parameter.

I think that's called "side effect".

Yet another is to throw an exception as a return value, though this
style is frowned upon. A third that I can think of is to return a
value through a global variable, also frowned upon.

Again, a side effect, not "returning a value". Such value cannot
really be used in an expression involving a function call, can it?
Neither can an exception, come to think of it...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Noah Roberts]

Re: Reposted: C++ Best practices, OOD, Linked List


Marcus Kwok wrote:

Noah Roberts <roberts.noah@g mail.comwrote:

Throwing an exception is actually completely outside the normal program
flow and doesn't fit in the function concept at all.

>
In Section 14.5 of _TC++PL_ :
>
Using exceptions as alternate returns can be an elegant technique for
terminating search functions - especially highly recursive search
functions such as a lookup in a tree. For example:
>
void fnd(Tree* p, const string& s)
{
if (s == p->str) throw p; // found s
if (p->left) fnd(p->left, s);
if (p->right) fnd(p->right, s);
}
>
Tree* find(Tree* p, const string& s)
{
try {
fnd(p, s);
}
catch (Tree* q) { // q->str == s
return q;
}
return 0;
}
>
However, such use of exceptions can easily be overused and lead to
obscure code. Whenever reasonable, one should stick to the
"exception handling is error handling" view.
>
In the example above, the helper function fnd() returns a pointer
through the exception mechanism.

No, it throws an exception and returns nothing. Throwing an exception
and returning a value are two very different things. Again, exceptions
don't really fit in the function concept at all and are a path of
execution outside of that concept. Abusing them not withstanding.

Also, I would disagree with the Bjarne on this one. Someone else
brought this up a while ago and testing reveiled that on at least one
common architecture the performance penalty for doing it that way was
quite severe when compared to using the actual return mechanism. I
agree that it can obviously be done but is far from elegant or
appropriate.

[Marcus Kwok]

Re: Reposted: C++ Best practices, OOD, Linked List

Noah Roberts <roberts.noah@g mail.comwrote:

Marcus Kwok wrote:

>Noah Roberts <roberts.noah@g mail.comwrote:

Throwing an exception is actually completely outside the normal program
flow and doesn't fit in the function concept at all.

>>
>In Section 14.5 of _TC++PL_ :
>>
> Using exceptions as alternate returns can be an elegant technique for
> terminating search functions - especially highly recursive search
> functions such as a lookup in a tree. For example:
>>
> void fnd(Tree* p, const string& s)
> {
> if (s == p->str) throw p; // found s
> if (p->left) fnd(p->left, s);
> if (p->right) fnd(p->right, s);
> }
>>
> Tree* find(Tree* p, const string& s)
> {
> try {
> fnd(p, s);
> }
> catch (Tree* q) { // q->str == s
> return q;
> }
> return 0;
> }
>>
> However, such use of exceptions can easily be overused and lead to
> obscure code. Whenever reasonable, one should stick to the
> "exception handling is error handling" view.
>>
>In the example above, the helper function fnd() returns a pointer
>through the exception mechanism.

>
No, it throws an exception and returns nothing. Throwing an exception
and returning a value are two very different things. Again, exceptions
don't really fit in the function concept at all and are a path of
execution outside of that concept. Abusing them not withstanding.

I agree that this is an abuse of the exception mechanism and I would
probably never write code like this. However, I think our disagreement
may be in what our definitions of "returns" are. In this context, I am
using a little more liberal definition, as in "makes a result available
to the calling code". If you use my definition, then the exception
mechanism indeed does make the result available to the calling code,
albeit in a highly unorthodox manner.


#include <iostream>

void foo_ex()
{
throw 42;
}

void bar_ex()
{
int i = 0;
try {
foo_ex();
}
catch (int j) {
i = j;
}
std::cout << "exception: i = " << i << '\n';
}



int foo_ret()
{
return 42;
}

void bar_ret()
{
int i = foo_ret();
std::cout << "return: i = " << i << '\n';
}



int main()
{
bar_ex();
bar_ret();
}

/*
output:
exception: i = 42
return: i = 42
*/


In both cases, 'i' gets the value obtained from foo(). Obviously, the
standard return mechanism is much better. But, with diligence I believe
it should be *possible* to replace all return-statements with
throw-statements, if all invocations of the function are appropiately
wrapped in try/catch blocks so that the stack is never unwound more than
would happen with a regular function, etc. Therefore, throwing an
exception *can* be used as a slow, error-prone, clumsy way to return
values from a function.

Whether this is something that anyone would actually *want* to do is
another matter...

Also, I would disagree with the Bjarne on this one. Someone else
brought this up a while ago and testing reveiled that on at least one
common architecture the performance penalty for doing it that way was
quite severe when compared to using the actual return mechanism.

Yes, I remember that thread.

http://groups.google.com/group/alt.comp.lang.learn.c-c++/browse_frm/thread/1a5e7fef082b5472/

I also see that you weighed in several times in that thread too.

I
agree that it can obviously be done but is far from elegant or
appropriate.

Well, I never said I endorsed this method... just that it is not the
only way to "return" something from a function.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Noah Roberts]

Re: Reposted: C++ Best practices, OOD, Linked List


Marcus Kwok wrote:

I agree that this is an abuse of the exception mechanism and I would
probably never write code like this. However, I think our disagreement
may be in what our definitions of "returns" are. In this context, I am
using a little more liberal definition, as in "makes a result available
to the calling code". If you use my definition, then the exception
mechanism indeed does make the result available to the calling code,
albeit in a highly unorthodox manner.

Well, if we call a chicken a duck then the differences between chickens
and ducks obviously becomes quite difficult to talk about.

[snip a bunch of obvious stuff]

Therefore, throwing an
exception *can* be used as a slow, error-prone, clumsy way to return
values from a function.

No, there is only one mechanism for returning values from a function.