From lechner@cs.uml.edu Fri Nov 10 19:58:27 2006 Received: from saturn.cs.uml.edu (saturn.cs.uml.edu [129.63.8.2]) by earth.cs.uml.edu (8.12.11.20060308/8.11.6) with ESMTP id kAB0wR31002989; Fri, 10 Nov 2006 19:58:27 -0500 Received: from saturn.cs.uml.edu (localhost [127.0.0.1]) by saturn.cs.uml.edu (8.12.9/8.12.9) with ESMTP id kAB0wQHo378638; Fri, 10 Nov 2006 19:58:26 -0500 (EST) Received: (from lechner@localhost) by saturn.cs.uml.edu (8.12.9/8.12.9/Submit) id kAB0wQd7378062; Fri, 10 Nov 2006 19:58:26 -0500 (EST) From: Bob Lechner Message-Id: <200611110058.kAB0wQd7378062@saturn.cs.uml.edu> Subject: Re: asgnt3 cguffey update 11/9 - more ideas. RJLFdbk3 To: cguffey@gmail.com (Chris Guffey) Date: Fri, 10 Nov 2006 19:58:26 -0500 (EST) Cc: alison_lea@yahoo.com, kbagley@us.ibm.com, cguffey@gmail.com, agabriel@cs.uml.edu, nitin.sonawane@verizon.net, nsonawan@cs.uml.edu (Nitin Sonawane), nitin.sonawane@gmail.com, lechner@cs.uml.edu (Bob Lechner) In-Reply-To: <2da105360611101614n2e67019fg99ab1c3fb10c7682@mail.gmail.com> from "Chris Guffey" at Nov 10, 2006 07:14:03 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Status: X-Keywords: X-UID: 1483 Status: RO > From cguffey@gmail.com Fri Nov 10 19:14:17 2006 > From: "Chris Guffey" > To: "Bob Lechner" > Subject: Re: asgnt3 cguffey update 11/9 - some ideas. RJLFdbk2 > Cc: alison_lea@yahoo.com, kbagley@us.ibm.com, agabriel@cs.uml.edu, > nitin.sonawane@verizon.net, "Nitin Sonawane" , > nitin.sonawane@gmail.com RJLRef: $PHJ/06f522/agnt3/asgnt3_cg_RJLFdbk061110.1900 > > On 11/10/06, Bob Lechner wrote: > > > From cguffey@gmail.com Fri Nov 10 12:13:06 2006 > > > From: "Chris Guffey" > > > To: "Bob Lechner" > > > Subject: Re: asgnt3 update 11/9 - some ideas. > > > Cc: alison_lea@yahoo.com, kbagley@us.ibm.com, agabriel@cs.uml.edu, > > > nitin.sonawane@verizon.net, "Nitin Sonawane" , > > > nitin.sonawane@gmail.com > > RJLRef: $PHJ/06f522/agnt3/asgnt3_cg_RJLFdbk061110.1800 > > > > > > I made more changes. Under this revision it is setup to look for a key > > > from the DE table only. > > > > > > I want to get inputs from people as to whether or not how it is > > > currently setup will work before going through the tediousness of > > > setting up the code for all the other tables as well. > > > > > > Under this design we need to write the following functions for each table: > > > bool GetValueFromXXCurr(char* pFName, char* pValue) > > > bool doesXXKeyExist(char* pValueList) > > > > > [RJL: Disclaimer: I have not reviewed your code yet. > > This is a reply to Chris because he sent the last request > > for clarification. but it applies to anyone else who > > is contributing to and having trouble with asgnt3.] > > > > What is it that you do not understand about the > > 3 ways I already showed you to set or get a field value? > > (once you know its fname and ftype): > > direct XXcurr->fname, pr_get_type(ptr,fname) and XXGetFname(XXcurr)? > > > > I see both functions above are specialized to some ttabb (i.e. XX). > > That's good (and inevitable). > > I presume you will replace XX with DE in GetvalueFromDEcurr()? > > > > In switch case fname I would call DEGetfname(DEGetDEid()). > > If DE were a class you could call Getfname(GetPkey()). Does this help? > > Or we could ignore encapsulation and call DEGetfname(DEcurr) instead. > > > > I think this part is ok now in rev3 that I uploaded today. > There's a keyExists that calls the keyXXExists based on the input ttabb. > > > > > > > Coding this would be so much easier using C++. > > > > > It would? I would like to see your concrete > > specific code justification for this claim. > > You are supposed to reuse chgen API code > > (wrap it but not rewrite it). > > > > For a C++ class CQ, just substitute class for struct, > > in defining CQ, make everything public, > > and write your methods. g++ will be happy: > > anychgenschema.h has lots of extern "C" > > functions e.g. bde/src/*.cc uses them. > > > > Bear in mind that RTTI is not available > > for fnames which are not types, > > STL is no help for non-unique ftypes, > > and most methods will need table-specific overrides. > > > > R Lechner > > [cut] > > > > simplified example: > pTable = GetTable("DE"); > value = pTable->GetFieldValue("FieldName"); > switch (pTable->GetFieldType("FieldName")) > { > case eI2: > ... > } > > Base classes of CTable and CValue results in one GetTable function > that can return based on the base class type. CValue could have > convert functions based on field type. Seems much less cluttered and > easier to me and it could possibly remove the reliance on side effects > as well. > Thanks for the example Cris. It makes for a better common starting point. The reliance on side effects is not C vs. C++ difference. The only diffrence is support for inheritance, which is from gencpp but not from chgen. Your implified example is practically indistinguishable from chgen-supported C-code. It is not sufficient to reveal any C vs. C++ differences in SW architecture. Like pr_*.c, it sacrifices encapsulation in favor of efficiency. This makes it more C-like than OO. What is your class model? Is there a subclass of CQ base class for each ttabb class? Or is there a template class CQ for each ttabb? if not, who not? Is class ttabb a friend of CQ or vice versa? What are content, associations, and purpose of CValue? Is it the same as struct (or class) CQ? Does it also have subclasses? Are they based on ttabb, or on CK? I repeat my invitation or challenge - compare your hand-written code to code-generation support (preferably from gencpp). Auto-generation of such code would make a good project, provided it provides generic methods for field comparison between encoded binary and ASCII versions. BTWay, such support is a good example for the application of the double-dispatch design pattern to enhance gencpp. of field values. This would be a good project focus, and is directly applicable to bde's O-O classXmethod Menu. Replacing chgen with gencpp to generate the pr_*.c files for asgnt3 might be my next step.