Passing member variables as function parameters

[Ninan]

Is this a good design for myClass in the example below? Are there
better alternatives for m_oA and myCallback?
struct apiA, and function apiFn () are not in my control, as they are
standard api supplied by the exchange for which I am writing the
application. Also the member variable m_oA logically belongs to myClass

struct apiA {

int a;

int b;

} ;

typedef void (apiCallback) (apiA* pA);

void apiFn (apiA *pA, apiCallback *pCbk)

{

std::cout << pA->a << " " << pA->b << std::endl;

pA->a = 8;

pA->b = 9;

std::cout << pA->a << " " << pA->b << std::endl;

//Simple illustration only. In real life callback fn will be
called later pA->a = 18;

pA->b = 19;

(*pCbk)(pA);

return;

}

class myClass {

apiA m_oA;

public:

void UseapiFn () ;

static void myCallback (apiA *pA) ;

} ;

void

myClass::UseapiFn ()

{

m_oA.a =6;

m_oA.b =7;

apiFn (&m_oA, myCallback);

}

void myClass::myCallback (apiA *pA)

{

std::cout << "In callback " << pA->a << " " << pA->b <<
std::endl;
return;

}

int main ()

{

myClass oInst;

oInst.UseapiFn();

return 0;

}
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Victor Bazarov]

Ninan wrote:

Is this a good design for myClass in the example below? Are there
better alternatives for m_oA and myCallback?
I don't see any problem with it. What makes you ask? You must have
doubts about the validity of the design, why?

Yes, 'm_oA' is a private member, but the API function doesn't know
(nor does it care) where the object comes from.
[...]

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

[Francis Glassborow]

In article <11**********************@p79g2000cwp.googlegroups .com>,
Ninan <ni****@yahoo.com> writes

Is this a good design for myClass in the example below? Are there
better alternatives for m_oA and myCallback? struct apiA, and function
apiFn () are not in my control, as they are standard api supplied by
the exchange for which I am writing the application. Also the member
variable m_oA logically belongs to myClass

This post is a wonderful example of how too much whitespace is as bad
(or possibly worse) as too little. I do not have the time to reformat
the code and without doing that I find it unreadable.

I am pretty sure that the problem (every line of source code has an
extra blank line added to it) is not an artefact of my news-reader but
an artefact of cutting and pasting from an incompatible source code
editor.

As the moderator who accepted this post my hands were tied because
format is not a reason for rejection, but perhaps readability ought to
be. We can reject for excessive source code, perhaps we should also have
an allowance for rejection for too many blank lines:-) What do others
think?

--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/
youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Joshua Lehrer]

Ninan wrote:

Is this a good design for myClass in the example below? Are there
better alternatives for m_oA and myCallback?
struct apiA, and function apiFn () are not in my control, as they are
standard api supplied by the exchange for which I am writing the
application. Also the member variable m_oA logically belongs to myClass

I'm not really sure what you are asking. You say that we can't change
the struct, nor the function that accepts the struct and the callback
pointer. Also, you say that m_oA must belong to myClass. It's as if
you said "here's some code that I can't change, what should I change?"

You are properly calling the apiFn() supplied and properly passing
arguments to it. I see nothing, given your restrictions, that should
change.

joshua lehrer
http://www.lehrerfamily.com/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Victor Bazarov]

Francis Glassborow wrote:

In article <11**********************@p79g2000cwp.googlegroups .com>,
Ninan <ni****@yahoo.com> writes

Is this a good design for myClass in the example below? Are there
better alternatives for m_oA and myCallback? struct apiA, and
function apiFn () are not in my control, as they are standard api
supplied by the exchange for which I am writing the application.
Also the member variable m_oA logically belongs to myClass

This post is a wonderful example of how too much whitespace is as bad
(or possibly worse) as too little. I do not have the time to reformat
the code and without doing that I find it unreadable.

I am pretty sure that the problem (every line of source code has an
extra blank line added to it) is not an artefact of my news-reader but
an artefact of cutting and pasting from an incompatible source code
editor.

