DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2645
Version: 1.3.0


Hello,

the unexported ctor/dtor issue is still there for the Fl_Hold_Browser
class after the fix that have been provided for other classes.

By the way, i think the fix provided to STR 2632 makes the code less
maintainable as it duplucates the implementatin of constuctors.

Why not to go for a all time (DLL or not DLL) .cxx implementation,
possibly adding the inline keyword that would make it the same generated
code : example for Fl_Multiline_Output :

in .H :

class FL_EXPORT Fl_Multiline_Output : public Fl_Output {
public:

  /**
    Creates a new Fl_Multiline_Output widget using the given position,
    size, and label string. The default boxtype is FL_DOWN_BOX.

    Inherited destructor destroys the widget and any value associated with
it.
  */
  inline Fl_Multiline_Output(int X,int Y,int W,int H,const char *l = 0);
};

in some .cxx (like Fl_Input.cxx as is is in the svn fix) :
(outside of any #ifdef FL_FLL block)

inline Fl_Output::Fl_Output(int X,int Y,int W,int H, const char *l)
    : Fl_Input(X, Y, W, H, l) {
  type(FL_NORMAL_OUTPUT);
}

if some target compilers do not support the inline keyword, it is possible
to replace it with a #define FL_INLINE inline or empty according to the
target compiler to keep only one version of the source code. 

regards,

Mathieu


Link: http://www.fltk.org/str.php?L2645
Version: 1.3.0

_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Reply via email to