www.digitalmars.com         C & C++   DMDScript  

D - I was looking for an answer, but ...

reply David B <trblshooter hotmail.com> writes:
(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.
Jul 17 2012
next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
I don't mean to be hostile, but that post is almost worthless. No 
one can extract whatever it is you're trying to say or ask 
without spending 15 minutes deciphering it, and no one will.
Jul 17 2012
prev sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
Also you managed to post in the wrong group. I award you no 
points, and may God have mercy on your soul.
Jul 18 2012