Hello, all, I really do not like playing with arguments and classes internal
data that have the same name:
class DerivedExprNode : public TypedNode<ValueExprNode,
ExprNode::TYPE_DERIVED_EXPR>
{
public:
....
virtual void findDependentFromStreams(const OptimizerRetrieval*
optRet,
-> SortedStreamList* streamList);
....
-> Firebird::Array<USHORT> streamList;
I think that playing here with streamList vs this->streamList is a recipe
for misreading the code and making mistakes:
void DerivedExprNode::findDependentFromStreams(const OptimizerRetrieval*
optRet,
SortedStreamList* streamList)
{
1 arg->findDependentFromStreams(optRet, streamList);
2 for (USHORT* i = this->streamList.begin(); i !=
this->streamList.end(); ++i)
{
int derivedStream = *i;
if (derivedStream != optRet->stream &&
(optRet->csb->csb_rpt[derivedStream].csb_flags &
csb_active))
{
3 if (!streamList->exist(derivedStream))
4 streamList->add(derivedStream);
}
}
}
I would rather rename the member data to internalStreamList instead of the
param since the other redefinitions of the virtual function use the same
signature. Besides, I wonder why we use a custom definition for this stream
list,
Firebird::Array<USHORT> streamList;
probably in this case, it's better than the canonical definition
typedef Firebird::HalfStaticArray<UCHAR, OPT_STATIC_ITEMS> StreamList;
that other places use?
Or do people prefer the code as it's now? Comments, please.
C.
---
Claudio Valderrama C. - www.cvalde.net
Consultant, SW developer.
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
