I was looking for an answer, but ...

July 18, 2012
Posted by David B
Permalink
David B
Permalink
(Sorry this is so long - but my frustration hasn't been this high since I
retired 5 years ago.)

I was looking for something to use as an alternative to C++. I found D. Looks good.

Even has C library use to fall back on when D has a buggy feature or is
lacking something.
Strings, arrays - perfect. Little need for pointers everywhere: just what I
was running from.

Or so it is advertised.

How to learn? Everyone has 'hello world' sample. Many have a not-hard-to-find file open, test, write, close, etc. samples.

Then - I am no different from anyone else - I try a few test code pieces for
that Next Big Program.
A little proof of concept at the console. But, Wait! Just a little character
i/o, please. A 'y/n' query.

That's a problem. It seems the decision was made that D would not honor the Linux/Unix world view of any device as a stream object. And, heck, no one uses a console anymore, so we will not cover that topic. At least, repeatedly - the best advice is - RTFM and try this, try that, oh - but that deals with line termination, that will be gone next version. That is deprecated. That will be removed next version. That was in D1, but removed already. Come on!

Oh, and, today-yes, tomorrow-no - include the wrapper for getc(), etc. from
the C libraries.

I have been searching for 2 weeks for reasonable and simple code that can do this.
You do strings (Heavens to BASIC!) You do easy/lazy type conversions (as do
many not-serious languages.) But not console i/o.

David

(since I am retired - only: 1 Ubu server; 5 Ubu workstations; 1 Fedora; 4
Window.x systems at home)
-------------------------------------
re: din

std.cstream:

/**
* $(RED Warning: This module is considered out-dated and not up to Phobos'
* current standards. It will remain until we have a suitable replacement,
* but be aware that it will not remain long term.)
--------------------------------------------------
--------------------------------------------------
I have looked at literally hundreds of conversations regarding the design decisions for D. Generally, I like the attitude. Just, don't get lazy. It is supposed to be easier and 'fix' C and C++. You already have split libraries and methods for *nix and *doze.

Is this too hard to fix? Do I need to keep looking and pick another language? (Where is Commercial BASIC when you need it? Oh, yeah.  M$ eventually got their way and Digital Research is no more. THAT'S how long I've been around.)

=========================================
THIS MAKES SENSE:

I have to say, I'm with Steve on this one.  While I do believe ranges will have a very important role to play in D's future I/O paradigm, I also think there needs to be a layer beneath the ranges that more directly maps to OS primitives.  And as D is a systems programming language, that layer needs to be publicly available.  (Note that this is how std.stdio works now, more or less.)

-------------------------------------------- D is a general purpose systems
and applications programming language
How can you do systems without fast single byte primitives?


re:

http://www.digitalmars.com/d/archives/digitalmars/D/deprecating_std.stream_std.cstream_std.socketstream_167187.html

"Why would anybody want to read a large binary file _one byte at a time_?

Stewart.

May 16 2012 "

proprietary packing schemes - this is a must for many.

And if I can't write a file that no one else can read (without the appropriate sweat involved), then why would I chose your language to write secure files?

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

Walter:
"Since it's not range based, probably not."

mine: So... decision previously made ... MUST be range based. Then, this language is finished?

Andrei: May 16, 2012 at 12:48:49PM -0500

"... In other words, ranges aren't enough..."

 This is copiously clear to me, but the way I like to think about it
 is by extending the notion of range (with notions such as e.g.
 BufferedRange, LookaheadRange, and such) instead of developing an
 abstraction independent from ranges and then working on stitching
 that with ranges.
-------------------------------------- BAD IDEA above
In a previous life, my job was to fix things. The hardest to fix were where the problem had bandage after bandage after bandage, and no one would get off of a past poor decision. 'Like to think about it' is interesting, but isn't going to improve anything.
--------------------------------------
So to tie it all nicely I think we need:

1. A STRICTLY UNBUFFERED streaming abstraction

2. A notion of range that supports unbuffered transfers.


No, Andrei, this only means that some decision that range is the only way to go is not to be tampered with.
Forums
