Skip to content

introduce protected_exprt #3855

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Jan 29, 2019
Merged

introduce protected_exprt #3855

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
1280010
avoid direct access to exprt::op0()
Jan 24, 2019
6c14669
use conditional_cast instead of make_typecast
Jan 24, 2019
39d38f1
replace exprt::make_typecast() by typecast_exprt()
Jan 26, 2019
adb0533
multi_ary_exprt::opX with precondtion
Jan 25, 2019
a48f855
introduce expr_protectedt
Jan 24, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions src/util/expr.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -319,6 +319,28 @@ class exprt:public irept
const_unique_depth_iteratort unique_depth_cend() const;
};

/// Base class for all expressions. This protects low-level methods in
/// exprt that are not type safe. Depcrecated constructors are removed.
Copy link
Member

Choose a reason for hiding this comment

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

Typo in deprecated

/// This API will eventually replace exprt.
class expr_protectedt : public exprt
{
protected:
Copy link
Contributor

Choose a reason for hiding this comment

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

❓ Would it make more sense to use protected inheritance? I assume the answer is no as there remains calls to other methods, that have not been removed, but perhaps given this direction of travel it would making more sense to using them into the public section? (I think you can do this, but I have not actually tried).

Copy link
Contributor

Choose a reason for hiding this comment

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

This would circumvent the need for this class entirely and just update the classes that inherit from exprt to protected extend it and in fact allow for explicitly identifying the classes that use the wrong interface.

Copy link
Member Author

Choose a reason for hiding this comment

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

There are a lot of classes inheriting from exprt; furthermore, the interface of exprt should change as well, once we are there.

// constructors
expr_protectedt(const irep_idt &_id, const typet &_type) : exprt(_id, _type)
{
}

// protect these low-level methods
using exprt::add;
using exprt::make_bool;
using exprt::make_typecast;
using exprt::op0;
using exprt::op1;
using exprt::op2;
using exprt::op3;
using exprt::remove;
};

class expr_visitort
{
public:
Expand Down
4 changes: 2 additions & 2 deletions src/util/std_expr.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -167,8 +167,8 @@ extractbits_exprt::extractbits_exprt(
const exprt &_src,
const std::size_t _upper,
const std::size_t _lower,
const typet &_type):
exprt(ID_extractbits, _type)
const typet &_type)
: expr_protectedt(ID_extractbits, _type)
{
PRECONDITION(_upper >= _lower);
operands().resize(3);
Expand Down
Loading