Re: programmatically create a TClass at runtime

 > so now, to tackle the Go-slices so they are properly recognized as

> collections, do I understand correctly that I "just" need to implement a
> 'createCollFuncTable' FunctionTypeBuilder with the correct 'size',
> 'feed', ... slots ?

Assuming that Cintex probably see them and propagate them, yes it should.

> or should I just grab the TClass corresponding to the new Reflex::Type
> and call TClass::SetCollectionProxy(go_slice_proxy) ?

This would also work.

Cheers,
Philippe.

On 5/10/11 12:02 PM, Sebastien Binet wrote:
> Philippe,
>
> On Wed, 4 May 2011 12:42:52 -0500, Philippe Canal<pcanal_at_fnal.gov> wrote:
>> Hi Sebastien,
>>
>> The work need is similar to the work done by Cintex for Reflex.
>> For example the answer to your direct question is somewhat
>> in the file cint/cintex/src/ROOTClassEnhancer.cxx
> thanks. I think "I know kung-fu now".
>
> I actually went using/wrapping the Reflex(TypeBuilder) API as it is
> somewhat more straightforward than the G__stuff one (or perhaps it is
> b/c I am more familiar with the Reflex one ?)
>
> probably not the most efficient use of CPU cycles but I can read/write
> simple structs...
>
> so now, to tackle the Go-slices so they are properly recognized as
> collections, do I understand correctly that I "just" need to implement a
> 'createCollFuncTable' FunctionTypeBuilder with the correct 'size',
> 'feed', ... slots ?
>
> I fear they won't be completely properly handled as most of the code I
> have seen relies on TClassEdit::IsSTLCont(typename_str) to decide if a
> type is collection-like...
> or should I just grab the TClass corresponding to the new Reflex::Type
> and call TClass::SetCollectionProxy(go_slice_proxy) ?
>
> -s
>
>> Cheers,
>> Philippe.
>>
>> On 5/4/11 12:00 PM, Sebastien Binet wrote:
>>> hi there,
>>>
>>> I am playing with Go (the language at golang.org) and trying to see if
>>> one could use ROOT as an I/O back-end.
>>>
>>> Go has built-in reflection capabilities so theoretically any Go struct
>>> can be described at runtime/compiletime and converted to a Reflex or
>>> CINT metadata.
>>> Moreover, Go-struct usually have the same layout than their C cousin
>>> (that's not true for Go-strings and Go-slices (which are views into
>>> arrays))
>>>
>>> the amount of work on my side to be able to support the below kind of
>>> code should be rather minimal:
>>>
>>> // ---
>>> type MyStruct struct {
>>> IntData [10]int32
>>> FloatData [20]float64
>>> }
>>>
>>> f := ROOT.NewFile("foo.root", "recreate")
>>> t := ROOT.NewTree("tree", "title")
>>> s := MyStruct{}
>>> t.Branch("mystruct",&s) //<---
>>> // ---
>>>
>>> From my end, I would need to create a ROOT::TClass instance for the
>>> Go-struct MyStruct leveraging Go's "reflect" package which knows the types
>>> and offsets of each data member.
>>>
>>> is this possible without reaching to automatically generated code ?
>>> (rootcint|genreflex)
>>> that would simplify the amount of infrastructure to provide...
>>>
>>> -s
>>>
>>> PS: right now, I am just unfolding the struct and register branches like
>>> so (in pseudo-code):
>>> for f := range typ.Fields() {
>>> s := "mystruct_"+f.Name()
>>> field_addr := obj.Address()+f.Offset()
>>> branch_typ := s+"/"+go2ctype[f.Type()].Name()
>>> tree.Branch(s, field_addr, branch_typ)
>>> }
>>>
Received on Tue May 10 2011 - 19:48:27 CEST