Why does “move” in Rust not actually move?












7















In the below example:



struct Foo {

    a: [u64; 100000],

}



fn foo(mut f: Foo) -> Foo {

    f.a[0] = 99999;

    f.a[1] = 99999;

    println!("{:?}", &mut f as *mut Foo);



    for i in 0..f.a[0] {

        f.a[i as usize] = 21444;

    }



    return f;

}

fn main(){

    let mut f = Foo {

        a:[0;100000]

    };



    println!("{:?}", &mut f as *mut Foo);

    f = foo(f);

    println!("{:?}", &mut f as *mut Foo);

}


I find that before and after passing into the function foo, the address of f is different. Why does Rust copy such a big struct everywhere but not actually move it (or achieve this optimization)?



I understand how stack memory works. But with the information provided by ownership in Rust, I think the copy can be avoided. The compiler unnecessarily copies the array twice. Can this be an optimization for the Rust compiler?






rust







share|improve this question

























  • C++ does essentially the same. Huge data structures can be dumped on the stack without the & in the function or method declaration indicating that you want to pass a reference. (In my case that was a bug, 200K were dumped on a 16K stack in an embedded system. Since there was no memory protection several other stacks were also wiped out, and the system crashed shortly afterwards in unrelated code. Took me a few hours to find the single missing &.)

    – starblue
    Nov 25 '18 at 9:04











  • @starblue With or without & can have lot of difference. Pass reference of a variable will share the same memory. But without & the copy constructor ( or simply copy ) will be used to create the argument variable ( it has no connection with the variable passed in after copy) . But move in c++ is used when we use && and std::move to trigger move constructor. After being moved into a function, the variable cannot be used. So the move in C++ has nearly the same semantic with rust (without security provided by ownership system), but the performance is different.

    – YangKeao
    Nov 25 '18 at 9:36






  • 1





    And how would you move an array in a C++ move constructor ? Use box for big thing.

    – Stargateur
    Nov 25 '18 at 19:39


















7















In the below example:



struct Foo {

    a: [u64; 100000],

}



fn foo(mut f: Foo) -> Foo {

    f.a[0] = 99999;

    f.a[1] = 99999;

    println!("{:?}", &mut f as *mut Foo);



    for i in 0..f.a[0] {

        f.a[i as usize] = 21444;

    }



    return f;

}

fn main(){

    let mut f = Foo {

        a:[0;100000]

    };



    println!("{:?}", &mut f as *mut Foo);

    f = foo(f);

    println!("{:?}", &mut f as *mut Foo);

}


I find that before and after passing into the function foo, the address of f is different. Why does Rust copy such a big struct everywhere but not actually move it (or achieve this optimization)?



I understand how stack memory works. But with the information provided by ownership in Rust, I think the copy can be avoided. The compiler unnecessarily copies the array twice. Can this be an optimization for the Rust compiler?






rust







share|improve this question

























  • C++ does essentially the same. Huge data structures can be dumped on the stack without the & in the function or method declaration indicating that you want to pass a reference. (In my case that was a bug, 200K were dumped on a 16K stack in an embedded system. Since there was no memory protection several other stacks were also wiped out, and the system crashed shortly afterwards in unrelated code. Took me a few hours to find the single missing &.)

    – starblue
    Nov 25 '18 at 9:04











  • @starblue With or without & can have lot of difference. Pass reference of a variable will share the same memory. But without & the copy constructor ( or simply copy ) will be used to create the argument variable ( it has no connection with the variable passed in after copy) . But move in c++ is used when we use && and std::move to trigger move constructor. After being moved into a function, the variable cannot be used. So the move in C++ has nearly the same semantic with rust (without security provided by ownership system), but the performance is different.

    – YangKeao
    Nov 25 '18 at 9:36






  • 1





    And how would you move an array in a C++ move constructor ? Use box for big thing.

    – Stargateur
    Nov 25 '18 at 19:39
















7












7








7


2






In the below example:



struct Foo {

    a: [u64; 100000],

}



fn foo(mut f: Foo) -> Foo {

    f.a[0] = 99999;

    f.a[1] = 99999;

    println!("{:?}", &mut f as *mut Foo);



    for i in 0..f.a[0] {

        f.a[i as usize] = 21444;

    }



    return f;

}

