[
https://issues.apache.org/jira/browse/TS-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14066006#comment-14066006
]
James Peach commented on TS-2943:
---------------------------------
I don't much like the {{SR_TRAITS}} naming convention. Maybe this is a good
candidate for a namespace, since the traits are localized and really only used
in the typedefs.
{{ats_scoped_str(size_t n)}} seems dangerous. I'd prefer to use a pattern like
{code}
ats_scoped_str foo((char *)ats_malloc(32));
{code}
I'd prefer the longer {{ats_scoped_string}} to {{ats_scoped_str}}.
Is this API enough to nuke {{xptr}} and {{xfd}}?
I know there was a vote at one point, but do we really need to have the
{{ats_}} prefix on internal APIs? I'd much rather just do {{scoped_string}} and
{{scoped_object}} ...
Should {{ats_scoped_fd}} use {{SR_TRAITS_FD::isValid()}} internally?
What's with the assignment operators? It looks like the {{scoped_resource}} one
should be enough, but apparently not?
> Add scoped resource class to help clean up resource leaks.
> ----------------------------------------------------------
>
> Key: TS-2943
> URL: https://issues.apache.org/jira/browse/TS-2943
> Project: Traffic Server
> Issue Type: New Feature
> Components: Core
> Reporter: Alan M. Carroll
> Attachments: ts-2943.diff
>
>
> Create a set of template classes to handle contingently allocated resources
> in a cleaner and more robust way. This holds the resource and destroys it if
> it goes out of scope, with the ability to release the resource after all
> contingent checks have been done. It is modeled on the current xptr class but
> with more generality and better naming.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
