Why Iostreams [and all std::] are so obsolet.

[HarD Gamer]

I think that is time for a standard library revision. And I ask: Why in each new version the older parts don't evolve?

[D. B.]

C++ thankfully does not follow the boneheaded doctrine that everything must be an object, like whatever language you wish C++ was instead, so class Main is not going to happen.

"And I ask: Why in each new version the older parts don't evolve?"

There's a thing called backwards compatibility, which although you clearly don't care about - many, many other users do, as do the Committee. I'd've thought that had been explained when you made such suggestions before.

Having said that, there are ideas about a new stdlib floating around, and I'm sure changes to iostreams are among them. Have you investigated those?

[HarD Gamer]

class Main is my code, my question is on the comments. I saw "Standardy Library" and not "Core Language"

----------------

[HarD Gamer]

And i go further, A good solution for older codes is stdN:: that already is posted here. And, I think that modules can solve that too.

ex::

import std.stl.Vector; //  current standard in 2020

=====================

import std2.vector // std C++14/11.... 

[Patrice Roy]

It might be interesting if you explained in what way the verbose code suggested in that example would be better than what exists, if only to orient debate towards the ideas you are trying to convey.

I doubt most C++ programmers would see this kind of code as an improvement over the current situation. I know I don't, but maybe I don't understand what you have in mind.

2016-10-17 18:10 GMT-04:00 HarD Gamer <rodrigo...@gmail.com>:

I think that is time for a standard library revision. And I ask: Why in each new version the older parts don't evolve?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a21834c5-8870-42a9-9187-487b2dd8e1bd%40isocpp.org.

[HarD Gamer]

Patricy,

 Do you like write casts all times that need write strings in high level code? or binary files?

Do you like error codes or exceptions that simplify error conditions? (...)

[Patrice Roy]

Please answer the question; if there's no problem you can identify clearly, then this might not be the right forum for you. It's Ok, there are many other discussion spaces out there.

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/040d6874-1da5-426f-9b31-5360b8d5c769%40isocpp.org.

[HarD Gamer]

My questions are the aswers.

===============

Patricy, 

[Nicol Bolas]

On Monday, October 17, 2016 at 6:10:16 PM UTC-4, HarD Gamer wrote:

I think that is time for a standard library revision. And I ask: Why in each new version the older parts don't evolve?

They do evolve. What they do not do is:

1: Radically change themselves with every version of the language. Backwards compatibility is not something we break lightly. Or pretty much at all without fair warning.

2: Use different naming conventions because a guy on a forum prefers InterCaps to under_scores.

If you would like to put forth a coherent proposal for some aspect of the standard library to change, feel free. But all you've done in this thread is make vague claims about the standard library not evolving in the direction you prefer. That's hardly constructive.

Before you do so however, you might want to consider that it's unlikely that people will find "change the naming convention of everything to Java-style" to be a useful starting point.

[Nicol Bolas]

On Monday, October 17, 2016 at 7:25:28 PM UTC-4, HarD Gamer wrote:

Do you like write casts all times that need write strings in high level code?

No, but fortunately, C++ requires no such thing. I don't recall needed to do much casting when working with `std::string`.

Perhaps you could give an example of the problem you are referring to.
 

or binary files?

... huh?

Do you like error codes or exceptions that simplify error conditions? (...)

That really depends on who you ask. And what code you're talking about. And what the purpose of that code is.

Error codes are a perfectly valid means of communicating failure conditions. So are exceptions. Each is appropriate in its own domain. But we should never believe that one is so superior to the other that the other never ought to be used.

Personally, I'm in favor of always giving the user a choice about such things.

[Ren Industries]

Why is StringList not const? That's the real question here.

Also, what is StringList? Never seen that in C++ before.

Wouldn't it be std::forward_list<std::string>?
Or maybe forward_list<string>?

Hell, I'd settle for even list<string>; why have a hard coded type for StringList when you could have a generic type that can be used over and over, like our current std::list?

It also looks like you are iterating over the StringList to get each string as an item; sure.

But why do you then need to pass the length of the item (a string) to cout?

Why can't cout interpolate with a string enough to know the "length" automatically?

What happens when string is passed to a different kind of out? Does it need to pass the length every time?

Why don't we have an idiom to make this easier and reduce effort?

Seems like the current C++11 standard is better in this regard:

int main(int argc, char* argv[]) {

    std::vector<std::string> arguments(argv, argv + argc);

    for(auto&& item : arguments) {

        std::cout << item << '\n';

    }

}

Look, mine is even smaller!

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/82f33d33-bb86-4230-867f-fdb73fc17bc9%40isocpp.org.

[szollos...@gmail.com]

Hi,

Error codes are a perfectly valid means of communicating failure conditions. So are exceptions. Each is appropriate in its own domain. But we should never believe that one is so superior to the other that the other never ought to be used.

Personally, I'm in favor of always giving the user a choice about such things.

.. and jftr, in C++11 you can just do that by accepting an 'error lambda' in your function:

template<typename OnError>
int parseInt(const std::string& s, OnError error)
{
    int ret = 0;
    for (char c : s) {
        if (!is_digit(c)) return error(ret);
        ret *= 10; ret += c;
    }
    return ret;
}

