January 15, 2013
On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote:
> mist:
>
>> I am most unpleasant with vertical space point. Times when screen space was that important are long gone - I generally can understand less at once than can possibly fit with 9th font size on 24 inch screen.
>
> I prefer a larger font and less wasted lines.
> The very very airy style of C# coding worsens my code understanding.
>
>
>> And extra vertical spaces are like semantic formatting tools for plain text - can group related blocks perfectly and speed up reading.
>
> The idea of not wasting lines doesn't go against the idea of adding blank lines to create code paragraphs. When you are adding a line to divide chunks, you are not wasting vertical space, it's a well used line :-)
>

I could explain it better.

Plus, in some languages, (yes javascript, I'm looking at you) semicolon are inserted in places that can create very nasty bugs when changing line like that. I know it isn't really an argument that apply for C/C++/D but it does matter for a programmer that use both C/C++/D and such a language (as I do).
January 15, 2013
On Tuesday, 15 January 2013 at 04:45:02 UTC, deadalnix wrote:
> On Monday, 14 January 2013 at 23:48:14 UTC, bearophile wrote:
>> mist:
>>
>>> I am most unpleasant with vertical space point. Times when screen space was that important are long gone - I generally can understand less at once than can possibly fit with 9th font size on 24 inch screen.
>>
>> I prefer a larger font and less wasted lines.
>> The very very airy style of C# coding worsens my code understanding.
>>
>>
>>> And extra vertical spaces are like semantic formatting tools for plain text - can group related blocks perfectly and speed up reading.
>>
>> The idea of not wasting lines doesn't go against the idea of adding blank lines to create code paragraphs. When you are adding a line to divide chunks, you are not wasting vertical space, it's a well used line :-)
>>
>
> I could explain it better.
>

s/could/couldn't/

> Plus, in some languages, (yes javascript, I'm looking at you) semicolon are inserted in places that can create very nasty bugs when changing line like that. I know it isn't really an argument that apply for C/C++/D but it does matter for a programmer that use both C/C++/D and such a language (as I do).

January 15, 2013
Am 15.01.2013 01:55, schrieb Stewart Gordon:
> vec.erase(std::remove(vec.begin(), vec.end(), val), vec.end());
>
> Gee, that's going to be typed correctly by every programmer every time!"
>
> It seems that even the writer of that piece hasn't typed it correctly -
> from what I can make out, that code would remove everything _except_ val
> from vec.  Either that or it wouldn't work at all, since the vector
> returned by remove is no longer a plain vector iterator.

That piece of code is correct.
http://en.wikipedia.org/wiki/Erase-remove_idiom
January 15, 2013
On 2013-01-14 21:57, monarch_dodra wrote:

> Apart from a few *style* issues, the only thing the article contains was
> mostly hate for the stl.
>
> I understand one might dislikes the stream operators due to the syntax
> (myself included), but once you've used them more than once, and know
> how to use them, they aren't a problem. The strong typing they provide
> is simply unmatched in C++. The article even mentions that NOT using
> stream operators was one of their biggest source of bugs. And Carmack
> himself replies stating that in retrospect: StrongTyping > WeirdCode.

With variadic templates introduced in C++11 can't you implement a type safe writeln or similar just like Phobos has?

-- 
/Jacob Carlborg
January 15, 2013
On 2013-01-14 22:40, H. S. Teoh wrote:

> Stream operators are teh eviil. Overloading << and >> for I/O was a
> horrible design decision. Operator overloading should be reserved for
> numeric types. But then again, Stroustrup didn't have the benefit of
> hindsight back then, and certainly, on the surface, overloading <<
> and >> seemed like a cool thing to do. And C++ didn't (still doesn't?)
> have typesafe handling of variadics, so the desire to not have to write
> "cout.put(x); cout.put(y); cout.put(z); cout.put(w); ..." is
> understandable.

C++11 has variadic templates.

