davide added inline comments.

================
Comment at: lldb/source/Commands/CommandObjectStats.cpp:43-46
+    target->RegisterStats(StatisticKind::ExpressionSuccessful);
+    target->RegisterStats(StatisticKind::ExpressionFailure);
+    target->RegisterStats(StatisticKind::FrameVarSuccess);
+    target->RegisterStats(StatisticKind::FrameVarFailure);
----------------
labath wrote:
> davide wrote:
> > labath wrote:
> > > Are you planning to have some kind of decentralized method of registering 
> > > statistics?
> > > If not, then I don't see a need for explicitly registering the statistic 
> > > kinds here, since the single source of truth about the available kinds 
> > > can be StatisticKind enum, and Target can just get the list from there 
> > > automatically when need (when stats are enabled?)
> > > 
> > > This way we could even simplify the code by avoiding the "statistic is 
> > > not registered but someone still called IncrementStats" state altogether) 
> > > and the stats map could be a simple array with NumStatistics elements.
> > No. I originally thought to make it that way but I have to say that maybe 
> > it's easier to have a centralized mechanism. I'm still unsure whether this 
> > should be a vector or a map, I'll think about it more.
> llvm manual recommends 
> <http://llvm.org/docs/ProgrammersManual.html#map-like-containers-std-map-densemap-etc>
>  vector as a first choice data structure for a map. :P
Allright, you convinced me :)


https://reviews.llvm.org/D45547



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to