 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Daniel
Guest
|
 Posted: Fri Feb 03, 2006 5:00 pm Post subject: Implicit parameter |
 |
|
Hello,
I'm working on a database project. When the user sets some data on a
database object, the corresponding member function looks up the table
storing the data for the object, as well as the objects record index
into that table. It then forwards the call to corresponding the table's
member, which finally sets the data:
// declaration of table() function:
Table* table(Object*, RecordIndex&);
// sample member function of Object
void Object::setData(int data)
{
RecordIndex idx;
table(this, idx)->setData(idx, width);
}
I have a very large number of such lookup/forward member functions, and
I'm looking for a way to simplify the code. I would like to get rid of
the RecordIndex. Idealy, the body of Object::setData should look like
this:
table2(this)->setData(width);
So, whatever table2() is returning, it contains not only the Table
pointer, but also the correct record index. Somehow, this returned
object then calls the setData() member of the Table, auto-magically
binding the record index to the first (could also be the last)
parameter.
Short of using inline assembly, I can't seem to come up with a suitable
solution. Also, writing a proxy class that stores the record index and
then repeats all member functions of the Table class w/o the index kind
of defeats the purpose of simplifying the code.
I could use parameter binding as in boost::bind. The call would then
look something like this:
TableProxy()(this, &Table::setData, width);
But that doesn't look much simpler than the original code, does it ?
I guess my question is: is there a known way of returning two
parameters from one function and pass those to another function,
without actually naming those parameters. Something like a "paired
this" pointer ?
Thank you,
Daniel
--
Daniel Gehriger
<http://www.linkcad.com>
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Greg Herlihy
Guest
|
| Posted: Sat Feb 04, 2006 8:00 pm Post subject: Re: Implicit parameter |
|
|
Daniel wrote:
| Quote: | Hello,
I'm working on a database project. When the user sets some data on a
database object, the corresponding member function looks up the table
storing the data for the object, as well as the objects record index
into that table. It then forwards the call to corresponding the table's
member, which finally sets the data:
// declaration of table() function:
Table* table(Object*, RecordIndex&);
// sample member function of Object
void Object::setData(int data)
{
RecordIndex idx;
table(this, idx)->setData(idx, width);
}
I have a very large number of such lookup/forward member functions, and
I'm looking for a way to simplify the code. I would like to get rid of
the RecordIndex. Idealy, the body of Object::setData should look like
this:
table2(this)->setData(width);
So, whatever table2() is returning, it contains not only the Table
pointer, but also the correct record index. Somehow, this returned
object then calls the setData() member of the Table, auto-magically
binding the record index to the first (could also be the last)
parameter.
Short of using inline assembly, I can't seem to come up with a suitable
solution. Also, writing a proxy class that stores the record index and
then repeats all member functions of the Table class w/o the index kind
of defeats the purpose of simplifying the code.
I could use parameter binding as in boost::bind. The call would then
look something like this:
TableProxy()(this, &Table::setData, width);
But that doesn't look much simpler than the original code, does it ?
I guess my question is: is there a known way of returning two
parameters from one function and pass those to another function,
without actually naming those parameters. Something like a "paired
this" pointer ?
|
I don't see a way to solve such a narrowly defined problem especially
when the requirement to be met (of simplifying the code) is so broadly
stated. As I see it, there are really two, not particularly compatible
ways of simplifying a program's code. One way to simplify code is the
obvious way: to pare down, consolidate re-use, re-factor the code. I
don't see much room for that kind of simplification here - given that a
record, its table and the record index are still going to be needed. So
whatever changes are to be made are unlikely to reduce the either the
amount or the total complexity of the application's existing code.
The other kind of simplification is to simplify a client interface -
that is, reduce the amount and complexity of code which a client needs
to write in order to make good use of the interface. Note that this
kind of simplification may in fact increase the total amount of code
because logic may have to be transferred from the client and be made
part of the implementation. But this one time charge is to be weighed
against the recurring benefit realized by each new client who is able
to take advantage of the more streamlined interface. In other words, a
small upfront investment should pay dividends well into the future. For
this kind of simplification, the current interface as described
certainly seems to offer ample opportunity to reduce the interface's
complexity through judicious use of encapsulation and abstraction.
For example, I would expect that a client should be able manipulate a
record without needing to know anything about tables or record ids. A
record's persistent data storage (if it has any) could be viewed as an
implementation detail. Of course any reworking of the interface needs
to take into account the exisiting implementation. So I would suggest
adhering to the "open-closed" principle and not rip out a lot of
existing, working code. Rather the approach would be to layer this
improved interface over the existing one.
For example, an "ObjectRef" class could encapsulate the object pointer,
table pointer and record index. So from the client's perspective,
setting the width of an object represented with one of these classes
would become something like:
ObjectRef object( objectPtr );
object.SetData(width);
Certainly there is more code that would have to be written to make this
kind of interface possible. But this kind of "pass through" code does
not greatly increase the overall complexity of the application. And the
benefit for clients is clear. An interface free of tables and record
ids, is more streamlined, more simple, more maintainable and simply
much easier to use - in my opinion.
So to answer the original question, I would say no. At least I don't
see any way to make such a function call without having to resort to
some kind of a "hack" that would be neither simple nor robust.
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Bob Hairgrove
Guest
|
| Posted: Sun Feb 05, 2006 2:00 am Post subject: Re: Implicit parameter |
|
|
On 3 Feb 2006 10:55:10 -0500, "Daniel" <gehriger (AT) linkcad (DOT) com> wrote:
| Quote: | I have a very large number of such lookup/forward member functions, and
I'm looking for a way to simplify the code.
|
I would just define a default value for that column in the database
table ... talk to your DBA if necessary.
--
Bob Hairgrove
NoSpamPlease (AT) Home (DOT) com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Daniel
Guest
|
| Posted: Sun Feb 05, 2006 6:00 pm Post subject: Re: Implicit parameter |
|
|
Greg Herlihy wrote:
| Quote: | For example, I would expect that a client should be able manipulate a
record without needing to know anything about tables or record ids. A
record's persistent data storage (if it has any) could be viewed as an
implementation detail. Of course any reworking of the interface needs
to take into account the exisiting implementation. So I would suggest
adhering to the "open-closed" principle and not rip out a lot of
existing, working code. Rather the approach would be to layer this
improved interface over the existing one.
For example, an "ObjectRef" class could encapsulate the object pointer,
table pointer and record index. So from the client's perspective,
setting the width of an object represented with one of these classes
would become something like:
ObjectRef object( objectPtr );
object.SetData(width);
Greg, |
Thank you for your reply. Actually, the code I'm talking about is
inside a library. A client won't see or know about tables, but uses
just the interface you describe.
Daniel
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Stephan Brönnimann
Guest
|
| Posted: Mon Feb 06, 2006 11:00 am Post subject: Re: Implicit parameter |
|
|
Daniel wrote:
| Quote: | Hello,
I'm working on a database project. When the user sets some data on a
database object, the corresponding member function looks up the table
storing the data for the object, as well as the objects record index
into that table. It then forwards the call to corresponding the table's
member, which finally sets the data:
// declaration of table() function:
Table* table(Object*, RecordIndex&);
// sample member function of Object
void Object::setData(int data)
{
RecordIndex idx;
table(this, idx)->setData(idx, width);
}
I have a very large number of such lookup/forward member functions, and
I'm looking for a way to simplify the code. I would like to get rid of
the RecordIndex. Idealy, the body of Object::setData should look like
this:
table2(this)->setData(width);
|
I've intentionally cut a big part of your posting, hopefully not the
relevent part ...
Why not modify the class Object:
class Object {
public:
RecordIndex idx() const;
private:
friend class Table;
void setIdx(const RecordIndex& newIdx);
};
| Quote: | From your statements I have a doubt that only the class Table maintains
the relationship Object <-> RecordIndex. |
My design assumes that each instance of Object knows its own record
index. This is true for objects read from the database and false for
newly created objects. It the latter case Table must generate a
temporary record index and assign it to the object. Note: the temp.
record index can be used to distinguish between inserts and updates
when the objects are permanently stored at a later stage.
Regards, Stephan
broeni@osb-systems.com
Open source rating and billing engine for communication networks.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
|
|
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
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
