«

* Phlip:
> * Julie:
> >
> > * Steven T. Hatton:
> > >
> > > int* i; ?
> >
> > Space on both sides, makes it immediately obvious (to me) what is going
> > on,doesn't crowd the type or name, and I never have multiple declarations on
> > one line.
> >
> > Been doing this since I started programming and never had a problem.
>
> Absitively. Space on both sides: int * i.
>
> I'm visually impaired - especially when I program while f---ed up - so every
> little visual cue helps.

Although Australian farmers have found that new technology allows
f--king while farming, see <url: http://tinyurl.com/5btbx>, it's generally
not recommended to f--k while programming, especially not in C++, even if
you have space on both sides and can rely on visual cues.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Sorry about the tinyurl, the URL it refers only works as a link from
certain web-pages such as Google because the web-page provider (news.24.com,
don't use it, they're incompetent and/or uncaring folks) has access control.

Same article elsewhere, namely ABC news:

<url: http://www.abc.net.au/news/newsitems/200408/s1185358.htm>.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

"Denis Remezov" <> wrote in message
news:...
> "Steven T. Hatton" wrote:
<<snip>>
> is just as bad because "*b = 0;" reads almost exactly as an independent
> assignment expression statement (for a previously declared b), which has
> a completely different meaning to "int *b=0;".
> Of course, you could avoid multiple declarations in the first place.

Looks like a reason to use
int *b=NULL;
for declaration. I'm fond of int* myself, but I use either with no real
hang-up.
--
Gary

Alf P. Steinbach wrote:

> * Phlip:

> > I'm visually impaired - especially when I program while f---ed up - so
every
> > little visual cue helps.
>
> Although Australian farmers have found that new technology allows
> f--king while farming, see <url: http://tinyurl.com/5btbx>, it's generally

I thought that was New Zealand farmers...

> not recommended to f--k while programming, especially not in C++, even if
> you have space on both sides and can rely on visual cues.

No no no - I'm talking about getting f---ed up while programming. Other end
of the body.

Good style guides, unit tests, etc. help me remain quite productive, thank
you...

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Steven T. Hatton" <> wrote in message news:<ENydnbvkoKDB4rDcRVn->...
> So I have two questions about this. First which do you prefer and why?

int *ptr. Consider stuff like "int *var1, var2, **var3, var4" or "int
var1, *var2, var3, ***var4". Whether each variable is a pointer or not
(or a pointer to a pointer, or a pointer to a pointer to a pointer...)
is a per-variable thing, not something that applies to the entire line
like int. If you put the asterisk of the first variable with the int,
the rest of the variables just look hokey, whether they are pointers
with their own asterisks next to them or regular ints which now kind
of look like pointers because you stuck the asterisk right with the
int. But of course, this is just my taste, although I think it is a
pretty consistent taste.

Tommy McDaniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBLk7ZVB8FYP9YqDcRAt5DAJ9kXZ18V1nKNc6gNuUE6P yG7lwVewCePRGW
LoCe2rR2FmGIFSpn5OlzSbg=
=+h/n
-----END PGP SIGNATURE-----

Howard wrote:

> This has been discussed so many times it's ridiculous. But, seeing as I'm
> the ultimate "notable authority" (from my perspective, anyway ), I
> declare that the CORRECT way is to put the * with the type, not with the
> variable name. Plus, NEVER declare more than one variable on one line!
> (That prevents any chance of confusion, and makes finding the variable
> you're looking for much easier.)


However if you declare many variables in the same line, the * with the
variable name is the more reasonable and obvious. Also when you declare
a pointer alone, the * going with the variable name is the more
reasonable too.


How do you dereference by the way * p=7; or *p=7; ?






>
> One other thing I do (which I just know ****es some others off) is to always
> precede pointer variable names with the small letter 'p', as in pHead. It's
> the only time I use that weird hungarian notation, but it really helps me
> recognize pointers from non-pointers. (But that makes me wonder...should a
> pointer to a pointer to a Head then be a ppHead? Sorry, bad pun.)


That's naming conventions and it is another thing that we can quibble
on, in the future.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Denis Remezov wrote:

> A couple more remarks:
>
> I concede that the following is often a source of confusion and
> possible errors:
>
> int* pa = 0,
> pb = 0;
>
> To me, however, the alternative
>
> int *a = 0,
> *b = 0;
>
> is just as bad because "*b = 0;" reads almost exactly as an independent
> assignment expression statement (for a previously declared b), which has
> a completely different meaning to "int *b=0;".
> Of course, you could avoid multiple declarations in the first place.


What about


int *pa=0, pb=0;


which is the most elegant and accurate?






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Tommy McDaniel wrote:

> int *ptr. Consider stuff like "int *var1, var2, **var3, var4" or "int
> var1, *var2, var3, ***var4". Whether each variable is a pointer or not
> (or a pointer to a pointer, or a pointer to a pointer to a pointer...)
> is a per-variable thing, not something that applies to the entire line
> like int. If you put the asterisk of the first variable with the int,
> the rest of the variables just look hokey, whether they are pointers
> with their own asterisks next to them or regular ints which now kind
> of look like pointers because you stuck the asterisk right with the
> int. But of course, this is just my taste, although I think it is a
> pretty consistent taste.


At last, someone who is reasonable.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys

Ioannis Vranos wrote:
>
> Denis Remezov wrote:
>
> > A couple more remarks:
> >
> > I concede that the following is often a source of confusion and
> > possible errors:
> >
> > int* pa = 0,
> > pb = 0;
> >
> > To me, however, the alternative
> >
> > int *a = 0,
> > *b = 0;
> >
> > is just as bad because "*b = 0;" reads almost exactly as an independent
> > assignment expression statement (for a previously declared b), which has
> > a completely different meaning to "int *b=0;".
> > Of course, you could avoid multiple declarations in the first place.
>
> What about
>
> int *pa=0, pb=0;
>
> which is the most elegant and accurate?
>

Whichever we happen to like.

Most generally, you cannot declare multiple names of /different/
types in one declaration.

int signed s, unsigned u; //illegal

This is why I see no value (or elegance) in being able to declare
variables of type T and T* (and T**, ...) in one declaration.

Denis

Denis Remezov wrote:

> Whichever we happen to like.
>
> Most generally, you cannot declare multiple names of /different/
> types in one declaration.
>
> int signed s, unsigned u; //illegal
>
> This is why I see no value (or elegance) in being able to declare
> variables of type T and T* (and T**, ...) in one declaration.


You have got the main issue. Since int and int * are different types the
standard should require an error. That's why we are here with this
syntax stuff today.


However based on the fact that they are allowed to be declared together,
and the asterisk denotes a pointer variable, while an object next to it
in the same declaration without an asterisk becomes a non-pointer
object, the most rational thing in this kind of declarations is the
asterisk to go close to the pointer variable itself rather than the type.






Regards,

Ioannis Vranos

http://www23.brinkster.com/noicys