[PATCH] Initial pass at API design for DebugInfo/PDB

[Zachary Turner]

I was thinking it might still be useful for people who knew what they were
doing and who wanted to write some implementation-specific code to be able
to get at the native native interface.  Like in this case a raw COM
pointer.  In theory this shouldn't ever be necessary, but it's hard to say
without knowing anything about implementation strategies other than DIA how
much compatibility someone would be able to achieve, and if there ever
might be things that are only possible to implement in terms of one API but
not the other.  So I didn't want to prematurely remove the possibility to
get at the native interface, for example by writing
static_cast<DIASymbol*>(PDBSymbol::getRawSymbol())->someDIAOnlyMethod().

On Tue Feb 03 2015 at 3:19:11 PM David Blaikie <dblaikie at gmail.com> wrote:

> On Tue, Feb 3, 2015 at 3:11 PM, Zachary Turner <zturner at google.com> wrote:
>
>> ================
>> Comment at: include/llvm/DebugInfo/PDB/IPDBRawSymbol.h:193
>> @@ +192,3 @@
>> +  virtual bool isVirtualInheritance() const = 0;
>> +  virtual bool isVolatileType() const = 0;
>> +};
>> ----------------
>> dblaikie wrote:
>> > How're these functions going to communicate failure?
>> Undefined in theory, probably false in practice.  You shouldn't call
>> methods on the raw interface unless you know it's a valid method.
>>
>> For the purposes of a dumper who wanted to detect unknown / unexpected
>> fields, that knowledge could all be encapsulated in the implementation of
>> the raw interface.  For example, you could have PDBSymbol::dump() which
>> calls RawSymbol->dump(), and that particular implementation can go to the
>> native API instead of calling the friendly accessors.
>>
>
> Ah - that's a bit different from what I was thinking from our previous
> discussion.
>
> If it's undefined behavior, then it might be appropriate to hide
> PDBRawSymbol from users entirely - they might as well be casting down to
> the specific type and using those functions instead, perhaps? (I was
> thinking clients would be able to use PDBRawSymbol and just call all the
> functions and swallow the failures when they would call the wrong functions)
>
>
> - David
>
>
>>
>> http://reviews.llvm.org/D7356
>>
>> EMAIL PREFERENCES
>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150203/5d4c089e/attachment.html>