Am 22.06.2013 08:46, schrieb Olaf Radicke:

Tommi Mäkitalo <[email protected]> hat am 21. Juni 2013 um 19:00 geschrieben:
The next step for the new homepage is to integrate API documentation.
And after that we have to go through the classes and see, where proper
documentation is missing.
Now I generate the API documentation with doxygen self and I be little
bit surprised. In this generate API documentation it is to find the
function split() and join()! And I be surprised too: It is very fine
documentated!

I think namespace is a wonderful thing to give that a right ordering.
If you dont like class member we can use a namespace. For suggestion:

namspace cxxtools{
     namspace string{
         [...]
     }
}
cxxtools::string::split()
cxxtools::string::join()
cxxtools::string::convert<>()

But, a class name is not big difference do a namspace. Ultimately a
class name is a namspace. Anyway...
A class is something you want to instantiate. A namespace is just a namespace. It is a big difference.

Moving the methods to a namespace "string" indicates, that they are string stuff. But indeed they are not. Ok split is more or less limited to strings but join is not. You can well write:

   std::vector<int> numbers = something();
   join(numbers.begin(), numbers.end(), " / ", std::cout);

It has nothing to do with std::string now. Thats the idea behind algorithms in the standard library as well. They are quite versatile and not limited to one specific use case.

"convert" is the same thing. It acts like a generic conversion tool. It should not be limited to strings but. At the same time it just became limited use with C++11. There is a std::to_string(number) in C++11.

But at the same time I feel, that it is overused. Often you think you need a string from a number but actually you don't. Maybe you want to convert a C++ structure to json and in json you have a string representation of your number. If you use cxxtools::JsonSerializer you have nothing to do with number to string conversion. Or you want to inform the user about a number of something. The message has a number inside. Actually you want to output the number but do not really need to have that string. In the most simple case you just output it to std::cout. Or in tntnet/ecpp you just use the <$...$> tags.



Transform is a free function. It is not a member of anything.
Yes you are right. std::transform is not a member of string or member of
this namespace. I was wrong.

Okay, let's have a look at other frameworks. Qt is a good example. Specialy
the QString class: qt-project.org/doc/qt-5.0/qtcore/qstring.html

The class is clear an intuitively to use. That's what programmers love. And
of
course, the doku is fine too!
String handling with standard C++ is just a little different. It is not
as people expect but different. Maybe something like a cookbook how to
handle strings in C++ correctly may help. String handling is really not
that bad and everything can be done. The only problem is, that the
algorithms are not member functions of std::string and hence can't be
found there.
We can create a proxy class to embedded this in the cxxtols/tntnet
framework. So programm can find his tool easier.
There are so many string classes out there that I don't want to duplicate the effort. The std::string is just fine. I added some helper functions in cxxtools for common problems.

Just wrapping stuff again and again do not make code more readable. People should learn how to use the standard stuff. People who are familiar with the C++ standard will have less problems reading your code, if you use the standard stuff wherever possible. The standard is not perfect but it is mostly good enough. And extending std::string by adding algorithms is easy just because it do not have member functions for all stuff.

Lets take an example. Lets assume we have a string class MyString with a member tolower. You can then write something like:
MyString foo = "FOO BAR";
MyString bar = foo.tolower();  // becomes "foo bar"

For a special case you need a method for camel case. If you have a ready to go MyString, you can't just add a member camelcase. You can extend the string class by deriving from it. We have a CCString. Then you can write:
CCString foo = "FOO BAR";
CCString bar = foo.camelcase();  // becomes "FooBar"

But someone else wants to add different extension he have to derive his own class. You end up in a tree of different string classes. Maybe even in the same project.

Better is to keep stuff outside in the first place. Then you can easily implement algorithms at your own will.

And that is the idea behind std::string.

You may not find it intuitive and feel, that QString is more intuitive. But what about people, who are used to std::string and have never heard about QString. They will feel just more comfortable with std::string. So just go with the standard and most people will understand your code.

Qt created a string class because standard C++ did not have any those
days. std::string is newer than QString.
i think the goal of a framework is too make it easy for programmer
to do what they want. So wrapper classes is a good way to make using a
little bit more intuitive.


Typically web programming has many string operations so the string handling
is very impotent, I think.
I don't see may string operations in web programming. Can you give me
some examples, where you really need string operations in web programming?
You have a number an like embedded this in a message sting (you need a cast).
You get a list separated by commas as a string input. In my program the user
can give a bible verse some tags. And ths tags don't like upper letters. You
can see more hier http://www.the-independent-friend.de:8008/
As told above. You don't need to embed your number in a message string but have to output a message with a number. Hence you should consider just outputting the number instead of converting it to string first.

And there is cxxtools::split for splitting and tolower to convert to lower case. So you have everything you need.

Tommi
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Tntnet-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tntnet-general

Reply via email to