Skip to content

Limitations of cxxopts in F3D #434

@mwestphal

Description

@mwestphal

F3D uses cxxopts for parsing options, however there is some limitations that negativela impacts F3D, it has to do with how cxxopts handles vectors.

F3D is using actual value of the option as default value, parsing it to a string before providing this string to cxxopts as a "default value".

The main issue is that an empty string is not parsed as an empty vector by cxxopts. It forces F3D to provide default value to some options when they should not have any.

A secondary issue is that the value stored in the vector is not replaced by cxxopts but pushed back into it, which means that before parsing, the value needs to be reseted.

The way we use cxxopts and these two cxxopts limitations forces us to define "default values" for values that should not have any (--camera-* and --range). Not a very big deal as this can be handled internally however they do appear when using --help which is not great.

That being said, this is not a critical issue, I'm opening this as a documentation of the current behavior if we ever want to fix it.

A few possible fixes are:

  1. Convince upstream / fork so that vector are handled differently and parsing an empty string for a vector is supported. The current implementation actually make sense and simplify many things in cxxopts code, so fork may be needed.

  2. Rework complettely our option system to stored default value in string from somewhere else. This is possible however it means that libf3d option default and these new string defautl will be duplicated/synchronised

  3. Use another option parsing lib

1. is of course the simplest but 3. may be what is needed in the long run.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    Done

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions