On Friday, 4 January 2013 at 16:47:38 UTC, Jonathan M Davis wrote:
> On Friday, January 04, 2013 13:12:52 js.mdnq wrote:
>> can you show an example of such a bug? I assume you mean that a
>> "struct literal" ends up being a local object and a ref to it can
>> easily become invalid?(in your example this is not possible
>> inside main). But your example basically contradicts what you say.
>> 
>> There is no semantic difference between
>> 
>> S s = S(2); foo(s)
>> 
>> and
>> 
>> foo(S(2));
>
> There's a _huge_ difference between those two. In the first case, you have a
> variable which exists beyond the end of the function call. In the second, you
> have temporary which is destroyed as soon as the statement has completed.

Nope, sorry, it's not. That is only a compiler optimization. Just because the compiler decides to do something to make them different does not mean they are. The compiler could easily just make S(2) null for no obvious reason because it wants to.

But if the compiler decides to make a different because of some reason(such as optimization then it also can decide to not do so.

For example, tell me why the compiler can't just expand

   foo(S(2));

to

   S ___s = S(2);
   foo(___s)

where ___s is hidden?

Then there is obviously no difference. But nothing is stopping the compiler from doing so and in fact, it could be doing so already unless you know it's not. If it did do such a hidden expansion then you would agree that the two cases are identical? (if not then there is no point is discussing any further because we can't even agree on basic logic)

Now, if the compiler decides to optimize the first case differently then the second case, that is not because they are different but because who ever write the code thinks they are.

Just because something looks different from something else does not mean they are.

On Friday, January 04, 2013 21:47:42 js.mdnq wrote:
> On Friday, 4 January 2013 at 16:47:38 UTC, Jonathan M Davis wrote:
> > On Friday, January 04, 2013 13:12:52 js.mdnq wrote:
> >> can you show an example of such a bug? I assume you mean that a
> >> "struct literal" ends up being a local object and a ref to it
> >> can
> >> easily become invalid?(in your example this is not possible
> >> inside main). But your example basically contradicts what you
> >> say.
> >> 
> >> There is no semantic difference between
> >> 
> >> S s = S(2); foo(s)
> >> 
> >> and
> >> 
> >> foo(S(2));
> > 
> > There's a _huge_ difference between those two. In the first
> > case, you have a
> > variable which exists beyond the end of the function call. In
> > the second, you
> > have temporary which is destroyed as soon as the statement has
> > completed.
> 
> Nope, sorry, it's not. That is only a compiler optimization. Just because the compiler decides to do something to make them different does not mean they are. The compiler could easily just make S(2) null for no obvious reason because it wants to.
> 
> But if the compiler decides to make a different because of some reason(such as optimization then it also can decide to not do so.
> 
> For example, tell me why the compiler can't just expand
> 
> foo(S(2));
> 
> to
> 
> S ___s = S(2);
> foo(___s)
> 
> where ___s is hidden?

S(2) _must_ leave scope after the statement foo(S(2)) completes, whereas with

S s = S(2);
foo(s);

the variable must continue to exist after foo(s) completes. That's fundamentally different. We're _not_ talking about compiler optimizations here. We're talking about the semantics of how the code works. And creating a variable on the stack would change the code's semantics, especially because foo(S(2)) should involve a move operation, whereas creating a variable on the stack would require that the object be destroyed after the call to foo. But even if declaring a hidden variable didn't change the semantics, __s must be destroyed once the statement with foo has completed, so it won't exist beyond the call to foo (it can't or it would alter the semantics of the code), so it's still fundamentally different from declaring a variable and passing it to foo, since the variable must continue to exist afterwards whereas the temporary must be gone.

- Jonathan M Davis

On 1/3/13 11:26 PM, Rob T wrote:
> On Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote:
>> What's the link?
>>
>
> The bad link is also here, including the Amazon link.
> http://dlang.org/spec.html

I've added the .mobi build to the regular site build. Unfortunately, I'm getting warnings and an output with artifacts:

http://dlang.org/dlangspec.mobi

Will look into it.


Andrei

Al 04/01/13 18:17, En/na Andrei Alexandrescu ha escrit:
> On 1/4/13 6:11 AM, Jacob Carlborg wrote:
>> On 2013-01-04 05:32, Andrei Alexandrescu wrote:
>>> On 1/3/13 11:26 PM, Rob T wrote:
>>>> On Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote:
>>>>> What's the link?
>>>>>
>>>>
>>>> The bad link is also here, including the Amazon link. http://dlang.org/spec.html
>>>>
>>>> The problem link and the Amazon e-book issue has been mentioned multiple times before and as recently as Nov last year.
>>>
>>> I don't understand what the "issue" is.
>>
>> There's a link on the top of that page, "Mobi ebook", which links to this page
>>
>> http://www.digitalmars.com/d/2.0/dlangspec.mobi
>>
>> That page results in a 404 page.
> 
> Got it, thanks. Will fwd to Walter.
> 
> Andrei
> 

dlangspec.mobi is back! :-)

-- 
Jordi Sayol

On 1/4/13 5:44 PM, Jordi Sayol wrote:
> dlangspec.mobi is back! :-)

