On Mon, Sep 6, 2021 at 5:21 PM lxsameer <lxsameer at lxsameer.com> wrote:
> I think a bit of pseudo code might be good to demonstrate roughly what I
> had in mind:
> ```
> template <typename ConcreteType, template <typename T> class...
Traits>
> class WithTrait : public Traits<ConcreteType>... {
> protected:
> WithTrait(){};
> friend ConcreteType;
> };
>
> template <typename ConcreteType, template <typename> class
TraitType>
> class TraitBase {
> protected:
> ConcreteType &Object() { return static_cast<ConcreteType
&>(*this); };
> };
>
> template <typename ConcreteType>
> class SourceMgr : public TraitBase<ConcreteType, SourceMgr> {
> public:
> .... source mgr interface functions ....
> };
>
> class DefaultSourceMgr : public WithTrait<DefaultSourceMgr,
SourceMgr> {
> ..... implementation ....
> }
> ```
> This way function that want to use SourceMgr would need a template but
> that template can be defaulted to `DefaultSourceMgr`. I hope I could
> demonstrate my thoughts clear enough.
>
Yep yep. Not sure what the specific purpose of all the various abstractions
there would be, but get the gist of the architecture.
> As for the functionality I need in the sourcemgr, my compiler uses
> namespaces as the center piece and the unit of compilation, i want my
> source manager to accept a namespace name and load the source code of that
> namespace. At the moment I had to copy paste the llvm::SourceMgr and
> manually tweak it.
>
Perhaps there's something narrower that could be added directly to the
existing SourceMgr (perhaps something fairly general/not specific to the
particular features you're designing for, but addressing whatever in
SourceMgr doesn't make it suitable for that direction/gets in the way)? I
suspect if the extension is too invasive that way, or such that it would
require the kind of abstraction/templates suggested above - it might be
that SourceMgr isn't a great foundation for the functionality you're
building.
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, September 7th, 2021 at 1:03 AM, David Blaikie <
> dblaikie at gmail.com> wrote:
>
> On Mon, Sep 6, 2021 at 4:58 PM lxsameer <lxsameer at lxsameer.com>
wrote:
>
>> Sorry about the terminology, I was thinking about CRTP style traits. I
>> see CRTP based classes and templates quite often it the LLVM source
code.
>>
>
> Yeah, there's a fair bit of CRTP, and traits, but they are different
> things -
> https://www.internalpointers.com/post/quick-primer-type-traits-modern-cpp
> discusses traits, for some details.
>
>
>> So I think the current SourceMgr can be renamed to something like
>> `DefaultSourceManager` that implement the `SourceMgr` CRTP trait (
sorry I
>> don't know the exact term here).
>>
>
> I'm still a bit unclear on how the existing SourceMgr-using code would
> work - it'd have to be updated to be templated on the specific
SourceMgr
> implementation in use, would it? Some other ideas?
>
> Might be worth a more narrowly defined discussion about what
> extensibility/features you're looking for in SourceMgr, without the
need to
> create a whole new hierarchy.
>
>
>>
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Tuesday, September 7th, 2021 at 12:50 AM, David Blaikie <
>> dblaikie at gmail.com> wrote:
>>
>> On Mon, Sep 6, 2021 at 3:59 PM lxsameer via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hey folks,
>>> Hope you're doing well.
>>>
>>>
>>> It seems to me that it is not possible to extend the current
behavior
>>> of `llvm::SourceMgr` (at least I couldn't think of any
solution) and it is
>>> quite C/C++ish ( for lack of a better word).
>>>
>>> For my use case, I need to tweak it a little bit and since there is
now
>>> way to do that, I have to write my own which means I'm going to
lose the
>>> ability to use any llvm api that expect a source manager and
that's a big
>>> price to pay.
>>>
>>> It seems that the source manger will benefits from a trait like
design.
>>> This way, any front end that need a customized source manager can
easily do
>>> that and the current source manager would be an implementation of
that
>>> trait.
>>>
>>
>> I /think/ the C++ terminology that's a closer match for what
you're
>> describing might be a "concept" rather than a
"trait"?
>>
>> But then, if I'm understanding correctly, all the code that
currently is
>> written in terms of the SourceMgr would have to become a template so it
can
>> be used by different implementations of the SourceMgr concept? That, at
>> first guess, seems unlikely/infeasible?
>>
>> - Dave
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210906/a064a462/attachment-0001.html>