Well, now I have time to continue our conversation :)
Greg, first I want to say I like code that your write. You are good
computer programmer and
I don't try to cast doubt on your professional skill. But I think
everyone can choose his own way
and your prejudice (rational in many respects) against features of C++
should not influence onto others.

2013/7/13 Greg Ercolano <erco_mlist@seriss.com>:
>
>         I wanted to use it, and for several years was happy enough
>         making my code longer using cout instead of printf/fprintf,
>         because mainly I knew my cout code was 'safe' from bugs like this:
>
>                 int x=1, y=2;
>                 printf("two strings: %s %s\n",x,y);     // BAD

Not only. Do you like to write explicit instruction which type of
variable you are going to print (%s,%n,%c...)? It's not necessary in
C++.

>
>         Just a simple example:
>
>                 printf("%-20s: %12.12s\n", key, value);
>
>         ..vs:
>
>                 std::cout << std::setiosflags(std::ios::right) << std::setw(20) << key
>                           << ": " << std::resetiosflags(std::ios::left) << std::setw(20) ..etc..
>

Yes, I agree with you, the complex formatting of output is complicate
thing when we use iostream. But in my first post I spoke about simpler
printing (80-90% of output in apps). Yes, printf() is shorter, but is
it more readable? I'd rather say it's ugly! I think the second variant
(without unnecessary 'std') can be clearer than mess of % symbols:)
And boost (you said about it below) gives us the shorter way to
manipulate with output data.

>
> h = CreateFile(filename,        // filename
>                GENERIC_READ,    // access
>                FILE_SHARE_READ, // share
>                NULL,            // security
>                NULL,            // create mode
>                NULL,            // attribs
>                NULL);           // template
>
>         ..vs the much simpler, easier to remember/read:
>
> fp = fopen(filename, "r");

next step...
fp = ifstream(filename);
:)

>         I also don't like the idea that I need something like boost
>         just to fill in all the gaps of STL. Why wasn't STL conceived fully
>         in the first place?

One can think boost is pre-STL features. A lot of modern STL parts was
taken from boost.

>         I hope boost app coding is cleaner than STL.

Partly... Boost improves STL (and C++ too)

>> strs.erase(strs.begin() + n); // memory leak!
>
>         My point is that to remove items from a vector is a bit convoluted;
>         you can't just remove the nth item without using iterators, and I
>         think that's too bad you can't also just specify a simple integer.

I think, the root of our claims to STL is other point of view. STL's
main conception of containers is sequence.It's more common idea than
array(list, map and so on). It allows to create generic algorithms for
any programming structures of data. Of course, there is a price to be
paid for the common idea. But STL is one of programming standarts and
now its API is quite usual thing.

>
>         Regarding the memory leak comment, that's only true if one assumes
>         the memory of the string is not being managed elsewhere.
>
>         For instance, it's not leak if it's a vector<> copy of an argv[] array,
>         or a vector array of pointers to different words in a char[] array.
>
>         Granted it's probably better to work with arrays of strings
>         instead of chars.. for safety that's true. But sometimes you can
>         make more efficient code by managing string memory yourself and
>         using pointers.

Again, at the moment one can use shared_ptr to make efficient and safe
code. To avoid cyclic references you can use weak_ptr. Example:

    typedef shared_ptr<string> string_ptr;
    typedef weak_ptr<string> string_wptr;

    vector<string_ptr> v;
    v.push_back(make_shared<string>("one"));
    v.push_back(make_shared<string>("two"));
    v.push_back(make_shared<string>("three"));

    vector<string_wptr> vw(v.begin(), v.end()); // array of weak
pointers, e.g. log of used strings

    v.erase(v.begin() + 1);// delete the string "two"

    for_each(vw.begin(), vw.end(), [&] (string_wptr& next)
    {
        string_ptr s = next.lock();
        if (s)
            cout << "link to " << s->c_str() << endl;
        else
            cout << "expired" << endl; // this will be printed instead
of string "two"
    });


>         ..right, but this starts you on a path of redefining the
>         base language, which affects code readability.
>
>         Honestly I'd rather read code and see a lot of v.push_back(xyz)
>         instead of calls to custom method wrappers like v.add(xyz),
>         just so that at least I know when I read it there's no other
>         code implications.

Agree, that was only an example for the old grumbler ;)

>
>         Yes, and I agree -- you can get used to it.
>
>         But I do try to avoid the more esoteric features of the language
>         unless they really provide a benefit.

Do you really see no benefit? I have created several new objects and I
have no head ache about releasing them when it need to be done and
only once. They live while I use at least one of pointers and they die
in the moment I delete/reset/reassign last pointer.

-- 
Nikita Egorov

-- 
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.