Did my best to fix it. All, please take a look.

Andrei

Al 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit:
> On 1/4/13 5:44 PM, Jordi Sayol wrote:
>> dlangspec.mobi is back! :-)
> 
> Did my best to fix it. All, please take a look.
> 
> Andrei
> 

I found these things:

Data Type Compatibility
http://img.ly/rwtF

Named Character Entities
http://img.ly/rwug

Structs & Unions
http://img.ly/rwum

Trait
http://img.ly/rwup


May only happen in my viewer (calibre for Linux).

Regards,
-- 
Jordi Sayol

On Friday, 4 January 2013 at 23:03:32 UTC, Andrei Alexandrescu wrote:
> On 1/4/13 5:44 PM, Jordi Sayol wrote:
>> dlangspec.mobi is back! :-)
>
> Did my best to fix it. All, please take a look.
>
> Andrei

Thanks Andrei!

Calibre on Linux gives me errors when I try to view.

FBReader opens it OK, but the tables are not formatted correctly and show up flat.

I have not tried on an actual tablet or reader device.

A suggestion is to file it as a bug against the website or documentation and remove the link or note that there may be problems with it until a fix is ready.

--rt

On 1/4/13 6:59 PM, Jordi Sayol wrote:
> Al 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit:
>> On 1/4/13 5:44 PM, Jordi Sayol wrote:
>>> dlangspec.mobi is back! :-)
>>
>> Did my best to fix it. All, please take a look.
>>
>> Andrei
>>
>
> I found these things:
>
> Data Type Compatibility
> http://img.ly/rwtF
>
> Named Character Entities
> http://img.ly/rwug
>
> Structs&  Unions
> http://img.ly/rwum
>
> Trait
> http://img.ly/rwup
>
>
> May only happen in my viewer (calibre for Linux).

Thanks a bunch! I made one more pass and fixed the excessively large left and right margins. Then I took a look at each of the issues above with Kindle viewer on OSX, they all work for me.

All - one more look please: http://dlang.org/dlangspec.mobi


Thanks,

Andrei

Al 05/01/13 03:05, En/na Andrei Alexandrescu ha escrit:
> On 1/4/13 6:59 PM, Jordi Sayol wrote:
>> Al 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit:
>>> On 1/4/13 5:44 PM, Jordi Sayol wrote:
>>>> dlangspec.mobi is back! :-)
>>>
>>> Did my best to fix it. All, please take a look.
>>>
>>> Andrei
>>>
>>
>> I found these things:
>>
>> Data Type Compatibility
>> http://img.ly/rwtF
>>
>> Named Character Entities
>> http://img.ly/rwug
>>
>> Structs&  Unions
>> http://img.ly/rwum
>>
>> Trait
>> http://img.ly/rwup
>>
>>
>> May only happen in my viewer (calibre for Linux).
> 
> Thanks a bunch! I made one more pass and fixed the excessively large left and right margins. Then I took a look at each of the issues above with Kindle viewer on OSX, they all work for me.
> 
> All - one more look please: http://dlang.org/dlangspec.mobi
> 
> 
> Thanks,

Great work! All these things properly shown on Calibre too.

Just one more thing. At the "Table of Contents", there are two disabled links, "Introduction" and "Inline Assembler":

http://ves.cat/b-Vh

Regards,
-- 
Jordi Sayol

Al 05/01/13 03:42, En/na Jordi Sayol ha escrit:
> Al 05/01/13 03:05, En/na Andrei Alexandrescu ha escrit:
>> On 1/4/13 6:59 PM, Jordi Sayol wrote:
>>> Al 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit:
>>>> On 1/4/13 5:44 PM, Jordi Sayol wrote:
>>>>> dlangspec.mobi is back! :-)
>>>>
>>>> Did my best to fix it. All, please take a look.
>>>>
>>>> Andrei
>>>>
>>>
>>> I found these things:
>>>
>>> Data Type Compatibility
>>> http://img.ly/rwtF
>>>
>>> Named Character Entities
>>> http://img.ly/rwug
>>>
>>> Structs&  Unions
>>> http://img.ly/rwum
>>>
>>> Trait
>>> http://img.ly/rwup
>>>
>>>
>>> May only happen in my viewer (calibre for Linux).
>>
>> Thanks a bunch! I made one more pass and fixed the excessively large left and right margins. Then I took a look at each of the issues above with Kindle viewer on OSX, they all work for me.
>>
>> All - one more look please: http://dlang.org/dlangspec.mobi
>>
>>
>> Thanks,
> 
> Great work! All these things properly shown on Calibre too.
> 
> Just one more thing. At the "Table of Contents", there are two disabled links, "Introduction" and "Inline Assembler":
> 
> http://ves.cat/b-Vh
> 

In "Table of contents", last chapter "Vector Extensions" is missing.

-- 
Jordi Sayol