Why doesn't FLTK take c++ strings?

[David Topham]

Probably this has been asked before but I couldn't find the thread searching...

Although I know we can always add c_str(), I am curious why FLTK functions do not take c++ string objects?

As far as I know, we can't use FLTK directly from C anyway, so all users are using C++, right?

Maybe just too big a job to add overloaded functions to support that?

I know using c++11 compiler option, we can finally use ifstream with c++ strings!

i.e.

string s = "file"; ifstream ifs(s);

whereas for c++98, we needed:

string s = "file"; ifstream ifs(s.c_str());

[Nikita]

Hi,

05.12.2016 23:05, David Topham wrote:
> Probably this has been asked before but I couldn't find the thread
> searching...
>
>
> Although I know we can always add c_str(), I am curious why FLTK
> functions do not take c++ string objects?
>
> As far as I know, we can't use FLTK directly from C anyway, so all
> users are using C++, right?

Well, I believe it is a not very good idea to use in API of the library
some classes of *other* libraries (though they are widely used). Some
troubles can happen, because, eg, FLTK and user application can be
compiled with different versions of STL.

You can add a few simple definitions into your header file and forget
about this problem. For example:

template <typename T> void value(T* wdg, const std::string& s) {
wdg->value(s.c_str());
}

template <typename T> void value(T* wdg, const char* s) {
wdg->value(s);
}

Any invoking of "value(widget, str);" will be handled correctly.

Nikita Egorov

[Greg Ercolano]

On 12/05/16 12:05, David Topham wrote:
> Probably this has been asked before but I couldn't find the thread searching...
> Although I know we can always add c_str(), I am curious why FLTK
> functions do not take c++ string objects?

Mainly to prevent fltk from having a dependency on stl.

This allows fltk to be built and run on systems like embedded hardware
that have minimal compilers that can handle c++, but /can't/ handle
advanced templates that stl needs.

Which is why fltk continues to use C strings instead of
std::string or std::<anything> internally.

This way fltk can have a consistent API across all platforms.

While we /could/ add optional convenience methods to fltk
that accept and return std::string definitions, this would
just hide the fact that fltk is still using C strings internally.

Better to expose the library's internal data to expose the most
efficient data path possible, rather than try to hide it with
convenience methods. This way the app can choose the most efficient
techniques for moving data possible, to avoid efficiency issues later.

[David Topham]

Thanks Greg for the info, that makes sense--fast, LIGHT, toolkit! ...and thanks Nikita for the nice template idea too!

--
You received this message because you are subscribed to a topic in the Google Groups "fltk.general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fltkgeneral/NUBUs6DRFp8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Roman]

You can also define your own srting class with a conversion operator like:

class My_String: public std::string {
  operator const char *() const {return c_str();}
  ...
};

Now you  can use your class directly for all functions which accept const char * (and of course std:;string too)

  My_String str("Hello, world!");
  widget->label(str);

However str must exist as long as particular widget is used and MUST NOT be modified (otherwise internal c_str pointer might change). If not, do something like:

  widget->copy_label(str);

R.