C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Passing member variables as function parameters          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Ninan Guest Posted: Tue Jun 20, 2006 2:51 pm    Post subject: Passing member variables as function parameters 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! ] Back to top Francis Glassborow Guest Posted: Tue Jun 20, 2006 7:08 pm    Post subject: Re: Passing member variables as function parameters In article <1150752333.436609.180830 (AT) p79g2000cwp (DOT) googlegroups.com>, Ninan <nin234 (AT) yahoo (DOT) com> writes Quote: 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! ] Back to top Joshua Lehrer Guest Posted: Wed Jun 21, 2006 2:55 pm    Post subject: Re: Passing member variables as function parameters Ninan wrote: Quote: 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! ] Back to top Victor Bazarov Guest Posted: Wed Jun 21, 2006 2:58 pm    Post subject: Re: Passing member variables as function parameters Francis Glassborow wrote: Quote: In article <1150752333.436609.180830 (AT) p79g2000cwp (DOT) googlegroups.com>, Ninan <nin234 (AT) yahoo (DOT) 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! ] Back to top kanze Guest Posted: Wed Jun 21, 2006 3:15 pm    Post subject: Re: Passing member variables as function parameters Francis Glassborow wrote: Quote: In article <1150752333.436609.180830 (AT) p79g2000cwp (DOT) googlegroups.com>, Ninan <nin234 (AT) yahoo (DOT) 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:-). Quote: 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, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze Guest Posted: Sat Jun 24, 2006 6:02 am    Post subject: Re: Passing member variables as function parameters Victor Bazarov wrote: Quote: Francis Glassborow wrote: [...] Quote: 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, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.