fn main(){

    let mut f = Foo {

        a:[0;100000]

    };



    println!("{:?}", &mut f as *mut Foo);

    f = foo(f);

    println!("{:?}", &mut f as *mut Foo);

}


I find that before and after passing into the function foo, the address of f is different. Why does Rust copy such a big struct everywhere but not actually move it (or achieve this optimization)?



I understand how stack memory works. But with the information provided by ownership in Rust, I think the copy can be avoided. The compiler unnecessarily copies the array twice. Can this be an optimization for the Rust compiler?






rust







share|improve this question
















In the below example:



struct Foo {

    a: [u64; 100000],

}



fn foo(mut f: Foo) -> Foo {

    f.a[0] = 99999;

    f.a[1] = 99999;

    println!("{:?}", &mut f as *mut Foo);



    for i in 0..f.a[0] {

        f.a[i as usize] = 21444;

    }



    return f;

}

fn main(){

    let mut f = Foo {

        a:[0;100000]

    };



    println!("{:?}", &mut f as *mut Foo);

    f = foo(f);

    println!("{:?}", &mut f as *mut Foo);

}


I find that before and after passing into the function foo, the address of f is different. Why does Rust copy such a big struct everywhere but not actually move it (or achieve this optimization)?



I understand how stack memory works. But with the information provided by ownership in Rust, I think the copy can be avoided. The compiler unnecessarily copies the array twice. Can this be an optimization for the Rust compiler?






rust




rust






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 25 '18 at 12:51









Boann

37.2k1290121




37.2k1290121










asked Nov 25 '18 at 8:31









YangKeaoYangKeao

623




623













  • C++ does essentially the same. Huge data structures can be dumped on the stack without the & in the function or method declaration indicating that you want to pass a reference. (In my case that was a bug, 200K were dumped on a 16K stack in an embedded system. Since there was no memory protection several other stacks were also wiped out, and the system crashed shortly afterwards in unrelated code. Took me a few hours to find the single missing &.)

    – starblue
    Nov 25 '18 at 9:04











  • @starblue With or without & can have lot of difference. Pass reference of a variable will share the same memory. But without & the copy constructor ( or simply copy ) will be used to create the argument variable ( it has no connection with the variable passed in after copy) . But move in c++ is used when we use && and std::move to trigger move constructor. After being moved into a function, the variable cannot be used. So the move in C++ has nearly the same semantic with rust (without security provided by ownership system), but the performance is different.

    – YangKeao
    Nov 25 '18 at 9:36






  • 1





    And how would you move an array in a C++ move constructor ? Use box for big thing.

    – Stargateur
    Nov 25 '18 at 19:39





















  • C++ does essentially the same. Huge data structures can be dumped on the stack without the & in the function or method declaration indicating that you want to pass a reference. (In my case that was a bug, 200K were dumped on a 16K stack in an embedded system. Since there was no memory protection several other stacks were also wiped out, and the system crashed shortly afterwards in unrelated code. Took me a few hours to find the single missing &.)

    – starblue
    Nov 25 '18 at 9:04











  • @starblue With or without & can have lot of difference. Pass reference of a variable will share the same memory. But without & the copy constructor ( or simply copy ) will be used to create the argument variable ( it has no connection with the variable passed in after copy) . But move in c++ is used when we use && and std::move to trigger move constructor. After being moved into a function, the variable cannot be used. So the move in C++ has nearly the same semantic with rust (without security provided by ownership system), but the performance is different.

    – YangKeao
    Nov 25 '18 at 9:36






  • 1





    And how would you move an array in a C++ move constructor ? Use box for big thing.

    – Stargateur
    Nov 25 '18 at 19:39



















C++ does essentially the same. Huge data structures can be dumped on the stack without the & in the function or method declaration indicating that you want to pass a reference. (In my case that was a bug, 200K were dumped on a 16K stack in an embedded system. Since there was no memory protection several other stacks were also wiped out, and the system crashed shortly afterwards in unrelated code. Took me a few hours to find the single missing &.)

– starblue
Nov 25 '18 at 9:04





