View mode: basic / threaded / horizontal-split · Log in · Help
January 15, 2013
Re: Exceptional coding style
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.
January 15, 2013
Re: Exceptional coding style
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.
January 15, 2013
Re: Exceptional coding style
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
January 15, 2013
Re: Exceptional coding style
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
January 15, 2013
Re: Exceptional coding style
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
January 15, 2013
Re: Exceptional coding style
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
January 16, 2013
Re: Exceptional coding style
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).
January 16, 2013
Re: Exceptional coding style
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.
January 16, 2013
Re: Exceptional coding style
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.
January 16, 2013
Re: Exceptional coding style
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
5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home