Georg Baum wrote:
> The code depends now a bit more on the fact that we have at least one
> row, one column and one cell, because we use "row - 1", "column - 1" and
> "cell -1" at several places, and the result must be positive, but I think
> this is no problem.
You could reasonably define a LyXTabular::npos, no?
> Please have a look at the FIXMEs.
Agree:
+mynewidxtype
LyXTabular::getCellNumber(mynewrowtype row, mynewcoltype column) const
{
- BOOST_ASSERT(column >= 0 || column < columns_ ||
- row >= 0 || row < rows_);
+ // FIXME: was BOOST_ASSERT(column >= 0 || column < columns_ ||
+ // row >= 0 || row < rows_);
+ // I guess it should be && and not ||!
+ BOOST_ASSERT(column < columns_ && row < rows_);
return cell_info[row][column].cellno;
}
Leave the ASSERT for now. Usage will tell whether there is a logic problem:
-int LyXTabular::TeXTopHLine(ostream & os, int row) const
+int LyXTabular::TeXTopHLine(ostream & os, mynewrowtype row) const
{
- BOOST_ASSERT(row >= 0);
+ // FIXME: assert or return 0 as in TeXBottomHLine()?
BOOST_ASSERT(row < rows_);
I suspect a fudge. Does row < 0 mean something 'special'?3
-int LyXTabular::TeXBottomHLine(ostream & os, int row) const
+int LyXTabular::TeXBottomHLine(ostream & os, mynewrowtype row) const
{
- if (row < 0 || row >= rows_)
+ // FIXME: return 0 or assert as in TeXTopHLine()?
+ if (row >= rows_)
return 0;
--
Angus