C++ does essentially the same. Huge data structures can be dumped on the stack without the & in the function or method declaration indicating that you want to pass a reference. (In my case that was a bug, 200K were dumped on a 16K stack in an embedded system. Since there was no memory protection several other stacks were also wiped out, and the system crashed shortly afterwards in unrelated code. Took me a few hours to find the single missing &.)

– starblue
Nov 25 '18 at 9:04













@starblue With or without & can have lot of difference. Pass reference of a variable will share the same memory. But without & the copy constructor ( or simply copy ) will be used to create the argument variable ( it has no connection with the variable passed in after copy) . But move in c++ is used when we use && and std::move to trigger move constructor. After being moved into a function, the variable cannot be used. So the move in C++ has nearly the same semantic with rust (without security provided by ownership system), but the performance is different.

– YangKeao
Nov 25 '18 at 9:36





@starblue With or without & can have lot of difference. Pass reference of a variable will share the same memory. But without & the copy constructor ( or simply copy ) will be used to create the argument variable ( it has no connection with the variable passed in after copy) . But move in c++ is used when we use && and std::move to trigger move constructor. After being moved into a function, the variable cannot be used. So the move in C++ has nearly the same semantic with rust (without security provided by ownership system), but the performance is different.

– YangKeao
Nov 25 '18 at 9:36




1




1





And how would you move an array in a C++ move constructor ? Use box for big thing.

– Stargateur
Nov 25 '18 at 19:39







And how would you move an array in a C++ move constructor ? Use box for big thing.

– Stargateur
Nov 25 '18 at 19:39














1 Answer
1






active

oldest

votes


















4














A move is a memcpy followed by treating the source as non-existent.



Your big array is on the stack. That's just the way Rust's memory model works: local variables are on the stack. Since the stack space of foo is going away when the function returns, there's nothing else the compiler can do except copy the memory to main's stack space.



In some cases, the compiler can rearrange things so that the move can be elided (source and destination are merged into one thing), but this is an optimization that cannot be relied on, especially for big things.



If you don't want to copy the huge array around, allocate it on the heap yourself, either via a Box<[u64]>, or simply by using Vec<u64>.






share|improve this answer





















  • 2





    Or pass the function an &mut f and return nothing, which would be idiomatic in this case.

    – starblue
    Nov 25 '18 at 8:57






  • 1





    In this particular case, the move could actually be avoided. The variable f is created in the stack frame of main(), and the compiler could statically determine that it's not necessary to move it into the stack frame of foo(), since it will be copied back to its original location anyway. But even in a release build with foo() marked as #[inline(always)], the compiler still unnecessarily copies the array twice.

    – Sven Marnach
    Nov 25 '18 at 9:09













  • I understand how it works. But the ownership provide more information for compiler, with these information we can use same part of memory without any secure problem . I think it's a big optimization in some case. But rust haven't done this ( but actually when the function is inlined, it will use the same memory without copy ).

    – YangKeao
    Nov 25 '18 at 9:24






  • 1





    @YangKeao Even when inlining the function, the copy does not seem to get elided, but maybe that's because of taking the addresses, and wouldn't happen if we remove the println invocations? My understanding so far has been that Rust should be able to optimise that case.

    – Sven Marnach
    Nov 25 '18 at 12:22






  • 1





    @YangKeao I guess these kinds of optimisations aren't meant as guarantees. If you want to guarantee that no copy is happening, pass around references of boxes instead.

    – Sven Marnach
    Nov 25 '18 at 12:59











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53465843%2fwhy-does-move-in-rust-not-actually-move%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









4














A move is a memcpy followed by treating the source as non-existent.



Your big array is on the stack. That's just the way Rust's memory model works: local variables are on the stack. Since the stack space of foo is going away when the function returns, there's nothing else the compiler can do except copy the memory to main's stack space.



In some cases, the compiler can rearrange things so that the move can be elided (source and destination are merged into one thing), but this is an optimization that cannot be relied on, especially for big things.



If you don't want to copy the huge array around, allocate it on the heap yourself, either via a Box<[u64]>, or simply by using Vec<u64>.






