diff options
author | Aldy Hernandez <aldyh@redhat.com> | 2022-07-14 19:01:34 +0200 |
---|---|---|
committer | Aldy Hernandez <aldyh@redhat.com> | 2022-07-15 11:41:03 +0200 |
commit | 91a7f30662cd8da14f0ae5eec1ce13aa29f1817c (patch) | |
tree | 72d4637bf5e70ee228eba1abdffa9224a78df4cd /gcc/fortran/trans-decl.cc | |
parent | f858fe7a8b250995bc5b0d18720a2ceb6815622d (diff) | |
download | gcc-91a7f30662cd8da14f0ae5eec1ce13aa29f1817c.zip gcc-91a7f30662cd8da14f0ae5eec1ce13aa29f1817c.tar.gz gcc-91a7f30662cd8da14f0ae5eec1ce13aa29f1817c.tar.bz2 |
Implement visitor pattern for vrange.
We frequently do operations on the various (upcoming) range types.
The cascading if/switch statements of is_a<> are getting annoying and
repetitive.
The classic visitor pattern provides a clean way to implement classes
handling various range types without the need for endless
conditionals. It also helps us keep polluting the vrange API with
functionality that should frankly live elsewhere.
In a follow-up patch I will add pretty printing facilities for vrange
and unify them with the dumping code. This is a prime candidate for
the pattern, as the code isn't performance sensitive. Other instances
(?? the dispatch code in range-ops ??) may still benefit from the hand
coded conditionals, since they elide vtables in favor of the
discriminator bit in vrange.
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-range.cc (irange::accept): New.
(unsupported_range::accept): New.
* value-range.h (class vrange_visitor): New.
(class vrange): Add accept method.
(class unsupported_range): Same.
(class Value_Range): Same.
Diffstat (limited to 'gcc/fortran/trans-decl.cc')
0 files changed, 0 insertions, 0 deletions