Skip to content

Conversation

@tautschnig
Copy link
Collaborator

Please review commit-by-commit. The common theme to this PR is a review of all uses of "".

  • Each commit message has a non-empty body, explaining why the change was made.
  • n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • n/a My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

Copy link
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✔️
Passed Diffblue compatibility checks (cbmc commit: 8add28f).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/99533608

Copy link
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✔️
Passed Diffblue compatibility checks (cbmc commit: 465e0cc).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/99770135

@owen-mc-diffblue
Copy link
Contributor

The test failure appears to be clang-format complaining about one line

Copy link
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️
This PR failed Diffblue compatibility checks (cbmc commit: 385b7f8).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/105262938
Status will be re-evaluated on next push.
Common spurious failures:

  • the cbmc commit has disappeared in the mean time (e.g. in a force-push)

  • the author is not in the list of contributors (e.g. first-time contributors).

  • the compatibility was already broken by an earlier merge.

Copy link
Collaborator

@martin-cs martin-cs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this patch does what it claims to. I think it may even improve performance very slightly but I have to know -- why did you decide to do this?

@tautschnig
Copy link
Collaborator Author

why did you decide to do this?

In some prior PR I had something like symbol_exprt("", ...) and someone reminded me that using irep_idt() would be more efficient. Fixing that one instance was easy, but I don't really like doing half a job...

bool show_full,
const std::string &json_file_name);
const std::string &json_output_file_name = "");

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about actually using optionalt?

@kroening
Copy link
Collaborator

On Use s.empty() instead of s == "":
This may be a case of premature optimisation. Note that the implementation of == on std::string and char * is as follows:

    size_t __rhs_len = _Traits::length(__rhs);
    if (__rhs_len != __lhs.size()) return false;
    return __lhs.compare(0, _String::npos, __rhs, __rhs_len) == 0;

_Traits::length("") will be a compile-time zero; so there is likely no performance benefit. We would need to be convinced that .empty() is indeed better readable than !=""

@kroening
Copy link
Collaborator

There are a couple of cases where one might obtain better clarity by using optionalt instead of the empty-string as indicator of "no value", but that's beyond this PR.

@tautschnig tautschnig assigned tautschnig and unassigned kroening Apr 30, 2019
@tautschnig tautschnig changed the title Cleanup use of empty strings Cleanup use of empty strings [depends-on: #4591] Apr 30, 2019
tautschnig added a commit that referenced this pull request Apr 30, 2019
config.main is now optionalt<string> [blocks: #4041]
We previously passed in empty strings. Make explicit that the argument is not
required.
The use of "" requires constructing a std::string or dstringt, and then a string
comparison. empty() is just an integer comparison (both for std::string an
dstringt).
Both std::string and dstringt are default-initialised to an empty string.
The use of "" requires constructing a std::string or dstringt, and then a
string comparison. empty() is just an integer comparison (both for std::string
an dstringt).
Constructing a dstringt from a C string requires a string table lookup, while
the default constructor for a dstringt just zero-initialises an unsigned.
This avoids string table lookups.
Appending "" to a string has no effect.
This avoids constructing an object when we can just use an integer comparison.
@tautschnig tautschnig changed the title Cleanup use of empty strings [depends-on: #4591] Cleanup use of empty strings Apr 30, 2019
@tautschnig tautschnig merged commit d6eae52 into diffblue:develop Apr 30, 2019
@tautschnig tautschnig deleted the empty-string branch April 30, 2019 23:54
kroening added a commit that referenced this pull request May 1, 2019
This is follow-up of #4041.  It avoids the use of an empty string as
indicator of 'no value'.
@kroening kroening mentioned this pull request May 1, 2019
3 tasks
kroening added a commit that referenced this pull request May 1, 2019
This is follow-up of #4041.  It avoids the use of an empty string as
indicator of 'no value'.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants