Unnecessary (?) warnings reading `unique_ptr`

[Axel-Naumann]

From https://root-forum.cern.ch/t/segmentation-error-when-i-try-to-draw-a-histogram/47392

Opening https://root-forum.cern.ch/uploads/short-url/vue07kduqCLe9dhZ3MGW8pLWja0.root shows

root [0] 
Attaching file file05.root as _file0...
Warning in <TStreamerInfo::Build>: unique_ptr<TH1F,default_delete<TH1F> >: __uniq_ptr_data<TH1F,default_delete<TH1F>,true,true> has no streamer or dictionary, data member "_M_t" will not be saved
Warning in <TClass::Init>: no dictionary for class __compressed_pair<TH1F*,default_delete<TH1F> > is available
Warning in <TClass::Init>: no dictionary for class __compressed_pair_elem<TH1F*,0,false> is available
Warning in <TClass::Init>: no dictionary for class __compressed_pair_elem<default_delete<TH1F>,1,true> is available
(TFile *) 0x5617370bbe70

That's on Ubuntu 20.04.

[linev]

Here is content of the file (thanks to @bellenot one can now browse files from forum):

https://root.cern/js/latest/?file=https://root-forum.cern.ch/uploads/short-url/vue07kduqCLe9dhZ3MGW8pLWja0.root&item=StreamerInfo

Seems to be, not TH1F but std::unique_ptr<TH1F> was written into the file. Not sure if such usecase handled by I/O.

[dpiparo]

Can't reproduce. Probably fixed in the last few months.

[linev]

Issue is still there. Just do:

wget  https://root-forum.cern.ch/uploads/short-url/vue07kduqCLe9dhZ3MGW8pLWja0.root 
root vue07kduqCLe9dhZ3MGW8pLWja0.root 

[ferdymercury]

Related discussion: https://root-forum.cern.ch/t/how-to-save-std-unique-ptr-into-ttree/63859

Note: this is incorrectly marked as Fixed in 6.34 project.

[pcanal]

@ferdymercury Isn't the problem left that the error message is 'confusing'? Storing:

class A {
   std::unique_ptr<int> values;
};

is not supported as it is assumed to be a pointer to an array and the length is not specified. On the other hand:

class A {
    int NumberOfValues;
    std::unique_ptr<int> values; //[NumberOfValues]
};

should work fine.

In first approximation the above example should work 'exactly' the same whether the type of values is std::unique_ptr<int> or int*.

[ferdymercury]

Hm... shouldn't it be [1] by default if nothing is specified? Most times, that's what a unique_ptr is used for. And the number of elements is 1 or higher, never zero, right?

[pcanal]

a long long time ago, it was decided that if a user wanted to store a single int, they would be better off storing it directly rather than having a pointer to a single int, so that a pointer to an int only made sense for 2 or more values and thus not having the size was an error. (I suppose this left the case of an optional int to have to go through an std::vector instead of a pointer).