Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-09-12 02:37:23

Robert Ramey wrote:
>>>>>>3) Additions to documentation to include rationale for not depending
>>>>>>on type_id
>>>>>I'm afraid I'm not convinced by either the rationale or your posts.
>>>>>For that reason plan to argue and vote against the inclusion of your
>>>>>library in the current state.
>>>I'm not sure which posts or rationale you are unconvinced by. I can say
>>>I tried to address all points raised only after careful study and consideration
>>>and I am convinced that they have been addressed in the best way. My
>>>reasons for the decisions made have been documented in posts and the
>>>rationale. In the absence of new facts or observations, I see no reason to
>>>make any more changes.
>>I have tried hard to explain that while typeid would make archives
>>unportable between different machines (not really an issue if there's
>>denamgler for type_info::name() and I think work is underway on it),
>>your scheme make archives possibly unsusable between different
>>applications on the same platform and even inside the same application.
> You've made this assertion before but I found no basis for it. I asked for
> a example which illustrates your contention that the current
> "sequence based registration" is non-portable but none was ever forthcoming.

I think I've tried to explained that in
Did you missed that message or I missed your reply?

>>You've merely dismissed my concerns.
> Not at all true, I have carefully considered them and in some cases made alterations
> to take them into account. In response to your observations and example about diamond
> inheritance, I made valuable improvements in the library that eliminate redundancy in
> such situations. Your observations convinced me to but register_type back in. These
> things made the library better would not have happened without your input and my
> considered response to it. The fact that we have to disagree on some issues
> is not because I am dimissing your concerns. On this final issues, your arguments
> have failed to convince me.

I realize that you've listening to comments and did not mean to say that
you dismissed *all* concerns --- you indeed support diamond inheritance
now, for example. The use case in the message I refer seems still
unaddressed, though.

>>>>>In addition, there was *no* real discussion on interface. I still
>>>>>would like to use 'describe', which may work in 95% of cases. I also
>>>>>have some other minor disagreements. I'm afraid we won't be able to
>>>>>come to a decision over formal review period.
>>>There was quite a bit of discussion on the interface - particularly regarding
>>>the describe functionality. I had nothing against it in priniciple, its just
>>>that in practice it didn't really add anything.
>>1. It's much more terse
>>2. It can be used for other purposes.
>>3. Finally, you can 'describe' your class without even including
>>serialization headers, which is handy if somebody want to use your
>>classes without any serialization.
> This was discussed in detail. To summarize,
> 1. load and save are generally not symetric

'describe' can handle 95% of cases. It's okay to use separate load/save
for the remaining 5%.

> 2. describe left no place for const - a key point in correctness and eliminating
> redundance in diamond inhertitance situations.

There's a proposed solution in another message (by Michel André), and
it's not disproved yet.

> 3. did not address base class serialization.

Not sure. You don't have to grab current scheme as is. Something like


might work.

> 4. it wasn't clear how this would be applied to serialization of templates

No comment here -- don't see problems yet.

> If I may sumarize, I would say your objections boil down to
> 1. It is possible to add a useful "describe" facility and that such a facility is necessary
> 2. "sequential registration" doesn't work in the general case.
> I have made my best arguements that both of these propositions are unfounded. These
> arguments are documented in posts and the rationale. I am very disappointed that I have
> been unable to convince you, as I do respect your opinion, but I don't know what else to add.
> I do believe that anyone who investigates these issues to the depth that I have (i.e. implementing
> real code) would agree with me on these points.

Okay. We both retain our opinions.

- Volodya

Boost list run by bdawes at, gregod at, cpdaniel at, john at