On Tue, Jan 15, 2013 at 09:23:08PM +0000, Stewart Gordon wrote:
> On 15/01/2013 10:20, FG wrote:
> <snip>
> >All thanks to a terrible naming decision...
> >It's not remove but move_to_end. Why call it remove?
> 
> It doesn't necessarily move them to the end, going by
> http://www.cplusplus.com/reference/algorithm/remove/
> "The relative order of the elements not removed is preserved, while
> the elements past the new end of range are still valid, although
> with unspecified values."
[...]
       ^^^^^^^^^^^
       Very scary, but unfortunately much too frequent in C/C++.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.

On Tuesday, 15 January 2013 at 21:26:14 UTC, Stewart Gordon wrote:
> On 15/01/2013 10:20, FG wrote:
> <snip>
>> All thanks to a terrible naming decision...
>> It's not remove but move_to_end. Why call it remove?

It HAS to do this because there is a separation of iteration primitives and container. An iterator cannot (by itself) spontaneously remove a value from a container.

FWI, D has the EXACT same semantics:
1) Use std.algorithm.remove to bump the unwanted values to the end of the range, receiving in return a range of said elements.
2) Pass said range to std.container.remove to remove(erase) the elements from the container itself.

It may not be intuitive at first, but it makes perfect sense, and is (very) good design. It keeps orthogonal concepts orthogonal. the erase remove idiom always surprises the first time around, but quickly becomes natural. It's a tried and tested idiom.

> It doesn't necessarily move them to the end, going by
> http://www.cplusplus.com/reference/algorithm/remove/
> "The relative order of the elements not removed is preserved, while the elements past the new end of range are still valid, although with unspecified values."
>
> Just looking at the sample implementation there....
>
>     if (!(*first == value)) *result++ = *first;
>
> places each non-removed value in its place in the final state of the container, but doesn't do anything particular with the value where it was taken from.  In a C++11 implementation, I would expect it to become
>
>     if (!(*first == value)) *result++ = std::move(*first);
>
> Stewart.

Note that: "The behavior of this function template is *equivalent to*"

In no way does this mean this is the actual implementation. Besides, the actual definition as decribed in n3242 is:
//----
Requires: The type of *first shall satisfy the MoveAssignable requirements

Effects: Eliminates all the elements referred to by iterator i in the range [first,last) for which the following corresponding conditions hold: *i == value, pred(*i) != false.

Returns: The end of the resulting range.
//----

The "MoveAssignable" implies what you just said.

On Monday, January 14, 2013 22:31:23 mist wrote:
> On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:
> > Quite a nice read on the coding style used in Doom.
> > 
> > http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?po st=56177550
> That guy has rather weird sense of beauty... My eyes started bleeding at the "Spacing" section.

Agreed. That code was hideous. I think that the section on comments may be the only thing in that article that I actually agreed with.

- Jonathan M Davis

On Tuesday, January 15, 2013 17:33:08 mist wrote:
> so far that prefers proportional fonts for code. I need some time to even try to imagine how this may look.

I've had _one_ coworker that I know of who liked using. I still don't understand how he could read code that way. Proportional fonts make perfect sense for normal text, but they're horrible for code. Nothing lines up right. That's why I hate writing code in e-mails. Not only is it hard to get right with a proportional font, you don't even know if it's going to look the same for the person reading it.

- Jonathan M Davis

On 1/14/2013 2:26 PM, Walter Bright wrote:
> On 1/14/2013 11:24 AM, Walter Bright wrote:
>> Quite a nice read on the coding style used in Doom.
>>
>> http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
>>
>>
>
> Looks like it made reddit:
>
> http://www.reddit.com/r/programming/comments/16k7hm/the_exceptional_beauty_of_doom_3s_source_code/
>

And slashdot:

http://games.slashdot.org/story/13/01/15/1732216/doom-3-source-code-beautiful

On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:
> Quite a nice read on the coding style used in Doom.
>
> http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550

The sad part is that after all these decades, we're still _writing_ code, and we're doing it in essentially the exact same way as was done 30 years ago using a text editor.

For whatever reason, no other means of constructing software programs has really taken off, and I have to wonder why.

--rt

On Tuesday, 15 January 2013 at 23:57:44 UTC, Rob T wrote:
> On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:
>> Quite a nice read on the coding style used in Doom.
>>
>> http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
>
> The sad part is that after all these decades, we're still _writing_ code, and we're doing it in essentially the exact same way as was done 30 years ago using a text editor.
>
> For whatever reason, no other means of constructing software programs has really taken off, and I have to wonder why.
>
> --rt

Probably because typing with the keyboard directly is darn faster than anything that might involve the editor guessing what you're typing (or you using the mouse).

On Wednesday, 16 January 2013 at 00:41:51 UTC, Mehrdad wrote:
> On Tuesday, 15 January 2013 at 23:57:44 UTC, Rob T wrote:
>> On Monday, 14 January 2013 at 19:24:25 UTC, Walter Bright wrote:
>>> Quite a nice read on the coding style used in Doom.
>>>
>>> http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
>>
>> The sad part is that after all these decades, we're still _writing_ code, and we're doing it in essentially the exact same way as was done 30 years ago using a text editor.
>>
>> For whatever reason, no other means of constructing software programs has really taken off, and I have to wonder why.
>>
>> --rt
>
> Probably because typing with the keyboard directly is darn faster than anything that might involve the editor guessing what you're typing (or you using the mouse).

There's nothing stopping a more superior method from still using the keyboard.

What amazes me is how much language complexity is added just to make text editing more bearable.

On Tuesday, 15 January 2013 at 22:35:04 UTC, Jonathan M Davis wrote:
> I've had _one_ coworker that I know of who liked using. I still don't understand how he could read code that way. Proportional fonts make perfect sense for normal text, but they're horrible for code. Nothing lines up right. That's why I hate writing code in e-mails. Not only is it hard to get right with a proportional font, you don't even know if it's going to look the same for the person reading it.

 I remember being taught Java and helping everyone else debug their code. One girl had changed her fonts to this really fancy cursive font with purple & pink color. Why, I have no clue. Being too hard to read I refused to help her.

On Wednesday, 16 January 2013 at 01:03:36 UTC, Peter Alexander wrote:
>
> There's nothing stopping a more superior method from still using the keyboard.
>
> What amazes me is how much language complexity is added just to make text editing more bearable.

I agree, and consider this discussion as being a part of that complexity. We're accomplishing nothing of much importance really by aligning columns and adjusting font size, it's arcane.

I've even invented my own a naming convention to try and make text coding more bearable and efficient, but it had only limited success. I tried various IDE's but none of them seemed to make much difference, it's still text after all.

There are however some advantages with using text to construct programs, such as the extreme compactness and near universal compatibility with any text editor, however I highly doubt it is the most efficient or effective means of building software systems. The lack of innovation in this area is rather bewildering.

--rt