[
https://issues.apache.org/jira/browse/MINIFICPP-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mr TheSegfault updated MINIFICPP-678:
-------------------------------------
Description:
As per MINIFICPP-676 we should improve our long term const correctness. I agree
that this is a good idea ( thanks to [~aboda] for calling this out in his PR),
especially one that I haven't put a lot of emphasis on changing in code that
has been around a while.
For non stream or memory transfer objects, we want to maintain const
correctness. In some cases it makes sense, especially for equality comparisons
and getters to make changes. In some places it may require some evaluation and
tested. Since we are an established open source projects, might need to
safeguard certain changes and do full integration testing when we can.
In all cases, we should test all extensions before any merge. We can split
these efforts up as we see fit, but
was:
As per MINIFICPP-676 we should improve our long term const correctness. This
hasn't always been something we've improved over time, but for non stream or
memory transfer objects, we want to maintain const correctness. In some cases
it makes sense, especially for equality comparisons and getters to make
changes. In some places it may require some evaluation.
In all cases, we should test all extensions before any merge.
> Improve const correctness of code base.
> ----------------------------------------
>
> Key: MINIFICPP-678
> URL: https://issues.apache.org/jira/browse/MINIFICPP-678
> Project: NiFi MiNiFi C++
> Issue Type: Epic
> Reporter: Mr TheSegfault
> Assignee: Mr TheSegfault
> Priority: Major
>
> As per MINIFICPP-676 we should improve our long term const correctness. I
> agree that this is a good idea ( thanks to [~aboda] for calling this out in
> his PR), especially one that I haven't put a lot of emphasis on changing in
> code that has been around a while.
> For non stream or memory transfer objects, we want to maintain const
> correctness. In some cases it makes sense, especially for equality
> comparisons and getters to make changes. In some places it may require some
> evaluation and tested. Since we are an established open source projects,
> might need to safeguard certain changes and do full integration testing when
> we can.
>
> In all cases, we should test all extensions before any merge. We can split
> these efforts up as we see fit, but
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