share|improve this answer





















  • 2





    Or pass the function an &mut f and return nothing, which would be idiomatic in this case.

    – starblue
    Nov 25 '18 at 8:57






  • 1





    In this particular case, the move could actually be avoided. The variable f is created in the stack frame of main(), and the compiler could statically determine that it's not necessary to move it into the stack frame of foo(), since it will be copied back to its original location anyway. But even in a release build with foo() marked as #[inline(always)], the compiler still unnecessarily copies the array twice.

    – Sven Marnach
    Nov 25 '18 at 9:09













  • I understand how it works. But the ownership provide more information for compiler, with these information we can use same part of memory without any secure problem . I think it's a big optimization in some case. But rust haven't done this ( but actually when the function is inlined, it will use the same memory without copy ).

    – YangKeao
    Nov 25 '18 at 9:24






  • 1





    @YangKeao Even when inlining the function, the copy does not seem to get elided, but maybe that's because of taking the addresses, and wouldn't happen if we remove the println invocations? My understanding so far has been that Rust should be able to optimise that case.

    – Sven Marnach
    Nov 25 '18 at 12:22






  • 1





    @YangKeao I guess these kinds of optimisations aren't meant as guarantees. If you want to guarantee that no copy is happening, pass around references of boxes instead.

    – Sven Marnach
    Nov 25 '18 at 12:59
















4














A move is a memcpy followed by treating the source as non-existent.



Your big array is on the stack. That's just the way Rust's memory model works: local variables are on the stack. Since the stack space of foo is going away when the function returns, there's nothing else the compiler can do except copy the memory to main's stack space.



In some cases, the compiler can rearrange things so that the move can be elided (source and destination are merged into one thing), but this is an optimization that cannot be relied on, especially for big things.



If you don't want to copy the huge array around, allocate it on the heap yourself, either via a Box<[u64]>, or simply by using Vec<u64>.






share|improve this answer





















  • 2





    Or pass the function an &mut f and return nothing, which would be idiomatic in this case.

    – starblue
    Nov 25 '18 at 8:57






  • 1





    In this particular case, the move could actually be avoided. The variable f is created in the stack frame of main(), and the compiler could statically determine that it's not necessary to move it into the stack frame of foo(), since it will be copied back to its original location anyway. But even in a release build with foo() marked as #[inline(always)], the compiler still unnecessarily copies the array twice.

    – Sven Marnach
    Nov 25 '18 at 9:09













  • I understand how it works. But the ownership provide more information for compiler, with these information we can use same part of memory without any secure problem . I think it's a big optimization in some case. But rust haven't done this ( but actually when the function is inlined, it will use the same memory without copy ).

    – YangKeao
    Nov 25 '18 at 9:24






  • 1





    @YangKeao Even when inlining the function, the copy does not seem to get elided, but maybe that's because of taking the addresses, and wouldn't happen if we remove the println invocations? My understanding so far has been that Rust should be able to optimise that case.

    – Sven Marnach
    Nov 25 '18 at 12:22






  • 1





    @YangKeao I guess these kinds of optimisations aren't meant as guarantees. If you want to guarantee that no copy is happening, pass around references of boxes instead.

    – Sven Marnach
    Nov 25 '18 at 12:59














4












4








4







A move is a memcpy followed by treating the source as non-existent.



Your big array is on the stack. That's just the way Rust's memory model works: local variables are on the stack. Since the stack space of foo is going away when the function returns, there's nothing else the compiler can do except copy the memory to main's stack space.



In some cases, the compiler can rearrange things so that the move can be elided (source and destination are merged into one thing), but this is an optimization that cannot be relied on, especially for big things.



If you don't want to copy the huge array around, allocate it on the heap yourself, either via a Box<[u64]>, or simply by using Vec<u64>.






share|improve this answer















A move is a memcpy followed by treating the source as non-existent.



Your big array is on the stack. That's just the way Rust's memory model works: local variables are on the stack. Since the stack space of foo is going away when the function returns, there's nothing else the compiler can do except copy the memory to main's stack space.



In some cases, the compiler can rearrange things so that the move can be elided (source and destination are merged into one thing), but this is an optimization that cannot be relied on, especially for big things.



If you don't want to copy the huge array around, allocate it on the heap yourself, either via a Box<[u64]>, or simply by using Vec<u64>.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 25 '18 at 9:56

























answered Nov 25 '18 at 8:48









Sebastian RedlSebastian Redl

50.3k476116