-- 
/Jacob Carlborg
January 15, 2013
On 2013-01-14 22:31, mist wrote:

> That guy has rather weird sense of beauty... My eyes started bleeding at
> the "Spacing" section.

I have to agree.

-- 
/Jacob Carlborg
January 15, 2013
On 2013-01-15 01:55, Stewart Gordon wrote:

> Am I the only one who expected, on seeing the subject line, something
> about a coding style that relies heavily on exceptions?

Yeah, I thought so too.

-- 
/Jacob Carlborg
January 15, 2013
On Tuesday, 15 January 2013 at 07:38:01 UTC, Jacob Carlborg wrote:
> On 2013-01-14 22:40, H. S. Teoh wrote:
>
>> Stream operators are teh eviil. Overloading << and >> for I/O was a
>> horrible design decision. Operator overloading should be reserved for
>> numeric types. But then again, Stroustrup didn't have the benefit of
>> hindsight back then, and certainly, on the surface, overloading <<
>> and >> seemed like a cool thing to do. And C++ didn't (still doesn't?)
>> have typesafe handling of variadics, so the desire to not have to write
>> "cout.put(x); cout.put(y); cout.put(z); cout.put(w); ..." is
>> understandable.
>
> C++11 has variadic templates.

Let's not forget variadic templates are bleeding edge here.

C++ streams are 20 years old. They are inconvenient, ugly, and hard to use, *but* they are strongly typed *and* safe, both for read and wright. And they work. Just because there is something better today doesn't mean they were a mistake.

*Sure*, today, they can use "writeln(T...)", but not 20 years ago. On the subject of safety, I still prefer "writeln" over "writefln". While writefln is safe, you can still botch the amount of args, and or flag types, in which case writefln will throw. Writeln never throws (due to a code error).
January 15, 2013
On 01/14/2013 06:13 PM, H. S. Teoh wrote:
> On Tue, Jan 15, 2013 at 12:57:17AM +0100, Timon Gehr wrote:
>> On 01/15/2013 12:26 AM, mist wrote:
> [...]
>>> - I generally can understand less at once than can possibly fit with
>>> 9th font size on 24 inch screen.
>>
>> In my experience, the screen is always too small. I prefer font size
>> 12 though.
> [...]
>
> I use font size at least 15. :-P Well, it depends on what resolution I'm
> running at.  For 1280x1024, I use about 15. For my home PC running at
> 1600x1200, I use 18 or 20. I find anything less than 14 straining on my
> eyes, and anything below 12 painful.
>
> I'm a stickler for 80 column text terminals. I find that anything much
> larger than that tends to be unwieldy because your eyes have to scan too
> far a horizontal distance per line. And I like the 80 columns to fill
> the entire width of the screen. (I have stopped believing in tiling or
> overlapping windows. Maximize everything FTW.)
>
> But then again, I don't expect anyone else to share my peculiar
> configuration.  :-P
>
>
> T
>
You know, that's almost exactly how I like my stuff.

It still seems weird.  =P
January 15, 2013
On Tuesday, 15 January 2013 at 08:29:59 UTC, monarch_dodra wrote:
> Just because there is something better today doesn't mean they were a mistake.


I'm not sure if they /were/ but they certainly /are/...

no?

Okay, how many of these streambuf methods are you familiar with?

For me that's probably between 0-2.

Now do you /really/ expect to be able to implement your own stream in a reasonable amount of time with a streambuf interface like this? That's what's wrong with streams in C++.

eback
egptr
epptr
gbump
getloc
gptr
imbue
in_avail
overflow
pbackfail
pbase
pbump
pptr
pubimbue
pubseekoff
pubseekpos
pubsetbuf
pubsync
sbumpc
seekoff
seekpos
setbuf
setg
setp
sgetc
sgetn
showmanyc
snextc
sputbackc
sputc
sputn
stossc
sungetc
sync
uflow
underflow
xsgetn
xsputn