STL and ATS (not sitting in a tree ...)

[Leif Hedstrom <zw...@apache.org>]

Hi all,

this is just a gentle reminder:


We don’t use STL generally. There are exceptions, but unless there are truly good reasons for it, just don’t use it. Even if it’s not on the critical path. We have plenty of containers and tools to do similar things. Yes, they are not as “neat” as STL, but it’s worth taking the time to understand them, and improve upon them when needed.

There are exceptions, of course:

1) In plugins, we generally don’t say anything, since the user(s) always has the option *not* to use a plugin they don’t like. We also have no way currently to expose our core data structures through the C API.

2) In standalone tools, such as traffic_ctl, traffic_layout, and traffic_logstats, it’s all free for all. it doesn’t mean you should make those intentionally slow, but it is not worth going through hoops to use our performance optimized containers for these tools, when STL works just fine.


Thanks,

— leif

Re: STL and ATS (not sitting in a tree ...)

[Nick Kew <ni...@apache.org>]

On Fri, 10 Jul 2015 13:41:52 -0600
Leif Hedstrom <zw...@apache.org> wrote:

> Hi all,
> 
> this is just a gentle reminder:
> 
> 
> We don’t use STL generally. There are exceptions, but unless there are truly good reasons for it, just don’t use it. Even if it’s not on the critical path. We have plenty of containers and tools to do similar things. Yes, they are not as “neat” as STL, but it’s worth taking the time to understand them, and improve upon them when needed.
> 
> There are exceptions, of course:
> 
> 1) In plugins, we generally don’t say anything, since the user(s) always has the option *not* to use a plugin they don’t like. We also have no way currently to expose our core data structures through the C API.
> 
> 2) In standalone tools, such as traffic_ctl, traffic_layout, and traffic_logstats, it’s all free for all. it doesn’t mean you should make those intentionally slow, but it is not worth going through hoops to use our performance optimized containers for these tools, when STL works just fine.

I guess the timing of this just after I used STL in the
stream-editor plugin might not be entirely coincidental?

This comes back to my bugbear of API review.  If we have
containers and tools to do similar things, we should expose
them in an API, and with a stability promise.

The exercise could be a beneficial review, too.

-- 
Nick Kew