50.3k476116








  • 2





    Or pass the function an &mut f and return nothing, which would be idiomatic in this case.

    – starblue
    Nov 25 '18 at 8:57






  • 1





    In this particular case, the move could actually be avoided. The variable f is created in the stack frame of main(), and the compiler could statically determine that it's not necessary to move it into the stack frame of foo(), since it will be copied back to its original location anyway. But even in a release build with foo() marked as #[inline(always)], the compiler still unnecessarily copies the array twice.

    – Sven Marnach
    Nov 25 '18 at 9:09













  • I understand how it works. But the ownership provide more information for compiler, with these information we can use same part of memory without any secure problem . I think it's a big optimization in some case. But rust haven't done this ( but actually when the function is inlined, it will use the same memory without copy ).

    – YangKeao
    Nov 25 '18 at 9:24






  • 1





    @YangKeao Even when inlining the function, the copy does not seem to get elided, but maybe that's because of taking the addresses, and wouldn't happen if we remove the println invocations? My understanding so far has been that Rust should be able to optimise that case.

    – Sven Marnach
    Nov 25 '18 at 12:22






  • 1





    @YangKeao I guess these kinds of optimisations aren't meant as guarantees. If you want to guarantee that no copy is happening, pass around references of boxes instead.

    – Sven Marnach
    Nov 25 '18 at 12:59














  • 2





    Or pass the function an &mut f and return nothing, which would be idiomatic in this case.

    – starblue
    Nov 25 '18 at 8:57






  • 1





    In this particular case, the move could actually be avoided. The variable f is created in the stack frame of main(), and the compiler could statically determine that it's not necessary to move it into the stack frame of foo(), since it will be copied back to its original location anyway. But even in a release build with foo() marked as #[inline(always)], the compiler still unnecessarily copies the array twice.

    – Sven Marnach
    Nov 25 '18 at 9:09













  • I understand how it works. But the ownership provide more information for compiler, with these information we can use same part of memory without any secure problem . I think it's a big optimization in some case. But rust haven't done this ( but actually when the function is inlined, it will use the same memory without copy ).

    – YangKeao
    Nov 25 '18 at 9:24






  • 1





    @YangKeao Even when inlining the function, the copy does not seem to get elided, but maybe that's because of taking the addresses, and wouldn't happen if we remove the println invocations? My understanding so far has been that Rust should be able to optimise that case.

    – Sven Marnach
    Nov 25 '18 at 12:22






  • 1





    @YangKeao I guess these kinds of optimisations aren't meant as guarantees. If you want to guarantee that no copy is happening, pass around references of boxes instead.

    – Sven Marnach
    Nov 25 '18 at 12:59








2




2





Or pass the function an &mut f and return nothing, which would be idiomatic in this case.

– starblue
Nov 25 '18 at 8:57





Or pass the function an &mut f and return nothing, which would be idiomatic in this case.

– starblue
Nov 25 '18 at 8:57




1




1





In this particular case, the move could actually be avoided. The variable f is created in the stack frame of main(), and the compiler could statically determine that it's not necessary to move it into the stack frame of foo(), since it will be copied back to its original location anyway. But even in a release build with foo() marked as #[inline(always)], the compiler still unnecessarily copies the array twice.

– Sven Marnach
Nov 25 '18 at 9:09







In this particular case, the move could actually be avoided. The variable f is created in the stack frame of main(), and the compiler could statically determine that it's not necessary to move it into the stack frame of foo(), since it will be copied back to its original location anyway. But even in a release build with foo() marked as #[inline(always)], the compiler still unnecessarily copies the array twice.

– Sven Marnach
Nov 25 '18 at 9:09















I understand how it works. But the ownership provide more information for compiler, with these information we can use same part of memory without any secure problem . I think it's a big optimization in some case. But rust haven't done this ( but actually when the function is inlined, it will use the same memory without copy ).

– YangKeao
Nov 25 '18 at 9:24





I understand how it works. But the ownership provide more information for compiler, with these information we can use same part of memory without any secure problem . I think it's a big optimization in some case. But rust haven't done this ( but actually when the function is inlined, it will use the same memory without copy ).

– YangKeao
Nov 25 '18 at 9:24




1




1





@YangKeao Even when inlining the function, the copy does not seem to get elided, but maybe that's because of taking the addresses, and wouldn't happen if we remove the println invocations? My understanding so far has been that Rust should be able to optimise that case.