int main()
{
    std::string s("123a");
    std::cout << parseInt(s, [](int)   { throw ParseException(); } );
    std::cout << parseInt(s, [](int i) { return  i; } );
    std::cout << parseInt(s, [](int i) { return -1; } );
}

Thanks,
-lorro

[José Rodrigo]

Nicol Bolas, I'm not talking about naming conventions. I'm talking about "why is the standardy library obsolete?"

Bjarme says us to use the std:: massively, but we can't do it.

[HarD Gamer]

Ren Industries,

consider: int main(int argc, char *argv[])

Is argv const? Or * * const?

[D. B.]

What are you talking about? Why is it "obsolete"? Who is "Bjarme" and why can we not '"use the std:: massively"? As Patrice said, you haven't actually described a problem or introduced a solution, so there is no proposal here, and so this is the wrong place to publish your half-formed opinions and have irrelevant back-and-forth quips with other users. Start a blog or something.

[HarD Gamer]

Ren Industries,

Can you work with your example with binary files? I think you don't 

 

[HarD Gamer]

https://pt.wikipedia.org/wiki/Bjarne_Stroustrup Bjarne*,

obsolete is older, no 
robust, no uniform....

=============

[D. B.]

"Obsolete" means it's outdated to the point of being risky to use. That does not describe the stdlib. You not personally liking its naming conventions, or a lack of uniformity among them, does not make it "obsolete".

I also fail to find anywhere that you have described how it the stdlib is not "robust", by any usual definition of that word. I think the programmers who maintain the various implementations of the stdlib would appreciate being informed if somehow their products are not robust, really. Again, lack of uniformity or propensity for verbosity do not make something non-robust.

Even if this weren't all just based on your opinions, you are not providing any actual thesis for why and how it should be changed. A series of expositions on things you don't like and very vague riddles posed to other users do not constitute a proposal.

[José Rodrigo]

As I said, I'm not talking naming convetins; The std:: is  obsolete, what is  < c++11 is 

untouched. I think in a std:: like the Qt library: Each part works fine with alll stuffs, Each part supports any other, It doesn't have incomplete classes, types, modules..., and so on. It the Qt library Guidline be applied to std::, It won't be robust.

P.S.:

Qt guidlines, but with:

exceptions,

size_t for indexing strings, streams, ...)

without moc.

[And again, I'm not talking about naming conventions.]

[Patrice Roy]

José,

I find your train of thought very difficult to fathom. I might not be bright enough to understand what you are trying to convey.

I will suggest, once again, that if you want to submit a proposal here, you take the time to write it throroughly, explain your proposal, ensure it's clear enough to people you normally read in English, and only then post it. Remember that there are other locations to express yourself if you don't like something for personal reasons and want to vent. This forum is not such a place.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJe%2Baq_s4dLyGZE9uT2Vqct%2Be1Temy%3DNupR8Ox-0awNRXeeS%3DQ%40mail.gmail.com.

[Ren Industries]

Neither, as argv isn't const; the contents of that array may be modified by the program.

Not sure what that has to do with your contrived example though, and it doesn't answer literally any of the other questions I asked.

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/65ad37f5-f499-470a-a3f4-954d48cacc03%40isocpp.org.

[Ren Industries]

Neither my example nor yours included any instance of "files". 

cout is a stream.

On Wed, Oct 19, 2016 at 5:02 PM, HarD Gamer <rodrigo...@gmail.com> wrote:

Ren Industries,

Can you work with your example with binary files? I think you don't 

 

--

You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a6128ffd-433e-4535-a876-5c8cef7aa1ce%40isocpp.org.

[HarD Gamer]

Sorry, args is not const because I need to modify It in my Main::main() application.

Em quarta-feira, 19 de outubro de 2016 21:19:57 UTC-2, Ren Industries escreveu:

Neither, as argv isn't const; the contents of that array may be modified by the program.

Not sure what that has to do with your contrived example though, and it doesn't answer literally any of the other questions I asked.

On Wed, Oct 19, 2016 at 4:59 PM, HarD Gamer <rodrigo...@gmail.com> wrote:

Ren Industries,

consider: int main(int argc, char *argv[])

Is argv const? Or * * const?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

[HarD Gamer]

I said "files" because fstreams inherit streams

Em quarta-feira, 19 de outubro de 2016 21:20:38 UTC-2, Ren Industries escreveu:

Neither my example nor yours included any instance of "files". 

cout is a stream.

On Wed, Oct 19, 2016 at 5:02 PM, HarD Gamer <rodrigo...@gmail.com> wrote:

Ren Industries,

Can you work with your example with binary files? I think you don't 

 

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

[Nicol Bolas]

On Wednesday, October 19, 2016 at 5:02:42 PM UTC-4, HarD Gamer wrote:

Ren Industries,

Can you work with your example with binary files? I think you don't 

 

"Work" in what sense?

Yes, you can use any output fstream, even one opened with `ios::binary`, with that code. It will do exactly what it says it does: write the characters of a string with no text-to-binary translation, followed by a `\n` character with no text-to-binary translation.

Does that satisfy your definition of "work"? Or are you trying to serialize objects, which is a very different, and far more complex, operation?

[Ren Industries]

fstream is a kind of stream, sure. But we are dealing with cout. Which is not an fstream, but an ostream.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6a44c30e-c7ef-422d-a158-caf9ea0c76d6%40isocpp.org.