As the moderator who accepted this post my hands were tied because
format is not a reason for rejection, but perhaps readability ought to
be. We can reject for excessive source code, perhaps we should also
have an allowance for rejection for too many blank lines:-) What do
others think?

The message was x-posted to c.l.c++ and c.l.c++.m. It appeared at the
same time in both. It seems that it has to be approved for c.l.c++.m
in order to appear even in c.l.c++.

I am sure we're not going to solve the x-posting "problem" at this time,
but I would consider it unfair if a posting doesn't get to c.l.c++ if
moderators of c.l.c++.m decide to reject it for c.l.c++.m (whatever the
reason, and however justified it might be). Just a thought.

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

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[kanze]

Francis Glassborow wrote:

In article <11**********************@p79g2000cwp.googlegroups .com>,
Ninan <ni****@yahoo.com> writes

Is this a good design for myClass in the example below? Are
there better alternatives for m_oA and myCallback? struct
apiA, and function apiFn () are not in my control, as they
are standard api supplied by the exchange for which I am
writing the application. Also the member variable m_oA
logically belongs to myClass

This post is a wonderful example of how too much whitespace is
as bad (or possibly worse) as too little. I do not have the
time to reformat the code and without doing that I find it
unreadable.
Well, it's one of the easiest formatting problems to correct:-).
I am pretty sure that the problem (every line of source code
has an extra blank line added to it) is not an artefact of my
news-reader but an artefact of cutting and pasting from an
incompatible source code editor. As the moderator who accepted this post my hands were tied
because format is not a reason for rejection, but perhaps
readability ought to be. We can reject for excessive source
code, perhaps we should also have an allowance for rejection
for too many blank lines:-) What do others think?

It's a sad fact of life that some of the tools we use mangle
formats. I don't think that there's anyway to avoid it
completely. Code without any indentation is worse than the
extra blank lines, and at one time, Google stripped all leading
white space when posting. Once I realized this, I started
inserting a '|' at the start of each line in a code example.
But sometimes I'd forget, and of course, there were a lot of
postings before I'd realized that there was a problem. In this
case, while the problem might be in the copy/paste, as you
suggest, I wouldn't put it past his newsreader to have inserted
an extra empty line before any line which didn't start in the
first column. In which case, I couldn't possibly have been
aware of the problem before seeing the posting appear.

And if you reject because of extra lines, what about because of
wrapped lines---things like:

std::cout << "In callback " << pA->a << " " << pA->b <<
std::endl;

or

//Simple illustration only. In real life callback fn will be
called later pA->a = 18;

I find that this plays even more havoc to readability,
especially when what is wrapped is part of a comment. And
there's an awful lot of newsreader software which silently
wraps. Sometimes just visibly, so the poster thinks everything
is formatted correctly, but the posting contains lines with a
couple of hundred characters, or more.

So while I agree with you that it's not nice, and I think that
we should lobby newsreader providers to do the right thing, I
don't think it reasonably, today, to reject such postings.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[kanze]

Victor Bazarov wrote:

Francis Glassborow wrote:
[...]

As the moderator who accepted this post my hands were tied
because format is not a reason for rejection, but perhaps
readability ought to be. We can reject for excessive source
code, perhaps we should also have an allowance for rejection
for too many blank lines:-) What do others think?

The message was x-posted to c.l.c++ and c.l.c++.m. It
appeared at the same time in both. It seems that it has to be
approved for c.l.c++.m in order to appear even in c.l.c++. I am sure we're not going to solve the x-posting "problem" at
this time, but I would consider it unfair if a posting doesn't
get to c.l.c++ if moderators of c.l.c++.m decide to reject it
for c.l.c++.m (whatever the reason, and however justified it
might be). Just a thought.

That's the way newsgroups work, by definition. If a message is
cross posted, it must be approved by the moderators in every
moderted group it is posted to in order for it to appear
anywhere. A cross posted message is a single message that is
either present or absent on a server; if it is present, it is
visible in all of the groups it is cross-posted to. Moderation
occurs upstream, and determines whether a message will be
propagated to the servers or not.

--
James Kanze GABI Software
Conseils en informatique orient��e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S��mard, 78210 St.-Cyr-l'��cole,
France, [phone]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]