– Sven Marnach
Nov 25 '18 at 12:22





@YangKeao Even when inlining the function, the copy does not seem to get elided, but maybe that's because of taking the addresses, and wouldn't happen if we remove the println invocations? My understanding so far has been that Rust should be able to optimise that case.

– Sven Marnach
Nov 25 '18 at 12:22




1




1





@YangKeao I guess these kinds of optimisations aren't meant as guarantees. If you want to guarantee that no copy is happening, pass around references of boxes instead.

– Sven Marnach
Nov 25 '18 at 12:59





@YangKeao I guess these kinds of optimisations aren't meant as guarantees. If you want to guarantee that no copy is happening, pass around references of boxes instead.

– Sven Marnach
Nov 25 '18 at 12:59




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid …



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53465843%2fwhy-does-move-in-rust-not-actually-move%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

Costa Masnaga

Image
.mw-parser-output .avviso .mbox-text-div>div,.mw-parser-output .avviso .mbox-text-full-div>div{font-size:90%}.mw-parser-output .avviso .mbox-image div{width:52px}.mw-parser-output .avviso .mbox-text-full-div .hide-when-compact{display:block} Questa voce o sezione sull'argomento Lombardia non cita le fonti necessarie o quelle presenti sono insufficienti . Puoi migliorare questa voce aggiungendo citazioni da fonti attendibili secondo le linee guida sull'uso delle fonti. Segui i suggerimenti del progetto di riferimento. Costa Masnaga comune Localizzazione Stato   Italia Regione Lombardia Provincia Lecco Amministrazione Sindaco Sabina Panzeri (Al centro il cittadino) dall'08/06/2009 Territorio Coordinate 45°46′N 9°17′E  /  45.766667°N 9.283333°E 45.766667; 9.283333  ( Costa Masnaga ) Coordinate: 45°46′N 9°17′E  /  45.766667°N 9.283333°E 45.766667; 9.283333  ( Costa Masnaga ) Altitudine 318 m s.l.m...
Read more

Fotorealismo

Image
Guerrino Boatto, Venice's St. Barnaba Church and canal Il fotorealismo è un genere di pittura basato sull'uso di una o più fotografie dalle quali l'artista prende le informazioni necessarie da utilizzare poi nel processo della creazione dell'opera, in genere ad olio o ad acrilico, al fine di avere un aspetto finale il più simile possibile alla fotografia. Indice 1 Storia 2 Lista dei fotorealisti 3 Note 4 Voci correlate 5 Altri progetti Storia | Il fotorealismo è un movimento che nasce negli Stati Uniti d'America alla fine degli anni sessanta [1] sulla scia della Pop Art [2] [3] [4] , e insieme condividono il carattere reazionario verso la travolgente ascesa dei media, che alla metà del ventesimo secolo si trasforma in un fenomeno di massa talmente imponente da minacciare il valore dell'immagine nell'arte. [5] [6] Ne consegue così che, colto il gesto d'inizio che fu della Pop Art, i fotorealisti aprono ad un ...
Read more

Sidney Franklin

Image
Questa voce sull'argomento registi statunitensi è solo un abbozzo . Contribuisci a migliorarla secondo le convenzioni di Wikipedia. Sidney Franklin, foto di Carl Van Vechten Oscar alla memoria Irving G. Thalberg 1943 Sidney Franklin , all'anagrafe Sidney Arnold Franklin , (San Francisco, 21 marzo 1893 – Santa Monica, 18 maggio 1972), è stato un regista, produttore cinematografico e attore statunitense. Il 20 giugno 1963, si sposò con l'attrice australiana Enid Bennett. Il matrimonio durò fino alla morte dell'attrice, il 14 maggio 1969 [1] Indice 1 Filmografia 1.1 Regista 1.2 Aiuto regia (parziale) 1.3 Produttore 1.4 Attore (parziale) 2 Note 3 Altri progetti 4 Collegamenti esterni Filmografia | Regista | The Baby , co-regia Chester M. Franklin (1915) The Rivals , co-regia Chester M. Franklin (1915) Little Dick's First Case , co-regia Chester M. Franklin (1915) Her Filmland Hero , co-...
Read more