Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-08 02:42:50

Bertolt Mildner wrote:

>>So, the position of tab basically sets a indent level for the remaining
>>lines in the paragraph. Now I understand this. However, I don't like the
>>"last tab takes effect" rule. What if that last tab is on the third line
> of
>>the paragraph? Maybe, it's clearer (in code and in docs) to allow only one
>>tab in a paragraph and throw otherwise? Or do you have a use case for
>>multiple tabs?
> OK, to throw on multiple tabs makes perfect sens. (Any hint on what
> exception class is suitable?)

I think program_options::error would work.

> I also see the problem when the tab happens to be not on the first line.
> The problem is that in cases where line_length is queried from the console
> this may always happen, just set your console to 10 char long lines ->
> peng.
> It's the same problem with (first_column_width >= line_length)!
> I would prefere to *not* throw in this situations, but only assert on
> them. I think it would be much better to leave a user with an
> ill-formatted option description than with only an error msg.

Asserting on run-time condition does not seems reasonable to me ;-)
Maybe, the right solution is to silently ignore tabs which are not on the
first line of a paragraph?

> And probably set the pragraph indent to something like "tab_pos %
> (line_length - indent)" to prevent problems in the fromat code. The
> formatting is smashed anyway ...

Yes, formatting is smashed anyway, so ignoring the tabs on the seconds line
is a viable option.

- Volodya

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