hey gang!

one of the side effects of having multiple files the way i have them now
seems to be that if you want to be able to have stuff like:

File a = SD.open("/foo.txt");
File b = SD.open("/bar.txt");

e.g. multiple files opened, that are passed by value so you can return
them from open() - less memory annoyance

but there is no underlying 'static' object that is consistent. which is
great because you can return by value. but object data like "location in
file" is copied between function calls, and isn't changed globally.

for example!

----------
File f; // contains string "abc"

int reader(File x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

----------
>>>> will print out "aa" (incorrect)
----------
File f; // contains string "abc"

int reader(void) {
return f.read();
}

main() {
print(reader());
print(reader());
}
----------
>>>> will print out "ab" (correct)
this is because the state is stored globally and is not copied

i -think- the only way to make it so you can pass the files around
without this is to have them be references to global file objects that
are on the heap (not stack like these). which seems like a pain.

here's where i'd like your assistance:
1) am i missing an easy way to fix this issue?

2)i think i want to avoid using new() since that means after you open()
a file, you'll have to close() and delete() and arduino doesnt really
use delete() so much and people will forget.

3) or i could make people pass pointers to File's instead of Files which
is probably OK but a little nonideal since pointers are a mystery. i
suppose there's no conflict with existing code since no existing code
passes around the file object since there's only one.

anyways, useful suggestions welcome now before i make a decision!

thanks as always,
limor


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)

hey gang!

one of the side effects of having multiple files the way i have them now
seems to be that if you want to be able to have stuff like:

File a = SD.open("/foo.txt");
File b = SD.open("/bar.txt");

e.g. multiple files opened, that are passed by value so you can return
them from open() - less memory annoyance

but there is no underlying 'static' object that is consistent. which is
great because you can return by value. but object data like "location in
file" is copied between function calls, and isn't changed globally.

for example!

----------
File f; // contains string "abc"

int reader(File x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

----------
>>>> will print out "aa" (incorrect)
----------
File f; // contains string "abc"

int reader(void) {
return f.read();
}

main() {
print(reader());
print(reader());
}
----------
>>>> will print out "ab" (correct)
this is because the state is stored globally and is not copied

i -think- the only way to make it so you can pass the files around
without this is to have them be references to global file objects that
are on the heap (not stack like these). which seems like a pain.

here's where i'd like your assistance:
1) am i missing an easy way to fix this issue?

2)i think i want to avoid using new() since that means after you open()
a file, you'll have to close() and delete() and arduino doesnt really
use delete() so much and people will forget.

3) or i could make people pass pointers to File's instead of Files which
is probably OK but a little nonideal since pointers are a mystery. i
suppose there's no conflict with existing code since no existing code
passes around the file object since there's only one.

anyways, useful suggestions welcome now before i make a decision!

thanks as always,
limor


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
Maybe I'm missing something obvious, but aren't pass-by-value /
pass-by-reference semantics handled on a per-function basis, depending
on the definition of the function?

So, for example, couldn't you do something like the following?

// pass x by reference
int reader(File& x) {
return x.read();
}

main() {
File f; // contains string "abc"
print(reader(f));
print(reader(f));
}

That maintains object (i.e., non-pointer) usage, and lets f's state
persist between function calls like that, as described here:
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference

Wouldn't that handle this situation? Or is there some constraint
preventing pass-by-reference usage?

Andrew


On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.

hey gang!

one of the side effects of having multiple files the way i have them now
seems to be that if you want to be able to have stuff like:

File a = SD.open("/foo.txt");
File b = SD.open("/bar.txt");

e.g. multiple files opened, that are passed by value so you can return
them from open() - less memory annoyance

but there is no underlying 'static' object that is consistent. which is
great because you can return by value. but object data like "location in
file" is copied between function calls, and isn't changed globally.

for example!

----------
File f; // contains string "abc"

int reader(File x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

----------
>>>> will print out "aa" (incorrect)
----------
File f; // contains string "abc"

int reader(void) {
return f.read();
}

main() {
print(reader());
print(reader());
}
----------
>>>> will print out "ab" (correct)
this is because the state is stored globally and is not copied

i -think- the only way to make it so you can pass the files around
without this is to have them be references to global file objects that
are on the heap (not stack like these). which seems like a pain.

here's where i'd like your assistance:
1) am i missing an easy way to fix this issue?

2)i think i want to avoid using new() since that means after you open()
a file, you'll have to close() and delete() and arduino doesnt really
use delete() so much and people will forget.

3) or i could make people pass pointers to File's instead of Files which
is probably OK but a little nonideal since pointers are a mystery. i
suppose there's no conflict with existing code since no existing code
passes around the file object since there's only one.

anyways, useful suggestions welcome now before i make a decision!

thanks as always,
limor


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
Maybe I'm missing something obvious, but aren't pass-by-value /
pass-by-reference semantics handled on a per-function basis, depending
on the definition of the function?

So, for example, couldn't you do something like the following?

// pass x by reference
int reader(File& x) {
return x.read();
}

main() {
File f; // contains string "abc"
print(reader(f));
print(reader(f));
}

That maintains object (i.e., non-pointer) usage, and lets f's state
persist between function calls like that, as described here:
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference

Wouldn't that handle this situation? Or is there some constraint
preventing pass-by-reference usage?

Andrew


On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. Hi Limor,

I think most C++ folks would say that the standard way of building functions
like this that need to change the state of a passed-in parameter is to make
that parameters call-by-reference. Your code would look something like
this:

File f; // contains string "abc"

int reader(File &x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

Note the & in the parameter list. This says that x is a reference (read:
address) to a "File" object. X is no longer a copy of f, it's the *same*
object. For students coming from a C background, I explain that references
behave semantically like pointers, but are syntactically more similar to the
comfortable call-by-value. (No frightening dereference * operators!)

Note also that this style is also often superior performance-wise, because
call-by-value copies the entire class each time you call the function.

There should be no need for any heap allocation or static globals or
pointers or anything.

Best regards,

Mikal



> -----Original Message-----
> From: developers- [mailto:developers-
> ] On Behalf Of Limor
> Sent: Friday, February 25, 2011 7:03 PM
> To: Arduino Developer's List
> Subject: [Developers] sd/file pass-by-value not reference
>
> hey gang!
>
> one of the side effects of having multiple files the way i have them
> now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return
> them from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location
> in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
> return x.read();
> }
>
> main() {
> print(reader(f));
> print(reader(f));
> }
>
> ----------
> >>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
> return f.read();
> }
>
> main() {
> print(reader());
> print(reader());
> }
> ----------
> >>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around
> without this is to have them be references to global file objects that
> are on the heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open()
> a file, you'll have to close() and delete() and arduino doesnt really
> use delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files
> which
> is probably OK but a little nonideal since pointers are a mystery. i
> suppose there's no conflict with existing code since no existing code
> passes around the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)

hey gang!

one of the side effects of having multiple files the way i have them now
seems to be that if you want to be able to have stuff like:

File a = SD.open("/foo.txt");
File b = SD.open("/bar.txt");

e.g. multiple files opened, that are passed by value so you can return
them from open() - less memory annoyance

but there is no underlying 'static' object that is consistent. which is
great because you can return by value. but object data like "location in
file" is copied between function calls, and isn't changed globally.

for example!

----------
File f; // contains string "abc"

int reader(File x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

----------
>>>> will print out "aa" (incorrect)
----------
File f; // contains string "abc"

int reader(void) {
return f.read();
}

main() {
print(reader());
print(reader());
}
----------
>>>> will print out "ab" (correct)
this is because the state is stored globally and is not copied

i -think- the only way to make it so you can pass the files around
without this is to have them be references to global file objects that
are on the heap (not stack like these). which seems like a pain.

here's where i'd like your assistance:
1) am i missing an easy way to fix this issue?

2)i think i want to avoid using new() since that means after you open()
a file, you'll have to close() and delete() and arduino doesnt really
use delete() so much and people will forget.

3) or i could make people pass pointers to File's instead of Files which
is probably OK but a little nonideal since pointers are a mystery. i
suppose there's no conflict with existing code since no existing code
passes around the file object since there's only one.

anyways, useful suggestions welcome now before i make a decision!

thanks as always,
limor


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
Maybe I'm missing something obvious, but aren't pass-by-value /
pass-by-reference semantics handled on a per-function basis, depending
on the definition of the function?

So, for example, couldn't you do something like the following?

// pass x by reference
int reader(File& x) {
return x.read();
}

main() {
File f; // contains string "abc"
print(reader(f));
print(reader(f));
}

That maintains object (i.e., non-pointer) usage, and lets f's state
persist between function calls like that, as described here:
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference

Wouldn't that handle this situation? Or is there some constraint
preventing pass-by-reference usage?

Andrew


On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. Hi Limor,

I think most C++ folks would say that the standard way of building functions
like this that need to change the state of a passed-in parameter is to make
that parameters call-by-reference. Your code would look something like
this:

File f; // contains string "abc"

int reader(File &x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

Note the & in the parameter list. This says that x is a reference (read:
address) to a "File" object. X is no longer a copy of f, it's the *same*
object. For students coming from a C background, I explain that references
behave semantically like pointers, but are syntactically more similar to the
comfortable call-by-value. (No frightening dereference * operators!)

Note also that this style is also often superior performance-wise, because
call-by-value copies the entire class each time you call the function.

There should be no need for any heap allocation or static globals or
pointers or anything.

Best regards,

Mikal



> -----Original Message-----
> From: developers- [mailto:developers-
> ] On Behalf Of Limor
> Sent: Friday, February 25, 2011 7:03 PM
> To: Arduino Developer's List
> Subject: [Developers] sd/file pass-by-value not reference
>
> hey gang!
>
> one of the side effects of having multiple files the way i have them
> now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return
> them from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location
> in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
> return x.read();
> }
>
> main() {
> print(reader(f));
> print(reader(f));
> }
>
> ----------
> >>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
> return f.read();
> }
>
> main() {
> print(reader());
> print(reader());
> }
> ----------
> >>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around
> without this is to have them be references to global file objects that
> are on the heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open()
> a file, you'll have to close() and delete() and arduino doesnt really
> use delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files
> which
> is probably OK but a little nonideal since pointers are a mystery. i
> suppose there's no conflict with existing code since no existing code
> passes around the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
One of my priorities for the Arduino language is to minimize the
amount of syntax people need to learn, so I'd like to avoid requiring
them to use pointer or reference notation.

My suggestion is to make File a wrapper for a pointer to an SdFile
object that was allocated on the heap. With something like a file,
we're going to want people to explicitly call close anyway, so we
should be able to deallocate the memory there, too. People already
need to check if opening the file succeeded, so the fact that it could
fail from a lack of memory doesn't impose the need for significant
additional error checking.

Another possibility that avoids new syntax is having some set number
of statically allocated file objects. But this seems unnecessary
wasteful if people don't need them, and limiting if they need more.
Because in this case the additional user requirements for handling
dynamic allocation are minimal, I'd prefer that approach.

What do you think?

On Fri, Feb 25, 2011 at 8:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)

hey gang!

one of the side effects of having multiple files the way i have them now
seems to be that if you want to be able to have stuff like:

File a = SD.open("/foo.txt");
File b = SD.open("/bar.txt");

e.g. multiple files opened, that are passed by value so you can return
them from open() - less memory annoyance

but there is no underlying 'static' object that is consistent. which is
great because you can return by value. but object data like "location in
file" is copied between function calls, and isn't changed globally.

for example!

----------
File f; // contains string "abc"

int reader(File x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

----------
>>>> will print out "aa" (incorrect)
----------
File f; // contains string "abc"

int reader(void) {
return f.read();
}

main() {
print(reader());
print(reader());
}
----------
>>>> will print out "ab" (correct)
this is because the state is stored globally and is not copied

i -think- the only way to make it so you can pass the files around
without this is to have them be references to global file objects that
are on the heap (not stack like these). which seems like a pain.

here's where i'd like your assistance:
1) am i missing an easy way to fix this issue?

2)i think i want to avoid using new() since that means after you open()
a file, you'll have to close() and delete() and arduino doesnt really
use delete() so much and people will forget.

3) or i could make people pass pointers to File's instead of Files which
is probably OK but a little nonideal since pointers are a mystery. i
suppose there's no conflict with existing code since no existing code
passes around the file object since there's only one.

anyways, useful suggestions welcome now before i make a decision!

thanks as always,
limor


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
Maybe I'm missing something obvious, but aren't pass-by-value /
pass-by-reference semantics handled on a per-function basis, depending
on the definition of the function?

So, for example, couldn't you do something like the following?

// pass x by reference
int reader(File& x) {
return x.read();
}

main() {
File f; // contains string "abc"
print(reader(f));
print(reader(f));
}

That maintains object (i.e., non-pointer) usage, and lets f's state
persist between function calls like that, as described here:
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference

Wouldn't that handle this situation? Or is there some constraint
preventing pass-by-reference usage?

Andrew


On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. Hi Limor,

I think most C++ folks would say that the standard way of building functions
like this that need to change the state of a passed-in parameter is to make
that parameters call-by-reference. Your code would look something like
this:

File f; // contains string "abc"

int reader(File &x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

Note the & in the parameter list. This says that x is a reference (read:
address) to a "File" object. X is no longer a copy of f, it's the *same*
object. For students coming from a C background, I explain that references
behave semantically like pointers, but are syntactically more similar to the
comfortable call-by-value. (No frightening dereference * operators!)

Note also that this style is also often superior performance-wise, because
call-by-value copies the entire class each time you call the function.

There should be no need for any heap allocation or static globals or
pointers or anything.

Best regards,

Mikal



> -----Original Message-----
> From: developers- [mailto:developers-
> ] On Behalf Of Limor
> Sent: Friday, February 25, 2011 7:03 PM
> To: Arduino Developer's List
> Subject: [Developers] sd/file pass-by-value not reference
>
> hey gang!
>
> one of the side effects of having multiple files the way i have them
> now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return
> them from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location
> in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
> return x.read();
> }
>
> main() {
> print(reader(f));
> print(reader(f));
> }
>
> ----------
> >>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
> return f.read();
> }
>
> main() {
> print(reader());
> print(reader());
> }
> ----------
> >>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around
> without this is to have them be references to global file objects that
> are on the heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open()
> a file, you'll have to close() and delete() and arduino doesnt really
> use delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files
> which
> is probably OK but a little nonideal since pointers are a mystery. i
> suppose there's no conflict with existing code since no existing code
> passes around the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
One of my priorities for the Arduino language is to minimize the
amount of syntax people need to learn, so I'd like to avoid requiring
them to use pointer or reference notation.

My suggestion is to make File a wrapper for a pointer to an SdFile
object that was allocated on the heap. With something like a file,
we're going to want people to explicitly call close anyway, so we
should be able to deallocate the memory there, too. People already
need to check if opening the file succeeded, so the fact that it could
fail from a lack of memory doesn't impose the need for significant
additional error checking.

Another possibility that avoids new syntax is having some set number
of statically allocated file objects. But this seems unnecessary
wasteful if people don't need them, and limiting if they need more.
Because in this case the additional user requirements for handling
dynamic allocation are minimal, I'd prefer that approach.

What do you think?

On Fri, Feb 25, 2011 at 8:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)


On 2/26/2011 11:14 AM, David A. Mellis wrote:
> One of my priorities for the Arduino language is to minimize the
> amount of syntax people need to learn, so I'd like to avoid requiring
> them to use pointer or reference notation.
>
> My suggestion is to make File a wrapper for a pointer to an SdFile
> object that was allocated on the heap. With something like a file,
> we're going to want people to explicitly call close anyway, so we
> should be able to deallocate the memory there, too. People already
> need to check if opening the file succeeded, so the fact that it could
> fail from a lack of memory doesn't impose the need for significant
> additional error checking.
>
> Another possibility that avoids new syntax is having some set number
> of statically allocated file objects. But this seems unnecessary
> wasteful if people don't need them, and limiting if they need more.
> Because in this case the additional user requirements for handling
> dynamic allocation are minimal, I'd prefer that approach.
>
> What do you think?

I was thinking of this but dreading that users would forget to close()
and we'd just have floating chunks of memory that we cant spare. But
then I also thought of having a basic poor-mans-garbagecollector which
could count refs to each sdfile and delete it when no more Files are
pointing to it. not sure if that will make it into my version but it is
something that is easy to add in the backend and only costs a byte.


limor

> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>> hey gang!
>>
>> one of the side effects of having multiple files the way i have them now
>> seems to be that if you want to be able to have stuff like:
>>
>> File a = SD.open("/foo.txt");
>> File b = SD.open("/bar.txt");
>>
>> e.g. multiple files opened, that are passed by value so you can return them
>> from open() - less memory annoyance
>>
>> but there is no underlying 'static' object that is consistent. which is
>> great because you can return by value. but object data like "location in
>> file" is copied between function calls, and isn't changed globally.
>>
>> for example!
>>
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(File x) {
>> return x.read();
>> }
>>
>> main() {
>> print(reader(f));
>> print(reader(f));
>> }
>>
>> ----------
>>>>>> will print out "aa" (incorrect)
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(void) {
>> return f.read();
>> }
>>
>> main() {
>> print(reader());
>> print(reader());
>> }
>> ----------
>>>>>> will print out "ab" (correct)
>> this is because the state is stored globally and is not copied
>>
>> i -think- the only way to make it so you can pass the files around without
>> this is to have them be references to global file objects that are on the
>> heap (not stack like these). which seems like a pain.
>>
>> here's where i'd like your assistance:
>> 1) am i missing an easy way to fix this issue?
>>
>> 2)i think i want to avoid using new() since that means after you open() a
>> file, you'll have to close() and delete() and arduino doesnt really use
>> delete() so much and people will forget.
>>
>> 3) or i could make people pass pointers to File's instead of Files which is
>> probably OK but a little nonideal since pointers are a mystery. i suppose
>> there's no conflict with existing code since no existing code passes around
>> the file object since there's only one.
>>
>> anyways, useful suggestions welcome now before i make a decision!
>>
>> thanks as always,
>> limor
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)

hey gang!

one of the side effects of having multiple files the way i have them now
seems to be that if you want to be able to have stuff like:

File a = SD.open("/foo.txt");
File b = SD.open("/bar.txt");

e.g. multiple files opened, that are passed by value so you can return
them from open() - less memory annoyance

but there is no underlying 'static' object that is consistent. which is
great because you can return by value. but object data like "location in
file" is copied between function calls, and isn't changed globally.

for example!

----------
File f; // contains string "abc"

int reader(File x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

----------
>>>> will print out "aa" (incorrect)
----------
File f; // contains string "abc"

int reader(void) {
return f.read();
}

main() {
print(reader());
print(reader());
}
----------
>>>> will print out "ab" (correct)
this is because the state is stored globally and is not copied

i -think- the only way to make it so you can pass the files around
without this is to have them be references to global file objects that
are on the heap (not stack like these). which seems like a pain.

here's where i'd like your assistance:
1) am i missing an easy way to fix this issue?

2)i think i want to avoid using new() since that means after you open()
a file, you'll have to close() and delete() and arduino doesnt really
use delete() so much and people will forget.

3) or i could make people pass pointers to File's instead of Files which
is probably OK but a little nonideal since pointers are a mystery. i
suppose there's no conflict with existing code since no existing code
passes around the file object since there's only one.

anyways, useful suggestions welcome now before i make a decision!

thanks as always,
limor


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
Maybe I'm missing something obvious, but aren't pass-by-value /
pass-by-reference semantics handled on a per-function basis, depending
on the definition of the function?

So, for example, couldn't you do something like the following?

// pass x by reference
int reader(File& x) {
return x.read();
}

main() {
File f; // contains string "abc"
print(reader(f));
print(reader(f));
}

That maintains object (i.e., non-pointer) usage, and lets f's state
persist between function calls like that, as described here:
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference

Wouldn't that handle this situation? Or is there some constraint
preventing pass-by-reference usage?

Andrew


On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. Hi Limor,

I think most C++ folks would say that the standard way of building functions
like this that need to change the state of a passed-in parameter is to make
that parameters call-by-reference. Your code would look something like
this:

File f; // contains string "abc"

int reader(File &x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

Note the & in the parameter list. This says that x is a reference (read:
address) to a "File" object. X is no longer a copy of f, it's the *same*
object. For students coming from a C background, I explain that references
behave semantically like pointers, but are syntactically more similar to the
comfortable call-by-value. (No frightening dereference * operators!)

Note also that this style is also often superior performance-wise, because
call-by-value copies the entire class each time you call the function.

There should be no need for any heap allocation or static globals or
pointers or anything.

Best regards,

Mikal



> -----Original Message-----
> From: developers- [mailto:developers-
> ] On Behalf Of Limor
> Sent: Friday, February 25, 2011 7:03 PM
> To: Arduino Developer's List
> Subject: [Developers] sd/file pass-by-value not reference
>
> hey gang!
>
> one of the side effects of having multiple files the way i have them
> now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return
> them from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location
> in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
> return x.read();
> }
>
> main() {
> print(reader(f));
> print(reader(f));
> }
>
> ----------
> >>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
> return f.read();
> }
>
> main() {
> print(reader());
> print(reader());
> }
> ----------
> >>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around
> without this is to have them be references to global file objects that
> are on the heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open()
> a file, you'll have to close() and delete() and arduino doesnt really
> use delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files
> which
> is probably OK but a little nonideal since pointers are a mystery. i
> suppose there's no conflict with existing code since no existing code
> passes around the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
One of my priorities for the Arduino language is to minimize the
amount of syntax people need to learn, so I'd like to avoid requiring
them to use pointer or reference notation.

My suggestion is to make File a wrapper for a pointer to an SdFile
object that was allocated on the heap. With something like a file,
we're going to want people to explicitly call close anyway, so we
should be able to deallocate the memory there, too. People already
need to check if opening the file succeeded, so the fact that it could
fail from a lack of memory doesn't impose the need for significant
additional error checking.

Another possibility that avoids new syntax is having some set number
of statically allocated file objects. But this seems unnecessary
wasteful if people don't need them, and limiting if they need more.
Because in this case the additional user requirements for handling
dynamic allocation are minimal, I'd prefer that approach.

What do you think?

On Fri, Feb 25, 2011 at 8:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)


On 2/26/2011 11:14 AM, David A. Mellis wrote:
> One of my priorities for the Arduino language is to minimize the
> amount of syntax people need to learn, so I'd like to avoid requiring
> them to use pointer or reference notation.
>
> My suggestion is to make File a wrapper for a pointer to an SdFile
> object that was allocated on the heap. With something like a file,
> we're going to want people to explicitly call close anyway, so we
> should be able to deallocate the memory there, too. People already
> need to check if opening the file succeeded, so the fact that it could
> fail from a lack of memory doesn't impose the need for significant
> additional error checking.
>
> Another possibility that avoids new syntax is having some set number
> of statically allocated file objects. But this seems unnecessary
> wasteful if people don't need them, and limiting if they need more.
> Because in this case the additional user requirements for handling
> dynamic allocation are minimal, I'd prefer that approach.
>
> What do you think?

I was thinking of this but dreading that users would forget to close()
and we'd just have floating chunks of memory that we cant spare. But
then I also thought of having a basic poor-mans-garbagecollector which
could count refs to each sdfile and delete it when no more Files are
pointing to it. not sure if that will make it into my version but it is
something that is easy to add in the backend and only costs a byte.


limor

> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>> hey gang!
>>
>> one of the side effects of having multiple files the way i have them now
>> seems to be that if you want to be able to have stuff like:
>>
>> File a = SD.open("/foo.txt");
>> File b = SD.open("/bar.txt");
>>
>> e.g. multiple files opened, that are passed by value so you can return them
>> from open() - less memory annoyance
>>
>> but there is no underlying 'static' object that is consistent. which is
>> great because you can return by value. but object data like "location in
>> file" is copied between function calls, and isn't changed globally.
>>
>> for example!
>>
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(File x) {
>> return x.read();
>> }
>>
>> main() {
>> print(reader(f));
>> print(reader(f));
>> }
>>
>> ----------
>>>>>> will print out "aa" (incorrect)
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(void) {
>> return f.read();
>> }
>>
>> main() {
>> print(reader());
>> print(reader());
>> }
>> ----------
>>>>>> will print out "ab" (correct)
>> this is because the state is stored globally and is not copied
>>
>> i -think- the only way to make it so you can pass the files around without
>> this is to have them be references to global file objects that are on the
>> heap (not stack like these). which seems like a pain.
>>
>> here's where i'd like your assistance:
>> 1) am i missing an easy way to fix this issue?
>>
>> 2)i think i want to avoid using new() since that means after you open() a
>> file, you'll have to close() and delete() and arduino doesnt really use
>> delete() so much and people will forget.
>>
>> 3) or i could make people pass pointers to File's instead of Files which is
>> probably OK but a little nonideal since pointers are a mystery. i suppose
>> there's no conflict with existing code since no existing code passes around
>> the file object since there's only one.
>>
>> anyways, useful suggestions welcome now before i make a decision!
>>
>> thanks as always,
>> limor
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
You're right that people will probably forget to close files. On the
other hand, it should be pretty easy for them to fix the problem if
someone asks them if they remembered to close their files. I wouldn't
worry about reference counting for an initial implementation. As you
say, we could add it later, although it won't really work with global
variables, which tend to be pretty common in Arduino sketches.

On Sat, Feb 26, 2011 at 12:42 PM, Limor <> wrote:
>
>
> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>
>> One of my priorities for the Arduino language is to minimize the
>> amount of syntax people need to learn, so I'd like to avoid requiring
>> them to use pointer or reference notation.
>>
>> My suggestion is to make File a wrapper for a pointer to an SdFile
>> object that was allocated on the heap.  With something like a file,
>> we're going to want people to explicitly call close anyway, so we
>> should be able to deallocate the memory there, too.  People already
>> need to check if opening the file succeeded, so the fact that it could
>> fail from a lack of memory doesn't impose the need for significant
>> additional error checking.
>>
>> Another possibility that avoids new syntax is having some set number
>> of statically allocated file objects.  But this seems unnecessary
>> wasteful if people don't need them, and limiting if they need more.
>> Because in this case the additional user requirements for handling
>> dynamic allocation are minimal, I'd prefer that approach.
>>
>> What do you think?
>
> I was thinking of this but dreading that users would forget to close() and
> we'd just have floating chunks of memory that we cant spare. But then I also
> thought of having a basic poor-mans-garbagecollector which could count refs
> to each sdfile and delete it when no more Files are pointing to it. not sure
> if that will make it into my version but it is something that is easy to add
> in the backend and only costs a byte.
>
>
>  limor
>
>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<>  wrote:
>>>
>>>  hey gang!
>>>
>>>  one of the side effects of having multiple files the way i have them now
>>>  seems to be that if you want to be able to have stuff like:
>>>
>>>  File a = SD.open("/foo.txt");
>>>  File b = SD.open("/bar.txt");
>>>
>>>  e.g. multiple files opened, that are passed by value so you can return
>>> them
>>>  from open() - less memory annoyance
>>>
>>>  but there is no underlying 'static' object that is consistent. which is
>>>  great because you can return by value. but object data like "location in
>>>  file" is copied between function calls, and isn't changed globally.
>>>
>>>  for example!
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(File x) {
>>>    return x.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader(f));
>>>   print(reader(f));
>>>  }
>>>
>>>  ----------
>>>>>>>
>>>>>>>  will print out "aa" (incorrect)
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(void) {
>>>    return f.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader());
>>>   print(reader());
>>>  }
>>>  ----------
>>>>>>>
>>>>>>>  will print out "ab" (correct)
>>>
>>>  this is because the state is stored globally and is not copied
>>>
>>>  i -think- the only way to make it so you can pass the files around
>>> without
>>>  this is to have them be references to global file objects that are on
>>> the
>>>  heap (not stack like these). which seems like a pain.
>>>
>>>  here's where i'd like your assistance:
>>>  1) am i missing an easy way to fix this issue?
>>>
>>>  2)i think i want to avoid using new() since that means after you open()
>>> a
>>>  file, you'll have to close() and delete() and arduino doesnt really use
>>>  delete() so much and people will forget.
>>>
>>>  3) or i could make people pass pointers to File's instead of Files which
>>> is
>>>  probably OK but a little nonideal since pointers are a mystery. i
>>> suppose
>>>  there's no conflict with existing code since no existing code passes
>>> around
>>>  the file object since there's only one.
>>>
>>>  anyways, useful suggestions welcome now before i make a decision!
>>>
>>>  thanks as always,
>>>  limor
>>>
>>>
>>>  _______________________________________________
>>>  Developers mailing list
>>>  
>>>  http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)

hey gang!

one of the side effects of having multiple files the way i have them now
seems to be that if you want to be able to have stuff like:

File a = SD.open("/foo.txt");
File b = SD.open("/bar.txt");

e.g. multiple files opened, that are passed by value so you can return
them from open() - less memory annoyance

but there is no underlying 'static' object that is consistent. which is
great because you can return by value. but object data like "location in
file" is copied between function calls, and isn't changed globally.

for example!

----------
File f; // contains string "abc"

int reader(File x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

----------
>>>> will print out "aa" (incorrect)
----------
File f; // contains string "abc"

int reader(void) {
return f.read();
}

main() {
print(reader());
print(reader());
}
----------
>>>> will print out "ab" (correct)
this is because the state is stored globally and is not copied

i -think- the only way to make it so you can pass the files around
without this is to have them be references to global file objects that
are on the heap (not stack like these). which seems like a pain.

here's where i'd like your assistance:
1) am i missing an easy way to fix this issue?

2)i think i want to avoid using new() since that means after you open()
a file, you'll have to close() and delete() and arduino doesnt really
use delete() so much and people will forget.

3) or i could make people pass pointers to File's instead of Files which
is probably OK but a little nonideal since pointers are a mystery. i
suppose there's no conflict with existing code since no existing code
passes around the file object since there's only one.

anyways, useful suggestions welcome now before i make a decision!

thanks as always,
limor


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
Maybe I'm missing something obvious, but aren't pass-by-value /
pass-by-reference semantics handled on a per-function basis, depending
on the definition of the function?

So, for example, couldn't you do something like the following?

// pass x by reference
int reader(File& x) {
return x.read();
}

main() {
File f; // contains string "abc"
print(reader(f));
print(reader(f));
}

That maintains object (i.e., non-pointer) usage, and lets f's state
persist between function calls like that, as described here:
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference

Wouldn't that handle this situation? Or is there some constraint
preventing pass-by-reference usage?

Andrew


On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. Hi Limor,

I think most C++ folks would say that the standard way of building functions
like this that need to change the state of a passed-in parameter is to make
that parameters call-by-reference. Your code would look something like
this:

File f; // contains string "abc"

int reader(File &x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

Note the & in the parameter list. This says that x is a reference (read:
address) to a "File" object. X is no longer a copy of f, it's the *same*
object. For students coming from a C background, I explain that references
behave semantically like pointers, but are syntactically more similar to the
comfortable call-by-value. (No frightening dereference * operators!)

Note also that this style is also often superior performance-wise, because
call-by-value copies the entire class each time you call the function.

There should be no need for any heap allocation or static globals or
pointers or anything.

Best regards,

Mikal



> -----Original Message-----
> From: developers- [mailto:developers-
> ] On Behalf Of Limor
> Sent: Friday, February 25, 2011 7:03 PM
> To: Arduino Developer's List
> Subject: [Developers] sd/file pass-by-value not reference
>
> hey gang!
>
> one of the side effects of having multiple files the way i have them
> now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return
> them from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location
> in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
> return x.read();
> }
>
> main() {
> print(reader(f));
> print(reader(f));
> }
>
> ----------
> >>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
> return f.read();
> }
>
> main() {
> print(reader());
> print(reader());
> }
> ----------
> >>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around
> without this is to have them be references to global file objects that
> are on the heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open()
> a file, you'll have to close() and delete() and arduino doesnt really
> use delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files
> which
> is probably OK but a little nonideal since pointers are a mystery. i
> suppose there's no conflict with existing code since no existing code
> passes around the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
One of my priorities for the Arduino language is to minimize the
amount of syntax people need to learn, so I'd like to avoid requiring
them to use pointer or reference notation.

My suggestion is to make File a wrapper for a pointer to an SdFile
object that was allocated on the heap. With something like a file,
we're going to want people to explicitly call close anyway, so we
should be able to deallocate the memory there, too. People already
need to check if opening the file succeeded, so the fact that it could
fail from a lack of memory doesn't impose the need for significant
additional error checking.

Another possibility that avoids new syntax is having some set number
of statically allocated file objects. But this seems unnecessary
wasteful if people don't need them, and limiting if they need more.
Because in this case the additional user requirements for handling
dynamic allocation are minimal, I'd prefer that approach.

What do you think?

On Fri, Feb 25, 2011 at 8:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)


On 2/26/2011 11:14 AM, David A. Mellis wrote:
> One of my priorities for the Arduino language is to minimize the
> amount of syntax people need to learn, so I'd like to avoid requiring
> them to use pointer or reference notation.
>
> My suggestion is to make File a wrapper for a pointer to an SdFile
> object that was allocated on the heap. With something like a file,
> we're going to want people to explicitly call close anyway, so we
> should be able to deallocate the memory there, too. People already
> need to check if opening the file succeeded, so the fact that it could
> fail from a lack of memory doesn't impose the need for significant
> additional error checking.
>
> Another possibility that avoids new syntax is having some set number
> of statically allocated file objects. But this seems unnecessary
> wasteful if people don't need them, and limiting if they need more.
> Because in this case the additional user requirements for handling
> dynamic allocation are minimal, I'd prefer that approach.
>
> What do you think?

I was thinking of this but dreading that users would forget to close()
and we'd just have floating chunks of memory that we cant spare. But
then I also thought of having a basic poor-mans-garbagecollector which
could count refs to each sdfile and delete it when no more Files are
pointing to it. not sure if that will make it into my version but it is
something that is easy to add in the backend and only costs a byte.


limor

> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>> hey gang!
>>
>> one of the side effects of having multiple files the way i have them now
>> seems to be that if you want to be able to have stuff like:
>>
>> File a = SD.open("/foo.txt");
>> File b = SD.open("/bar.txt");
>>
>> e.g. multiple files opened, that are passed by value so you can return them
>> from open() - less memory annoyance
>>
>> but there is no underlying 'static' object that is consistent. which is
>> great because you can return by value. but object data like "location in
>> file" is copied between function calls, and isn't changed globally.
>>
>> for example!
>>
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(File x) {
>> return x.read();
>> }
>>
>> main() {
>> print(reader(f));
>> print(reader(f));
>> }
>>
>> ----------
>>>>>> will print out "aa" (incorrect)
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(void) {
>> return f.read();
>> }
>>
>> main() {
>> print(reader());
>> print(reader());
>> }
>> ----------
>>>>>> will print out "ab" (correct)
>> this is because the state is stored globally and is not copied
>>
>> i -think- the only way to make it so you can pass the files around without
>> this is to have them be references to global file objects that are on the
>> heap (not stack like these). which seems like a pain.
>>
>> here's where i'd like your assistance:
>> 1) am i missing an easy way to fix this issue?
>>
>> 2)i think i want to avoid using new() since that means after you open() a
>> file, you'll have to close() and delete() and arduino doesnt really use
>> delete() so much and people will forget.
>>
>> 3) or i could make people pass pointers to File's instead of Files which is
>> probably OK but a little nonideal since pointers are a mystery. i suppose
>> there's no conflict with existing code since no existing code passes around
>> the file object since there's only one.
>>
>> anyways, useful suggestions welcome now before i make a decision!
>>
>> thanks as always,
>> limor
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
You're right that people will probably forget to close files. On the
other hand, it should be pretty easy for them to fix the problem if
someone asks them if they remembered to close their files. I wouldn't
worry about reference counting for an initial implementation. As you
say, we could add it later, although it won't really work with global
variables, which tend to be pretty common in Arduino sketches.

On Sat, Feb 26, 2011 at 12:42 PM, Limor <> wrote:
>
>
> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>
>> One of my priorities for the Arduino language is to minimize the
>> amount of syntax people need to learn, so I'd like to avoid requiring
>> them to use pointer or reference notation.
>>
>> My suggestion is to make File a wrapper for a pointer to an SdFile
>> object that was allocated on the heap.  With something like a file,
>> we're going to want people to explicitly call close anyway, so we
>> should be able to deallocate the memory there, too.  People already
>> need to check if opening the file succeeded, so the fact that it could
>> fail from a lack of memory doesn't impose the need for significant
>> additional error checking.
>>
>> Another possibility that avoids new syntax is having some set number
>> of statically allocated file objects.  But this seems unnecessary
>> wasteful if people don't need them, and limiting if they need more.
>> Because in this case the additional user requirements for handling
>> dynamic allocation are minimal, I'd prefer that approach.
>>
>> What do you think?
>
> I was thinking of this but dreading that users would forget to close() and
> we'd just have floating chunks of memory that we cant spare. But then I also
> thought of having a basic poor-mans-garbagecollector which could count refs
> to each sdfile and delete it when no more Files are pointing to it. not sure
> if that will make it into my version but it is something that is easy to add
> in the backend and only costs a byte.
>
>
>  limor
>
>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<>  wrote:
>>>
>>>  hey gang!
>>>
>>>  one of the side effects of having multiple files the way i have them now
>>>  seems to be that if you want to be able to have stuff like:
>>>
>>>  File a = SD.open("/foo.txt");
>>>  File b = SD.open("/bar.txt");
>>>
>>>  e.g. multiple files opened, that are passed by value so you can return
>>> them
>>>  from open() - less memory annoyance
>>>
>>>  but there is no underlying 'static' object that is consistent. which is
>>>  great because you can return by value. but object data like "location in
>>>  file" is copied between function calls, and isn't changed globally.
>>>
>>>  for example!
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(File x) {
>>>    return x.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader(f));
>>>   print(reader(f));
>>>  }
>>>
>>>  ----------
>>>>>>>
>>>>>>>  will print out "aa" (incorrect)
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(void) {
>>>    return f.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader());
>>>   print(reader());
>>>  }
>>>  ----------
>>>>>>>
>>>>>>>  will print out "ab" (correct)
>>>
>>>  this is because the state is stored globally and is not copied
>>>
>>>  i -think- the only way to make it so you can pass the files around
>>> without
>>>  this is to have them be references to global file objects that are on
>>> the
>>>  heap (not stack like these). which seems like a pain.
>>>
>>>  here's where i'd like your assistance:
>>>  1) am i missing an easy way to fix this issue?
>>>
>>>  2)i think i want to avoid using new() since that means after you open()
>>> a
>>>  file, you'll have to close() and delete() and arduino doesnt really use
>>>  delete() so much and people will forget.
>>>
>>>  3) or i could make people pass pointers to File's instead of Files which
>>> is
>>>  probably OK but a little nonideal since pointers are a mystery. i
>>> suppose
>>>  there's no conflict with existing code since no existing code passes
>>> around
>>>  the file object since there's only one.
>>>
>>>  anyways, useful suggestions welcome now before i make a decision!
>>>
>>>  thanks as always,
>>>  limor
>>>
>>>
>>>  _______________________________________________
>>>  Developers mailing list
>>>  
>>>  http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.

t.

On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:

> You're right that people will probably forget to close files. On the
> other hand, it should be pretty easy for them to fix the problem if
> someone asks them if they remembered to close their files. I wouldn't
> worry about reference counting for an initial implementation. As you
> say, we could add it later, although it won't really work with global
> variables, which tend to be pretty common in Arduino sketches.
>
> On Sat, Feb 26, 2011 at 12:42 PM, Limor <> wrote:
>>
>>
>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>
>>> One of my priorities for the Arduino language is to minimize the
>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>> them to use pointer or reference notation.
>>>
>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>> object that was allocated on the heap. With something like a file,
>>> we're going to want people to explicitly call close anyway, so we
>>> should be able to deallocate the memory there, too. People already
>>> need to check if opening the file succeeded, so the fact that it could
>>> fail from a lack of memory doesn't impose the need for significant
>>> additional error checking.
>>>
>>> Another possibility that avoids new syntax is having some set number
>>> of statically allocated file objects. But this seems unnecessary
>>> wasteful if people don't need them, and limiting if they need more.
>>> Because in this case the additional user requirements for handling
>>> dynamic allocation are minimal, I'd prefer that approach.
>>>
>>> What do you think?
>>
>> I was thinking of this but dreading that users would forget to close() and
>> we'd just have floating chunks of memory that we cant spare. But then I also
>> thought of having a basic poor-mans-garbagecollector which could count refs
>> to each sdfile and delete it when no more Files are pointing to it. not sure
>> if that will make it into my version but it is something that is easy to add
>> in the backend and only costs a byte.
>>
>>
>> limor
>>
>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>
>>>> hey gang!
>>>>
>>>> one of the side effects of having multiple files the way i have them now
>>>> seems to be that if you want to be able to have stuff like:
>>>>
>>>> File a = SD.open("/foo.txt");
>>>> File b = SD.open("/bar.txt");
>>>>
>>>> e.g. multiple files opened, that are passed by value so you can return
>>>> them
>>>> from open() - less memory annoyance
>>>>
>>>> but there is no underlying 'static' object that is consistent. which is
>>>> great because you can return by value. but object data like "location in
>>>> file" is copied between function calls, and isn't changed globally.
>>>>
>>>> for example!
>>>>
>>>> ----------
>>>> File f; // contains string "abc"
>>>>
>>>> int reader(File x) {
>>>> return x.read();
>>>> }
>>>>
>>>> main() {
>>>> print(reader(f));
>>>> print(reader(f));
>>>> }
>>>>
>>>> ----------
>>>>>>>>
>>>>>>>> will print out "aa" (incorrect)
>>>>
>>>> ----------
>>>> File f; // contains string "abc"
>>>>
>>>> int reader(void) {
>>>> return f.read();
>>>> }
>>>>
>>>> main() {
>>>> print(reader());
>>>> print(reader());
>>>> }
>>>> ----------
>>>>>>>>
>>>>>>>> will print out "ab" (correct)
>>>>
>>>> this is because the state is stored globally and is not copied
>>>>
>>>> i -think- the only way to make it so you can pass the files around
>>>> without
>>>> this is to have them be references to global file objects that are on
>>>> the
>>>> heap (not stack like these). which seems like a pain.
>>>>
>>>> here's where i'd like your assistance:
>>>> 1) am i missing an easy way to fix this issue?
>>>>
>>>> 2)i think i want to avoid using new() since that means after you open()
>>>> a
>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>> delete() so much and people will forget.
>>>>
>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>> is
>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>> suppose
>>>> there's no conflict with existing code since no existing code passes
>>>> around
>>>> the file object since there's only one.
>>>>
>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>
>>>> thanks as always,
>>>> limor
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)

hey gang!

one of the side effects of having multiple files the way i have them now
seems to be that if you want to be able to have stuff like:

File a = SD.open("/foo.txt");
File b = SD.open("/bar.txt");

e.g. multiple files opened, that are passed by value so you can return
them from open() - less memory annoyance

but there is no underlying 'static' object that is consistent. which is
great because you can return by value. but object data like "location in
file" is copied between function calls, and isn't changed globally.

for example!

----------
File f; // contains string "abc"

int reader(File x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

----------
>>>> will print out "aa" (incorrect)
----------
File f; // contains string "abc"

int reader(void) {
return f.read();
}

main() {
print(reader());
print(reader());
}
----------
>>>> will print out "ab" (correct)
this is because the state is stored globally and is not copied

i -think- the only way to make it so you can pass the files around
without this is to have them be references to global file objects that
are on the heap (not stack like these). which seems like a pain.

here's where i'd like your assistance:
1) am i missing an easy way to fix this issue?

2)i think i want to avoid using new() since that means after you open()
a file, you'll have to close() and delete() and arduino doesnt really
use delete() so much and people will forget.

3) or i could make people pass pointers to File's instead of Files which
is probably OK but a little nonideal since pointers are a mystery. i
suppose there's no conflict with existing code since no existing code
passes around the file object since there's only one.

anyways, useful suggestions welcome now before i make a decision!

thanks as always,
limor


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
Maybe I'm missing something obvious, but aren't pass-by-value /
pass-by-reference semantics handled on a per-function basis, depending
on the definition of the function?

So, for example, couldn't you do something like the following?

// pass x by reference
int reader(File& x) {
return x.read();
}

main() {
File f; // contains string "abc"
print(reader(f));
print(reader(f));
}

That maintains object (i.e., non-pointer) usage, and lets f's state
persist between function calls like that, as described here:
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference

Wouldn't that handle this situation? Or is there some constraint
preventing pass-by-reference usage?

Andrew


On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. Hi Limor,

I think most C++ folks would say that the standard way of building functions
like this that need to change the state of a passed-in parameter is to make
that parameters call-by-reference. Your code would look something like
this:

File f; // contains string "abc"

int reader(File &x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

Note the & in the parameter list. This says that x is a reference (read:
address) to a "File" object. X is no longer a copy of f, it's the *same*
object. For students coming from a C background, I explain that references
behave semantically like pointers, but are syntactically more similar to the
comfortable call-by-value. (No frightening dereference * operators!)

Note also that this style is also often superior performance-wise, because
call-by-value copies the entire class each time you call the function.

There should be no need for any heap allocation or static globals or
pointers or anything.

Best regards,

Mikal



> -----Original Message-----
> From: developers- [mailto:developers-
> ] On Behalf Of Limor
> Sent: Friday, February 25, 2011 7:03 PM
> To: Arduino Developer's List
> Subject: [Developers] sd/file pass-by-value not reference
>
> hey gang!
>
> one of the side effects of having multiple files the way i have them
> now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return
> them from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location
> in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
> return x.read();
> }
>
> main() {
> print(reader(f));
> print(reader(f));
> }
>
> ----------
> >>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
> return f.read();
> }
>
> main() {
> print(reader());
> print(reader());
> }
> ----------
> >>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around
> without this is to have them be references to global file objects that
> are on the heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open()
> a file, you'll have to close() and delete() and arduino doesnt really
> use delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files
> which
> is probably OK but a little nonideal since pointers are a mystery. i
> suppose there's no conflict with existing code since no existing code
> passes around the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
One of my priorities for the Arduino language is to minimize the
amount of syntax people need to learn, so I'd like to avoid requiring
them to use pointer or reference notation.

My suggestion is to make File a wrapper for a pointer to an SdFile
object that was allocated on the heap. With something like a file,
we're going to want people to explicitly call close anyway, so we
should be able to deallocate the memory there, too. People already
need to check if opening the file succeeded, so the fact that it could
fail from a lack of memory doesn't impose the need for significant
additional error checking.

Another possibility that avoids new syntax is having some set number
of statically allocated file objects. But this seems unnecessary
wasteful if people don't need them, and limiting if they need more.
Because in this case the additional user requirements for handling
dynamic allocation are minimal, I'd prefer that approach.

What do you think?

On Fri, Feb 25, 2011 at 8:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)


On 2/26/2011 11:14 AM, David A. Mellis wrote:
> One of my priorities for the Arduino language is to minimize the
> amount of syntax people need to learn, so I'd like to avoid requiring
> them to use pointer or reference notation.
>
> My suggestion is to make File a wrapper for a pointer to an SdFile
> object that was allocated on the heap. With something like a file,
> we're going to want people to explicitly call close anyway, so we
> should be able to deallocate the memory there, too. People already
> need to check if opening the file succeeded, so the fact that it could
> fail from a lack of memory doesn't impose the need for significant
> additional error checking.
>
> Another possibility that avoids new syntax is having some set number
> of statically allocated file objects. But this seems unnecessary
> wasteful if people don't need them, and limiting if they need more.
> Because in this case the additional user requirements for handling
> dynamic allocation are minimal, I'd prefer that approach.
>
> What do you think?

I was thinking of this but dreading that users would forget to close()
and we'd just have floating chunks of memory that we cant spare. But
then I also thought of having a basic poor-mans-garbagecollector which
could count refs to each sdfile and delete it when no more Files are
pointing to it. not sure if that will make it into my version but it is
something that is easy to add in the backend and only costs a byte.


limor

> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>> hey gang!
>>
>> one of the side effects of having multiple files the way i have them now
>> seems to be that if you want to be able to have stuff like:
>>
>> File a = SD.open("/foo.txt");
>> File b = SD.open("/bar.txt");
>>
>> e.g. multiple files opened, that are passed by value so you can return them
>> from open() - less memory annoyance
>>
>> but there is no underlying 'static' object that is consistent. which is
>> great because you can return by value. but object data like "location in
>> file" is copied between function calls, and isn't changed globally.
>>
>> for example!
>>
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(File x) {
>> return x.read();
>> }
>>
>> main() {
>> print(reader(f));
>> print(reader(f));
>> }
>>
>> ----------
>>>>>> will print out "aa" (incorrect)
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(void) {
>> return f.read();
>> }
>>
>> main() {
>> print(reader());
>> print(reader());
>> }
>> ----------
>>>>>> will print out "ab" (correct)
>> this is because the state is stored globally and is not copied
>>
>> i -think- the only way to make it so you can pass the files around without
>> this is to have them be references to global file objects that are on the
>> heap (not stack like these). which seems like a pain.
>>
>> here's where i'd like your assistance:
>> 1) am i missing an easy way to fix this issue?
>>
>> 2)i think i want to avoid using new() since that means after you open() a
>> file, you'll have to close() and delete() and arduino doesnt really use
>> delete() so much and people will forget.
>>
>> 3) or i could make people pass pointers to File's instead of Files which is
>> probably OK but a little nonideal since pointers are a mystery. i suppose
>> there's no conflict with existing code since no existing code passes around
>> the file object since there's only one.
>>
>> anyways, useful suggestions welcome now before i make a decision!
>>
>> thanks as always,
>> limor
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
You're right that people will probably forget to close files. On the
other hand, it should be pretty easy for them to fix the problem if
someone asks them if they remembered to close their files. I wouldn't
worry about reference counting for an initial implementation. As you
say, we could add it later, although it won't really work with global
variables, which tend to be pretty common in Arduino sketches.

On Sat, Feb 26, 2011 at 12:42 PM, Limor <> wrote:
>
>
> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>
>> One of my priorities for the Arduino language is to minimize the
>> amount of syntax people need to learn, so I'd like to avoid requiring
>> them to use pointer or reference notation.
>>
>> My suggestion is to make File a wrapper for a pointer to an SdFile
>> object that was allocated on the heap.  With something like a file,
>> we're going to want people to explicitly call close anyway, so we
>> should be able to deallocate the memory there, too.  People already
>> need to check if opening the file succeeded, so the fact that it could
>> fail from a lack of memory doesn't impose the need for significant
>> additional error checking.
>>
>> Another possibility that avoids new syntax is having some set number
>> of statically allocated file objects.  But this seems unnecessary
>> wasteful if people don't need them, and limiting if they need more.
>> Because in this case the additional user requirements for handling
>> dynamic allocation are minimal, I'd prefer that approach.
>>
>> What do you think?
>
> I was thinking of this but dreading that users would forget to close() and
> we'd just have floating chunks of memory that we cant spare. But then I also
> thought of having a basic poor-mans-garbagecollector which could count refs
> to each sdfile and delete it when no more Files are pointing to it. not sure
> if that will make it into my version but it is something that is easy to add
> in the backend and only costs a byte.
>
>
>  limor
>
>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<>  wrote:
>>>
>>>  hey gang!
>>>
>>>  one of the side effects of having multiple files the way i have them now
>>>  seems to be that if you want to be able to have stuff like:
>>>
>>>  File a = SD.open("/foo.txt");
>>>  File b = SD.open("/bar.txt");
>>>
>>>  e.g. multiple files opened, that are passed by value so you can return
>>> them
>>>  from open() - less memory annoyance
>>>
>>>  but there is no underlying 'static' object that is consistent. which is
>>>  great because you can return by value. but object data like "location in
>>>  file" is copied between function calls, and isn't changed globally.
>>>
>>>  for example!
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(File x) {
>>>    return x.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader(f));
>>>   print(reader(f));
>>>  }
>>>
>>>  ----------
>>>>>>>
>>>>>>>  will print out "aa" (incorrect)
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(void) {
>>>    return f.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader());
>>>   print(reader());
>>>  }
>>>  ----------
>>>>>>>
>>>>>>>  will print out "ab" (correct)
>>>
>>>  this is because the state is stored globally and is not copied
>>>
>>>  i -think- the only way to make it so you can pass the files around
>>> without
>>>  this is to have them be references to global file objects that are on
>>> the
>>>  heap (not stack like these). which seems like a pain.
>>>
>>>  here's where i'd like your assistance:
>>>  1) am i missing an easy way to fix this issue?
>>>
>>>  2)i think i want to avoid using new() since that means after you open()
>>> a
>>>  file, you'll have to close() and delete() and arduino doesnt really use
>>>  delete() so much and people will forget.
>>>
>>>  3) or i could make people pass pointers to File's instead of Files which
>>> is
>>>  probably OK but a little nonideal since pointers are a mystery. i
>>> suppose
>>>  there's no conflict with existing code since no existing code passes
>>> around
>>>  the file object since there's only one.
>>>
>>>  anyways, useful suggestions welcome now before i make a decision!
>>>
>>>  thanks as always,
>>>  limor
>>>
>>>
>>>  _______________________________________________
>>>  Developers mailing list
>>>  
>>>  http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.

t.

On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:

> You're right that people will probably forget to close files. On the
> other hand, it should be pretty easy for them to fix the problem if
> someone asks them if they remembered to close their files. I wouldn't
> worry about reference counting for an initial implementation. As you
> say, we could add it later, although it won't really work with global
> variables, which tend to be pretty common in Arduino sketches.
>
> On Sat, Feb 26, 2011 at 12:42 PM, Limor <> wrote:
>>
>>
>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>
>>> One of my priorities for the Arduino language is to minimize the
>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>> them to use pointer or reference notation.
>>>
>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>> object that was allocated on the heap. With something like a file,
>>> we're going to want people to explicitly call close anyway, so we
>>> should be able to deallocate the memory there, too. People already
>>> need to check if opening the file succeeded, so the fact that it could
>>> fail from a lack of memory doesn't impose the need for significant
>>> additional error checking.
>>>
>>> Another possibility that avoids new syntax is having some set number
>>> of statically allocated file objects. But this seems unnecessary
>>> wasteful if people don't need them, and limiting if they need more.
>>> Because in this case the additional user requirements for handling
>>> dynamic allocation are minimal, I'd prefer that approach.
>>>
>>> What do you think?
>>
>> I was thinking of this but dreading that users would forget to close() and
>> we'd just have floating chunks of memory that we cant spare. But then I also
>> thought of having a basic poor-mans-garbagecollector which could count refs
>> to each sdfile and delete it when no more Files are pointing to it. not sure
>> if that will make it into my version but it is something that is easy to add
>> in the backend and only costs a byte.
>>
>>
>> limor
>>
>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>
>>>> hey gang!
>>>>
>>>> one of the side effects of having multiple files the way i have them now
>>>> seems to be that if you want to be able to have stuff like:
>>>>
>>>> File a = SD.open("/foo.txt");
>>>> File b = SD.open("/bar.txt");
>>>>
>>>> e.g. multiple files opened, that are passed by value so you can return
>>>> them
>>>> from open() - less memory annoyance
>>>>
>>>> but there is no underlying 'static' object that is consistent. which is
>>>> great because you can return by value. but object data like "location in
>>>> file" is copied between function calls, and isn't changed globally.
>>>>
>>>> for example!
>>>>
>>>> ----------
>>>> File f; // contains string "abc"
>>>>
>>>> int reader(File x) {
>>>> return x.read();
>>>> }
>>>>
>>>> main() {
>>>> print(reader(f));
>>>> print(reader(f));
>>>> }
>>>>
>>>> ----------
>>>>>>>>
>>>>>>>> will print out "aa" (incorrect)
>>>>
>>>> ----------
>>>> File f; // contains string "abc"
>>>>
>>>> int reader(void) {
>>>> return f.read();
>>>> }
>>>>
>>>> main() {
>>>> print(reader());
>>>> print(reader());
>>>> }
>>>> ----------
>>>>>>>>
>>>>>>>> will print out "ab" (correct)
>>>>
>>>> this is because the state is stored globally and is not copied
>>>>
>>>> i -think- the only way to make it so you can pass the files around
>>>> without
>>>> this is to have them be references to global file objects that are on
>>>> the
>>>> heap (not stack like these). which seems like a pain.
>>>>
>>>> here's where i'd like your assistance:
>>>> 1) am i missing an easy way to fix this issue?
>>>>
>>>> 2)i think i want to avoid using new() since that means after you open()
>>>> a
>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>> delete() so much and people will forget.
>>>>
>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>> is
>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>> suppose
>>>> there's no conflict with existing code since no existing code passes
>>>> around
>>>> the file object since there's only one.
>>>>
>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>
>>>> thanks as always,
>>>> limor
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
OK. probably just close() after every open() that succeeds is good
enough. I will also have an example that shows directory traversal which
will allow me to port this library for use with my Ethernet Webserver
example which is what I set out to do about a month ago :D

limor

On 2/26/2011 1:15 PM, Tom Igoe wrote:
> W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.
>
> t.
>
> On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:
>
>> You're right that people will probably forget to close files. On the
>> other hand, it should be pretty easy for them to fix the problem if
>> someone asks them if they remembered to close their files. I wouldn't
>> worry about reference counting for an initial implementation. As you
>> say, we could add it later, although it won't really work with global
>> variables, which tend to be pretty common in Arduino sketches.
>>
>> On Sat, Feb 26, 2011 at 12:42 PM, Limor<> wrote:
>>>
>>>
>>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>>
>>>> One of my priorities for the Arduino language is to minimize the
>>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>>> them to use pointer or reference notation.
>>>>
>>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>>> object that was allocated on the heap. With something like a file,
>>>> we're going to want people to explicitly call close anyway, so we
>>>> should be able to deallocate the memory there, too. People already
>>>> need to check if opening the file succeeded, so the fact that it could
>>>> fail from a lack of memory doesn't impose the need for significant
>>>> additional error checking.
>>>>
>>>> Another possibility that avoids new syntax is having some set number
>>>> of statically allocated file objects. But this seems unnecessary
>>>> wasteful if people don't need them, and limiting if they need more.
>>>> Because in this case the additional user requirements for handling
>>>> dynamic allocation are minimal, I'd prefer that approach.
>>>>
>>>> What do you think?
>>>
>>> I was thinking of this but dreading that users would forget to close() and
>>> we'd just have floating chunks of memory that we cant spare. But then I also
>>> thought of having a basic poor-mans-garbagecollector which could count refs
>>> to each sdfile and delete it when no more Files are pointing to it. not sure
>>> if that will make it into my version but it is something that is easy to add
>>> in the backend and only costs a byte.
>>>
>>>
>>> limor
>>>
>>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>>
>>>>> hey gang!
>>>>>
>>>>> one of the side effects of having multiple files the way i have them now
>>>>> seems to be that if you want to be able to have stuff like:
>>>>>
>>>>> File a = SD.open("/foo.txt");
>>>>> File b = SD.open("/bar.txt");
>>>>>
>>>>> e.g. multiple files opened, that are passed by value so you can return
>>>>> them
>>>>> from open() - less memory annoyance
>>>>>
>>>>> but there is no underlying 'static' object that is consistent. which is
>>>>> great because you can return by value. but object data like "location in
>>>>> file" is copied between function calls, and isn't changed globally.
>>>>>
>>>>> for example!
>>>>>
>>>>> ----------
>>>>> File f; // contains string "abc"
>>>>>
>>>>> int reader(File x) {
>>>>> return x.read();
>>>>> }
>>>>>
>>>>> main() {
>>>>> print(reader(f));
>>>>> print(reader(f));
>>>>> }
>>>>>
>>>>> ----------
>>>>>>>>>
>>>>>>>>> will print out "aa" (incorrect)
>>>>>
>>>>> ----------
>>>>> File f; // contains string "abc"
>>>>>
>>>>> int reader(void) {
>>>>> return f.read();
>>>>> }
>>>>>
>>>>> main() {
>>>>> print(reader());
>>>>> print(reader());
>>>>> }
>>>>> ----------
>>>>>>>>>
>>>>>>>>> will print out "ab" (correct)
>>>>>
>>>>> this is because the state is stored globally and is not copied
>>>>>
>>>>> i -think- the only way to make it so you can pass the files around
>>>>> without
>>>>> this is to have them be references to global file objects that are on
>>>>> the
>>>>> heap (not stack like these). which seems like a pain.
>>>>>
>>>>> here's where i'd like your assistance:
>>>>> 1) am i missing an easy way to fix this issue?
>>>>>
>>>>> 2)i think i want to avoid using new() since that means after you open()
>>>>> a
>>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>>> delete() so much and people will forget.
>>>>>
>>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>>> is
>>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>>> suppose
>>>>> there's no conflict with existing code since no existing code passes
>>>>> around
>>>>> the file object since there's only one.
>>>>>
>>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>>
>>>>> thanks as always,
>>>>> limor
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)

hey gang!

one of the side effects of having multiple files the way i have them now
seems to be that if you want to be able to have stuff like:

File a = SD.open("/foo.txt");
File b = SD.open("/bar.txt");

e.g. multiple files opened, that are passed by value so you can return
them from open() - less memory annoyance

but there is no underlying 'static' object that is consistent. which is
great because you can return by value. but object data like "location in
file" is copied between function calls, and isn't changed globally.

for example!

----------
File f; // contains string "abc"

int reader(File x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

----------
>>>> will print out "aa" (incorrect)
----------
File f; // contains string "abc"

int reader(void) {
return f.read();
}

main() {
print(reader());
print(reader());
}
----------
>>>> will print out "ab" (correct)
this is because the state is stored globally and is not copied

i -think- the only way to make it so you can pass the files around
without this is to have them be references to global file objects that
are on the heap (not stack like these). which seems like a pain.

here's where i'd like your assistance:
1) am i missing an easy way to fix this issue?

2)i think i want to avoid using new() since that means after you open()
a file, you'll have to close() and delete() and arduino doesnt really
use delete() so much and people will forget.

3) or i could make people pass pointers to File's instead of Files which
is probably OK but a little nonideal since pointers are a mystery. i
suppose there's no conflict with existing code since no existing code
passes around the file object since there's only one.

anyways, useful suggestions welcome now before i make a decision!

thanks as always,
limor


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
Maybe I'm missing something obvious, but aren't pass-by-value /
pass-by-reference semantics handled on a per-function basis, depending
on the definition of the function?

So, for example, couldn't you do something like the following?

// pass x by reference
int reader(File& x) {
return x.read();
}

main() {
File f; // contains string "abc"
print(reader(f));
print(reader(f));
}

That maintains object (i.e., non-pointer) usage, and lets f's state
persist between function calls like that, as described here:
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference

Wouldn't that handle this situation? Or is there some constraint
preventing pass-by-reference usage?

Andrew


On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. Hi Limor,

I think most C++ folks would say that the standard way of building functions
like this that need to change the state of a passed-in parameter is to make
that parameters call-by-reference. Your code would look something like
this:

File f; // contains string "abc"

int reader(File &x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

Note the & in the parameter list. This says that x is a reference (read:
address) to a "File" object. X is no longer a copy of f, it's the *same*
object. For students coming from a C background, I explain that references
behave semantically like pointers, but are syntactically more similar to the
comfortable call-by-value. (No frightening dereference * operators!)

Note also that this style is also often superior performance-wise, because
call-by-value copies the entire class each time you call the function.

There should be no need for any heap allocation or static globals or
pointers or anything.

Best regards,

Mikal



> -----Original Message-----
> From: developers- [mailto:developers-
> ] On Behalf Of Limor
> Sent: Friday, February 25, 2011 7:03 PM
> To: Arduino Developer's List
> Subject: [Developers] sd/file pass-by-value not reference
>
> hey gang!
>
> one of the side effects of having multiple files the way i have them
> now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return
> them from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location
> in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
> return x.read();
> }
>
> main() {
> print(reader(f));
> print(reader(f));
> }
>
> ----------
> >>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
> return f.read();
> }
>
> main() {
> print(reader());
> print(reader());
> }
> ----------
> >>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around
> without this is to have them be references to global file objects that
> are on the heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open()
> a file, you'll have to close() and delete() and arduino doesnt really
> use delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files
> which
> is probably OK but a little nonideal since pointers are a mystery. i
> suppose there's no conflict with existing code since no existing code
> passes around the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
One of my priorities for the Arduino language is to minimize the
amount of syntax people need to learn, so I'd like to avoid requiring
them to use pointer or reference notation.

My suggestion is to make File a wrapper for a pointer to an SdFile
object that was allocated on the heap. With something like a file,
we're going to want people to explicitly call close anyway, so we
should be able to deallocate the memory there, too. People already
need to check if opening the file succeeded, so the fact that it could
fail from a lack of memory doesn't impose the need for significant
additional error checking.

Another possibility that avoids new syntax is having some set number
of statically allocated file objects. But this seems unnecessary
wasteful if people don't need them, and limiting if they need more.
Because in this case the additional user requirements for handling
dynamic allocation are minimal, I'd prefer that approach.

What do you think?

On Fri, Feb 25, 2011 at 8:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)


On 2/26/2011 11:14 AM, David A. Mellis wrote:
> One of my priorities for the Arduino language is to minimize the
> amount of syntax people need to learn, so I'd like to avoid requiring
> them to use pointer or reference notation.
>
> My suggestion is to make File a wrapper for a pointer to an SdFile
> object that was allocated on the heap. With something like a file,
> we're going to want people to explicitly call close anyway, so we
> should be able to deallocate the memory there, too. People already
> need to check if opening the file succeeded, so the fact that it could
> fail from a lack of memory doesn't impose the need for significant
> additional error checking.
>
> Another possibility that avoids new syntax is having some set number
> of statically allocated file objects. But this seems unnecessary
> wasteful if people don't need them, and limiting if they need more.
> Because in this case the additional user requirements for handling
> dynamic allocation are minimal, I'd prefer that approach.
>
> What do you think?

I was thinking of this but dreading that users would forget to close()
and we'd just have floating chunks of memory that we cant spare. But
then I also thought of having a basic poor-mans-garbagecollector which
could count refs to each sdfile and delete it when no more Files are
pointing to it. not sure if that will make it into my version but it is
something that is easy to add in the backend and only costs a byte.


limor

> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>> hey gang!
>>
>> one of the side effects of having multiple files the way i have them now
>> seems to be that if you want to be able to have stuff like:
>>
>> File a = SD.open("/foo.txt");
>> File b = SD.open("/bar.txt");
>>
>> e.g. multiple files opened, that are passed by value so you can return them
>> from open() - less memory annoyance
>>
>> but there is no underlying 'static' object that is consistent. which is
>> great because you can return by value. but object data like "location in
>> file" is copied between function calls, and isn't changed globally.
>>
>> for example!
>>
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(File x) {
>> return x.read();
>> }
>>
>> main() {
>> print(reader(f));
>> print(reader(f));
>> }
>>
>> ----------
>>>>>> will print out "aa" (incorrect)
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(void) {
>> return f.read();
>> }
>>
>> main() {
>> print(reader());
>> print(reader());
>> }
>> ----------
>>>>>> will print out "ab" (correct)
>> this is because the state is stored globally and is not copied
>>
>> i -think- the only way to make it so you can pass the files around without
>> this is to have them be references to global file objects that are on the
>> heap (not stack like these). which seems like a pain.
>>
>> here's where i'd like your assistance:
>> 1) am i missing an easy way to fix this issue?
>>
>> 2)i think i want to avoid using new() since that means after you open() a
>> file, you'll have to close() and delete() and arduino doesnt really use
>> delete() so much and people will forget.
>>
>> 3) or i could make people pass pointers to File's instead of Files which is
>> probably OK but a little nonideal since pointers are a mystery. i suppose
>> there's no conflict with existing code since no existing code passes around
>> the file object since there's only one.
>>
>> anyways, useful suggestions welcome now before i make a decision!
>>
>> thanks as always,
>> limor
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
You're right that people will probably forget to close files. On the
other hand, it should be pretty easy for them to fix the problem if
someone asks them if they remembered to close their files. I wouldn't
worry about reference counting for an initial implementation. As you
say, we could add it later, although it won't really work with global
variables, which tend to be pretty common in Arduino sketches.

On Sat, Feb 26, 2011 at 12:42 PM, Limor <> wrote:
>
>
> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>
>> One of my priorities for the Arduino language is to minimize the
>> amount of syntax people need to learn, so I'd like to avoid requiring
>> them to use pointer or reference notation.
>>
>> My suggestion is to make File a wrapper for a pointer to an SdFile
>> object that was allocated on the heap.  With something like a file,
>> we're going to want people to explicitly call close anyway, so we
>> should be able to deallocate the memory there, too.  People already
>> need to check if opening the file succeeded, so the fact that it could
>> fail from a lack of memory doesn't impose the need for significant
>> additional error checking.
>>
>> Another possibility that avoids new syntax is having some set number
>> of statically allocated file objects.  But this seems unnecessary
>> wasteful if people don't need them, and limiting if they need more.
>> Because in this case the additional user requirements for handling
>> dynamic allocation are minimal, I'd prefer that approach.
>>
>> What do you think?
>
> I was thinking of this but dreading that users would forget to close() and
> we'd just have floating chunks of memory that we cant spare. But then I also
> thought of having a basic poor-mans-garbagecollector which could count refs
> to each sdfile and delete it when no more Files are pointing to it. not sure
> if that will make it into my version but it is something that is easy to add
> in the backend and only costs a byte.
>
>
>  limor
>
>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<>  wrote:
>>>
>>>  hey gang!
>>>
>>>  one of the side effects of having multiple files the way i have them now
>>>  seems to be that if you want to be able to have stuff like:
>>>
>>>  File a = SD.open("/foo.txt");
>>>  File b = SD.open("/bar.txt");
>>>
>>>  e.g. multiple files opened, that are passed by value so you can return
>>> them
>>>  from open() - less memory annoyance
>>>
>>>  but there is no underlying 'static' object that is consistent. which is
>>>  great because you can return by value. but object data like "location in
>>>  file" is copied between function calls, and isn't changed globally.
>>>
>>>  for example!
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(File x) {
>>>    return x.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader(f));
>>>   print(reader(f));
>>>  }
>>>
>>>  ----------
>>>>>>>
>>>>>>>  will print out "aa" (incorrect)
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(void) {
>>>    return f.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader());
>>>   print(reader());
>>>  }
>>>  ----------
>>>>>>>
>>>>>>>  will print out "ab" (correct)
>>>
>>>  this is because the state is stored globally and is not copied
>>>
>>>  i -think- the only way to make it so you can pass the files around
>>> without
>>>  this is to have them be references to global file objects that are on
>>> the
>>>  heap (not stack like these). which seems like a pain.
>>>
>>>  here's where i'd like your assistance:
>>>  1) am i missing an easy way to fix this issue?
>>>
>>>  2)i think i want to avoid using new() since that means after you open()
>>> a
>>>  file, you'll have to close() and delete() and arduino doesnt really use
>>>  delete() so much and people will forget.
>>>
>>>  3) or i could make people pass pointers to File's instead of Files which
>>> is
>>>  probably OK but a little nonideal since pointers are a mystery. i
>>> suppose
>>>  there's no conflict with existing code since no existing code passes
>>> around
>>>  the file object since there's only one.
>>>
>>>  anyways, useful suggestions welcome now before i make a decision!
>>>
>>>  thanks as always,
>>>  limor
>>>
>>>
>>>  _______________________________________________
>>>  Developers mailing list
>>>  
>>>  http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.

t.

On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:

> You're right that people will probably forget to close files. On the
> other hand, it should be pretty easy for them to fix the problem if
> someone asks them if they remembered to close their files. I wouldn't
> worry about reference counting for an initial implementation. As you
> say, we could add it later, although it won't really work with global
> variables, which tend to be pretty common in Arduino sketches.
>
> On Sat, Feb 26, 2011 at 12:42 PM, Limor <> wrote:
>>
>>
>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>
>>> One of my priorities for the Arduino language is to minimize the
>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>> them to use pointer or reference notation.
>>>
>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>> object that was allocated on the heap. With something like a file,
>>> we're going to want people to explicitly call close anyway, so we
>>> should be able to deallocate the memory there, too. People already
>>> need to check if opening the file succeeded, so the fact that it could
>>> fail from a lack of memory doesn't impose the need for significant
>>> additional error checking.
>>>
>>> Another possibility that avoids new syntax is having some set number
>>> of statically allocated file objects. But this seems unnecessary
>>> wasteful if people don't need them, and limiting if they need more.
>>> Because in this case the additional user requirements for handling
>>> dynamic allocation are minimal, I'd prefer that approach.
>>>
>>> What do you think?
>>
>> I was thinking of this but dreading that users would forget to close() and
>> we'd just have floating chunks of memory that we cant spare. But then I also
>> thought of having a basic poor-mans-garbagecollector which could count refs
>> to each sdfile and delete it when no more Files are pointing to it. not sure
>> if that will make it into my version but it is something that is easy to add
>> in the backend and only costs a byte.
>>
>>
>> limor
>>
>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>
>>>> hey gang!
>>>>
>>>> one of the side effects of having multiple files the way i have them now
>>>> seems to be that if you want to be able to have stuff like:
>>>>
>>>> File a = SD.open("/foo.txt");
>>>> File b = SD.open("/bar.txt");
>>>>
>>>> e.g. multiple files opened, that are passed by value so you can return
>>>> them
>>>> from open() - less memory annoyance
>>>>
>>>> but there is no underlying 'static' object that is consistent. which is
>>>> great because you can return by value. but object data like "location in
>>>> file" is copied between function calls, and isn't changed globally.
>>>>
>>>> for example!
>>>>
>>>> ----------
>>>> File f; // contains string "abc"
>>>>
>>>> int reader(File x) {
>>>> return x.read();
>>>> }
>>>>
>>>> main() {
>>>> print(reader(f));
>>>> print(reader(f));
>>>> }
>>>>
>>>> ----------
>>>>>>>>
>>>>>>>> will print out "aa" (incorrect)
>>>>
>>>> ----------
>>>> File f; // contains string "abc"
>>>>
>>>> int reader(void) {
>>>> return f.read();
>>>> }
>>>>
>>>> main() {
>>>> print(reader());
>>>> print(reader());
>>>> }
>>>> ----------
>>>>>>>>
>>>>>>>> will print out "ab" (correct)
>>>>
>>>> this is because the state is stored globally and is not copied
>>>>
>>>> i -think- the only way to make it so you can pass the files around
>>>> without
>>>> this is to have them be references to global file objects that are on
>>>> the
>>>> heap (not stack like these). which seems like a pain.
>>>>
>>>> here's where i'd like your assistance:
>>>> 1) am i missing an easy way to fix this issue?
>>>>
>>>> 2)i think i want to avoid using new() since that means after you open()
>>>> a
>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>> delete() so much and people will forget.
>>>>
>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>> is
>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>> suppose
>>>> there's no conflict with existing code since no existing code passes
>>>> around
>>>> the file object since there's only one.
>>>>
>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>
>>>> thanks as always,
>>>> limor
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
OK. probably just close() after every open() that succeeds is good
enough. I will also have an example that shows directory traversal which
will allow me to port this library for use with my Ethernet Webserver
example which is what I set out to do about a month ago :D

limor

On 2/26/2011 1:15 PM, Tom Igoe wrote:
> W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.
>
> t.
>
> On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:
>
>> You're right that people will probably forget to close files. On the
>> other hand, it should be pretty easy for them to fix the problem if
>> someone asks them if they remembered to close their files. I wouldn't
>> worry about reference counting for an initial implementation. As you
>> say, we could add it later, although it won't really work with global
>> variables, which tend to be pretty common in Arduino sketches.
>>
>> On Sat, Feb 26, 2011 at 12:42 PM, Limor<> wrote:
>>>
>>>
>>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>>
>>>> One of my priorities for the Arduino language is to minimize the
>>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>>> them to use pointer or reference notation.
>>>>
>>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>>> object that was allocated on the heap. With something like a file,
>>>> we're going to want people to explicitly call close anyway, so we
>>>> should be able to deallocate the memory there, too. People already
>>>> need to check if opening the file succeeded, so the fact that it could
>>>> fail from a lack of memory doesn't impose the need for significant
>>>> additional error checking.
>>>>
>>>> Another possibility that avoids new syntax is having some set number
>>>> of statically allocated file objects. But this seems unnecessary
>>>> wasteful if people don't need them, and limiting if they need more.
>>>> Because in this case the additional user requirements for handling
>>>> dynamic allocation are minimal, I'd prefer that approach.
>>>>
>>>> What do you think?
>>>
>>> I was thinking of this but dreading that users would forget to close() and
>>> we'd just have floating chunks of memory that we cant spare. But then I also
>>> thought of having a basic poor-mans-garbagecollector which could count refs
>>> to each sdfile and delete it when no more Files are pointing to it. not sure
>>> if that will make it into my version but it is something that is easy to add
>>> in the backend and only costs a byte.
>>>
>>>
>>> limor
>>>
>>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>>
>>>>> hey gang!
>>>>>
>>>>> one of the side effects of having multiple files the way i have them now
>>>>> seems to be that if you want to be able to have stuff like:
>>>>>
>>>>> File a = SD.open("/foo.txt");
>>>>> File b = SD.open("/bar.txt");
>>>>>
>>>>> e.g. multiple files opened, that are passed by value so you can return
>>>>> them
>>>>> from open() - less memory annoyance
>>>>>
>>>>> but there is no underlying 'static' object that is consistent. which is
>>>>> great because you can return by value. but object data like "location in
>>>>> file" is copied between function calls, and isn't changed globally.
>>>>>
>>>>> for example!
>>>>>
>>>>> ----------
>>>>> File f; // contains string "abc"
>>>>>
>>>>> int reader(File x) {
>>>>> return x.read();
>>>>> }
>>>>>
>>>>> main() {
>>>>> print(reader(f));
>>>>> print(reader(f));
>>>>> }
>>>>>
>>>>> ----------
>>>>>>>>>
>>>>>>>>> will print out "aa" (incorrect)
>>>>>
>>>>> ----------
>>>>> File f; // contains string "abc"
>>>>>
>>>>> int reader(void) {
>>>>> return f.read();
>>>>> }
>>>>>
>>>>> main() {
>>>>> print(reader());
>>>>> print(reader());
>>>>> }
>>>>> ----------
>>>>>>>>>
>>>>>>>>> will print out "ab" (correct)
>>>>>
>>>>> this is because the state is stored globally and is not copied
>>>>>
>>>>> i -think- the only way to make it so you can pass the files around
>>>>> without
>>>>> this is to have them be references to global file objects that are on
>>>>> the
>>>>> heap (not stack like these). which seems like a pain.
>>>>>
>>>>> here's where i'd like your assistance:
>>>>> 1) am i missing an easy way to fix this issue?
>>>>>
>>>>> 2)i think i want to avoid using new() since that means after you open()
>>>>> a
>>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>>> delete() so much and people will forget.
>>>>>
>>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>>> is
>>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>>> suppose
>>>>> there's no conflict with existing code since no existing code passes
>>>>> around
>>>>> the file object since there's only one.
>>>>>
>>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>>
>>>>> thanks as always,
>>>>> limor
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
I have an ethernet webserver example that reads from SD, happy to pass it to you if it'd speed you along.

t.


On Feb 26, 2011, at 1:20 PM, Limor wrote:

> OK. probably just close() after every open() that succeeds is good enough. I will also have an example that shows directory traversal which will allow me to port this library for use with my Ethernet Webserver example which is what I set out to do about a month ago :D
>
> limor
>
> On 2/26/2011 1:15 PM, Tom Igoe wrote:
>> W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.
>>
>> t.
>>
>> On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:
>>
>>> You're right that people will probably forget to close files. On the
>>> other hand, it should be pretty easy for them to fix the problem if
>>> someone asks them if they remembered to close their files. I wouldn't
>>> worry about reference counting for an initial implementation. As you
>>> say, we could add it later, although it won't really work with global
>>> variables, which tend to be pretty common in Arduino sketches.
>>>
>>> On Sat, Feb 26, 2011 at 12:42 PM, Limor<> wrote:
>>>>
>>>>
>>>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>>>
>>>>> One of my priorities for the Arduino language is to minimize the
>>>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>>>> them to use pointer or reference notation.
>>>>>
>>>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>>>> object that was allocated on the heap. With something like a file,
>>>>> we're going to want people to explicitly call close anyway, so we
>>>>> should be able to deallocate the memory there, too. People already
>>>>> need to check if opening the file succeeded, so the fact that it could
>>>>> fail from a lack of memory doesn't impose the need for significant
>>>>> additional error checking.
>>>>>
>>>>> Another possibility that avoids new syntax is having some set number
>>>>> of statically allocated file objects. But this seems unnecessary
>>>>> wasteful if people don't need them, and limiting if they need more.
>>>>> Because in this case the additional user requirements for handling
>>>>> dynamic allocation are minimal, I'd prefer that approach.
>>>>>
>>>>> What do you think?
>>>>
>>>> I was thinking of this but dreading that users would forget to close() and
>>>> we'd just have floating chunks of memory that we cant spare. But then I also
>>>> thought of having a basic poor-mans-garbagecollector which could count refs
>>>> to each sdfile and delete it when no more Files are pointing to it. not sure
>>>> if that will make it into my version but it is something that is easy to add
>>>> in the backend and only costs a byte.
>>>>
>>>>
>>>> limor
>>>>
>>>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>>>
>>>>>> hey gang!
>>>>>>
>>>>>> one of the side effects of having multiple files the way i have them now
>>>>>> seems to be that if you want to be able to have stuff like:
>>>>>>
>>>>>> File a = SD.open("/foo.txt");
>>>>>> File b = SD.open("/bar.txt");
>>>>>>
>>>>>> e.g. multiple files opened, that are passed by value so you can return
>>>>>> them
>>>>>> from open() - less memory annoyance
>>>>>>
>>>>>> but there is no underlying 'static' object that is consistent. which is
>>>>>> great because you can return by value. but object data like "location in
>>>>>> file" is copied between function calls, and isn't changed globally.
>>>>>>
>>>>>> for example!
>>>>>>
>>>>>> ----------
>>>>>> File f; // contains string "abc"
>>>>>>
>>>>>> int reader(File x) {
>>>>>> return x.read();
>>>>>> }
>>>>>>
>>>>>> main() {
>>>>>> print(reader(f));
>>>>>> print(reader(f));
>>>>>> }
>>>>>>
>>>>>> ----------
>>>>>>>>>>
>>>>>>>>>> will print out "aa" (incorrect)
>>>>>>
>>>>>> ----------
>>>>>> File f; // contains string "abc"
>>>>>>
>>>>>> int reader(void) {
>>>>>> return f.read();
>>>>>> }
>>>>>>
>>>>>> main() {
>>>>>> print(reader());
>>>>>> print(reader());
>>>>>> }
>>>>>> ----------
>>>>>>>>>>
>>>>>>>>>> will print out "ab" (correct)
>>>>>>
>>>>>> this is because the state is stored globally and is not copied
>>>>>>
>>>>>> i -think- the only way to make it so you can pass the files around
>>>>>> without
>>>>>> this is to have them be references to global file objects that are on
>>>>>> the
>>>>>> heap (not stack like these). which seems like a pain.
>>>>>>
>>>>>> here's where i'd like your assistance:
>>>>>> 1) am i missing an easy way to fix this issue?
>>>>>>
>>>>>> 2)i think i want to avoid using new() since that means after you open()
>>>>>> a
>>>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>>>> delete() so much and people will forget.
>>>>>>
>>>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>>>> is
>>>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>>>> suppose
>>>>>> there's no conflict with existing code since no existing code passes
>>>>>> around
>>>>>> the file object since there's only one.
>>>>>>
>>>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>>>
>>>>>> thanks as always,
>>>>>> limor
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)

hey gang!

one of the side effects of having multiple files the way i have them now
seems to be that if you want to be able to have stuff like:

File a = SD.open("/foo.txt");
File b = SD.open("/bar.txt");

e.g. multiple files opened, that are passed by value so you can return
them from open() - less memory annoyance

but there is no underlying 'static' object that is consistent. which is
great because you can return by value. but object data like "location in
file" is copied between function calls, and isn't changed globally.

for example!

----------
File f; // contains string "abc"

int reader(File x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

----------
>>>> will print out "aa" (incorrect)
----------
File f; // contains string "abc"

int reader(void) {
return f.read();
}

main() {
print(reader());
print(reader());
}
----------
>>>> will print out "ab" (correct)
this is because the state is stored globally and is not copied

i -think- the only way to make it so you can pass the files around
without this is to have them be references to global file objects that
are on the heap (not stack like these). which seems like a pain.

here's where i'd like your assistance:
1) am i missing an easy way to fix this issue?

2)i think i want to avoid using new() since that means after you open()
a file, you'll have to close() and delete() and arduino doesnt really
use delete() so much and people will forget.

3) or i could make people pass pointers to File's instead of Files which
is probably OK but a little nonideal since pointers are a mystery. i
suppose there's no conflict with existing code since no existing code
passes around the file object since there's only one.

anyways, useful suggestions welcome now before i make a decision!

thanks as always,
limor


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
Maybe I'm missing something obvious, but aren't pass-by-value /
pass-by-reference semantics handled on a per-function basis, depending
on the definition of the function?

So, for example, couldn't you do something like the following?

// pass x by reference
int reader(File& x) {
return x.read();
}

main() {
File f; // contains string "abc"
print(reader(f));
print(reader(f));
}

That maintains object (i.e., non-pointer) usage, and lets f's state
persist between function calls like that, as described here:
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference

Wouldn't that handle this situation? Or is there some constraint
preventing pass-by-reference usage?

Andrew


On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. Hi Limor,

I think most C++ folks would say that the standard way of building functions
like this that need to change the state of a passed-in parameter is to make
that parameters call-by-reference. Your code would look something like
this:

File f; // contains string "abc"

int reader(File &x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

Note the & in the parameter list. This says that x is a reference (read:
address) to a "File" object. X is no longer a copy of f, it's the *same*
object. For students coming from a C background, I explain that references
behave semantically like pointers, but are syntactically more similar to the
comfortable call-by-value. (No frightening dereference * operators!)

Note also that this style is also often superior performance-wise, because
call-by-value copies the entire class each time you call the function.

There should be no need for any heap allocation or static globals or
pointers or anything.

Best regards,

Mikal



> -----Original Message-----
> From: developers- [mailto:developers-
> ] On Behalf Of Limor
> Sent: Friday, February 25, 2011 7:03 PM
> To: Arduino Developer's List
> Subject: [Developers] sd/file pass-by-value not reference
>
> hey gang!
>
> one of the side effects of having multiple files the way i have them
> now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return
> them from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location
> in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
> return x.read();
> }
>
> main() {
> print(reader(f));
> print(reader(f));
> }
>
> ----------
> >>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
> return f.read();
> }
>
> main() {
> print(reader());
> print(reader());
> }
> ----------
> >>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around
> without this is to have them be references to global file objects that
> are on the heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open()
> a file, you'll have to close() and delete() and arduino doesnt really
> use delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files
> which
> is probably OK but a little nonideal since pointers are a mystery. i
> suppose there's no conflict with existing code since no existing code
> passes around the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
One of my priorities for the Arduino language is to minimize the
amount of syntax people need to learn, so I'd like to avoid requiring
them to use pointer or reference notation.

My suggestion is to make File a wrapper for a pointer to an SdFile
object that was allocated on the heap. With something like a file,
we're going to want people to explicitly call close anyway, so we
should be able to deallocate the memory there, too. People already
need to check if opening the file succeeded, so the fact that it could
fail from a lack of memory doesn't impose the need for significant
additional error checking.

Another possibility that avoids new syntax is having some set number
of statically allocated file objects. But this seems unnecessary
wasteful if people don't need them, and limiting if they need more.
Because in this case the additional user requirements for handling
dynamic allocation are minimal, I'd prefer that approach.

What do you think?

On Fri, Feb 25, 2011 at 8:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)


On 2/26/2011 11:14 AM, David A. Mellis wrote:
> One of my priorities for the Arduino language is to minimize the
> amount of syntax people need to learn, so I'd like to avoid requiring
> them to use pointer or reference notation.
>
> My suggestion is to make File a wrapper for a pointer to an SdFile
> object that was allocated on the heap. With something like a file,
> we're going to want people to explicitly call close anyway, so we
> should be able to deallocate the memory there, too. People already
> need to check if opening the file succeeded, so the fact that it could
> fail from a lack of memory doesn't impose the need for significant
> additional error checking.
>
> Another possibility that avoids new syntax is having some set number
> of statically allocated file objects. But this seems unnecessary
> wasteful if people don't need them, and limiting if they need more.
> Because in this case the additional user requirements for handling
> dynamic allocation are minimal, I'd prefer that approach.
>
> What do you think?

I was thinking of this but dreading that users would forget to close()
and we'd just have floating chunks of memory that we cant spare. But
then I also thought of having a basic poor-mans-garbagecollector which
could count refs to each sdfile and delete it when no more Files are
pointing to it. not sure if that will make it into my version but it is
something that is easy to add in the backend and only costs a byte.


limor

> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>> hey gang!
>>
>> one of the side effects of having multiple files the way i have them now
>> seems to be that if you want to be able to have stuff like:
>>
>> File a = SD.open("/foo.txt");
>> File b = SD.open("/bar.txt");
>>
>> e.g. multiple files opened, that are passed by value so you can return them
>> from open() - less memory annoyance
>>
>> but there is no underlying 'static' object that is consistent. which is
>> great because you can return by value. but object data like "location in
>> file" is copied between function calls, and isn't changed globally.
>>
>> for example!
>>
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(File x) {
>> return x.read();
>> }
>>
>> main() {
>> print(reader(f));
>> print(reader(f));
>> }
>>
>> ----------
>>>>>> will print out "aa" (incorrect)
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(void) {
>> return f.read();
>> }
>>
>> main() {
>> print(reader());
>> print(reader());
>> }
>> ----------
>>>>>> will print out "ab" (correct)
>> this is because the state is stored globally and is not copied
>>
>> i -think- the only way to make it so you can pass the files around without
>> this is to have them be references to global file objects that are on the
>> heap (not stack like these). which seems like a pain.
>>
>> here's where i'd like your assistance:
>> 1) am i missing an easy way to fix this issue?
>>
>> 2)i think i want to avoid using new() since that means after you open() a
>> file, you'll have to close() and delete() and arduino doesnt really use
>> delete() so much and people will forget.
>>
>> 3) or i could make people pass pointers to File's instead of Files which is
>> probably OK but a little nonideal since pointers are a mystery. i suppose
>> there's no conflict with existing code since no existing code passes around
>> the file object since there's only one.
>>
>> anyways, useful suggestions welcome now before i make a decision!
>>
>> thanks as always,
>> limor
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
You're right that people will probably forget to close files. On the
other hand, it should be pretty easy for them to fix the problem if
someone asks them if they remembered to close their files. I wouldn't
worry about reference counting for an initial implementation. As you
say, we could add it later, although it won't really work with global
variables, which tend to be pretty common in Arduino sketches.

On Sat, Feb 26, 2011 at 12:42 PM, Limor <> wrote:
>
>
> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>
>> One of my priorities for the Arduino language is to minimize the
>> amount of syntax people need to learn, so I'd like to avoid requiring
>> them to use pointer or reference notation.
>>
>> My suggestion is to make File a wrapper for a pointer to an SdFile
>> object that was allocated on the heap.  With something like a file,
>> we're going to want people to explicitly call close anyway, so we
>> should be able to deallocate the memory there, too.  People already
>> need to check if opening the file succeeded, so the fact that it could
>> fail from a lack of memory doesn't impose the need for significant
>> additional error checking.
>>
>> Another possibility that avoids new syntax is having some set number
>> of statically allocated file objects.  But this seems unnecessary
>> wasteful if people don't need them, and limiting if they need more.
>> Because in this case the additional user requirements for handling
>> dynamic allocation are minimal, I'd prefer that approach.
>>
>> What do you think?
>
> I was thinking of this but dreading that users would forget to close() and
> we'd just have floating chunks of memory that we cant spare. But then I also
> thought of having a basic poor-mans-garbagecollector which could count refs
> to each sdfile and delete it when no more Files are pointing to it. not sure
> if that will make it into my version but it is something that is easy to add
> in the backend and only costs a byte.
>
>
>  limor
>
>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<>  wrote:
>>>
>>>  hey gang!
>>>
>>>  one of the side effects of having multiple files the way i have them now
>>>  seems to be that if you want to be able to have stuff like:
>>>
>>>  File a = SD.open("/foo.txt");
>>>  File b = SD.open("/bar.txt");
>>>
>>>  e.g. multiple files opened, that are passed by value so you can return
>>> them
>>>  from open() - less memory annoyance
>>>
>>>  but there is no underlying 'static' object that is consistent. which is
>>>  great because you can return by value. but object data like "location in
>>>  file" is copied between function calls, and isn't changed globally.
>>>
>>>  for example!
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(File x) {
>>>    return x.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader(f));
>>>   print(reader(f));
>>>  }
>>>
>>>  ----------
>>>>>>>
>>>>>>>  will print out "aa" (incorrect)
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(void) {
>>>    return f.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader());
>>>   print(reader());
>>>  }
>>>  ----------
>>>>>>>
>>>>>>>  will print out "ab" (correct)
>>>
>>>  this is because the state is stored globally and is not copied
>>>
>>>  i -think- the only way to make it so you can pass the files around
>>> without
>>>  this is to have them be references to global file objects that are on
>>> the
>>>  heap (not stack like these). which seems like a pain.
>>>
>>>  here's where i'd like your assistance:
>>>  1) am i missing an easy way to fix this issue?
>>>
>>>  2)i think i want to avoid using new() since that means after you open()
>>> a
>>>  file, you'll have to close() and delete() and arduino doesnt really use
>>>  delete() so much and people will forget.
>>>
>>>  3) or i could make people pass pointers to File's instead of Files which
>>> is
>>>  probably OK but a little nonideal since pointers are a mystery. i
>>> suppose
>>>  there's no conflict with existing code since no existing code passes
>>> around
>>>  the file object since there's only one.
>>>
>>>  anyways, useful suggestions welcome now before i make a decision!
>>>
>>>  thanks as always,
>>>  limor
>>>
>>>
>>>  _______________________________________________
>>>  Developers mailing list
>>>  
>>>  http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.

t.

On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:

> You're right that people will probably forget to close files. On the
> other hand, it should be pretty easy for them to fix the problem if
> someone asks them if they remembered to close their files. I wouldn't
> worry about reference counting for an initial implementation. As you
> say, we could add it later, although it won't really work with global
> variables, which tend to be pretty common in Arduino sketches.
>
> On Sat, Feb 26, 2011 at 12:42 PM, Limor <> wrote:
>>
>>
>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>
>>> One of my priorities for the Arduino language is to minimize the
>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>> them to use pointer or reference notation.
>>>
>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>> object that was allocated on the heap. With something like a file,
>>> we're going to want people to explicitly call close anyway, so we
>>> should be able to deallocate the memory there, too. People already
>>> need to check if opening the file succeeded, so the fact that it could
>>> fail from a lack of memory doesn't impose the need for significant
>>> additional error checking.
>>>
>>> Another possibility that avoids new syntax is having some set number
>>> of statically allocated file objects. But this seems unnecessary
>>> wasteful if people don't need them, and limiting if they need more.
>>> Because in this case the additional user requirements for handling
>>> dynamic allocation are minimal, I'd prefer that approach.
>>>
>>> What do you think?
>>
>> I was thinking of this but dreading that users would forget to close() and
>> we'd just have floating chunks of memory that we cant spare. But then I also
>> thought of having a basic poor-mans-garbagecollector which could count refs
>> to each sdfile and delete it when no more Files are pointing to it. not sure
>> if that will make it into my version but it is something that is easy to add
>> in the backend and only costs a byte.
>>
>>
>> limor
>>
>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>
>>>> hey gang!
>>>>
>>>> one of the side effects of having multiple files the way i have them now
>>>> seems to be that if you want to be able to have stuff like:
>>>>
>>>> File a = SD.open("/foo.txt");
>>>> File b = SD.open("/bar.txt");
>>>>
>>>> e.g. multiple files opened, that are passed by value so you can return
>>>> them
>>>> from open() - less memory annoyance
>>>>
>>>> but there is no underlying 'static' object that is consistent. which is
>>>> great because you can return by value. but object data like "location in
>>>> file" is copied between function calls, and isn't changed globally.
>>>>
>>>> for example!
>>>>
>>>> ----------
>>>> File f; // contains string "abc"
>>>>
>>>> int reader(File x) {
>>>> return x.read();
>>>> }
>>>>
>>>> main() {
>>>> print(reader(f));
>>>> print(reader(f));
>>>> }
>>>>
>>>> ----------
>>>>>>>>
>>>>>>>> will print out "aa" (incorrect)
>>>>
>>>> ----------
>>>> File f; // contains string "abc"
>>>>
>>>> int reader(void) {
>>>> return f.read();
>>>> }
>>>>
>>>> main() {
>>>> print(reader());
>>>> print(reader());
>>>> }
>>>> ----------
>>>>>>>>
>>>>>>>> will print out "ab" (correct)
>>>>
>>>> this is because the state is stored globally and is not copied
>>>>
>>>> i -think- the only way to make it so you can pass the files around
>>>> without
>>>> this is to have them be references to global file objects that are on
>>>> the
>>>> heap (not stack like these). which seems like a pain.
>>>>
>>>> here's where i'd like your assistance:
>>>> 1) am i missing an easy way to fix this issue?
>>>>
>>>> 2)i think i want to avoid using new() since that means after you open()
>>>> a
>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>> delete() so much and people will forget.
>>>>
>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>> is
>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>> suppose
>>>> there's no conflict with existing code since no existing code passes
>>>> around
>>>> the file object since there's only one.
>>>>
>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>
>>>> thanks as always,
>>>> limor
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
OK. probably just close() after every open() that succeeds is good
enough. I will also have an example that shows directory traversal which
will allow me to port this library for use with my Ethernet Webserver
example which is what I set out to do about a month ago :D

limor

On 2/26/2011 1:15 PM, Tom Igoe wrote:
> W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.
>
> t.
>
> On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:
>
>> You're right that people will probably forget to close files. On the
>> other hand, it should be pretty easy for them to fix the problem if
>> someone asks them if they remembered to close their files. I wouldn't
>> worry about reference counting for an initial implementation. As you
>> say, we could add it later, although it won't really work with global
>> variables, which tend to be pretty common in Arduino sketches.
>>
>> On Sat, Feb 26, 2011 at 12:42 PM, Limor<> wrote:
>>>
>>>
>>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>>
>>>> One of my priorities for the Arduino language is to minimize the
>>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>>> them to use pointer or reference notation.
>>>>
>>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>>> object that was allocated on the heap. With something like a file,
>>>> we're going to want people to explicitly call close anyway, so we
>>>> should be able to deallocate the memory there, too. People already
>>>> need to check if opening the file succeeded, so the fact that it could
>>>> fail from a lack of memory doesn't impose the need for significant
>>>> additional error checking.
>>>>
>>>> Another possibility that avoids new syntax is having some set number
>>>> of statically allocated file objects. But this seems unnecessary
>>>> wasteful if people don't need them, and limiting if they need more.
>>>> Because in this case the additional user requirements for handling
>>>> dynamic allocation are minimal, I'd prefer that approach.
>>>>
>>>> What do you think?
>>>
>>> I was thinking of this but dreading that users would forget to close() and
>>> we'd just have floating chunks of memory that we cant spare. But then I also
>>> thought of having a basic poor-mans-garbagecollector which could count refs
>>> to each sdfile and delete it when no more Files are pointing to it. not sure
>>> if that will make it into my version but it is something that is easy to add
>>> in the backend and only costs a byte.
>>>
>>>
>>> limor
>>>
>>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>>
>>>>> hey gang!
>>>>>
>>>>> one of the side effects of having multiple files the way i have them now
>>>>> seems to be that if you want to be able to have stuff like:
>>>>>
>>>>> File a = SD.open("/foo.txt");
>>>>> File b = SD.open("/bar.txt");
>>>>>
>>>>> e.g. multiple files opened, that are passed by value so you can return
>>>>> them
>>>>> from open() - less memory annoyance
>>>>>
>>>>> but there is no underlying 'static' object that is consistent. which is
>>>>> great because you can return by value. but object data like "location in
>>>>> file" is copied between function calls, and isn't changed globally.
>>>>>
>>>>> for example!
>>>>>
>>>>> ----------
>>>>> File f; // contains string "abc"
>>>>>
>>>>> int reader(File x) {
>>>>> return x.read();
>>>>> }
>>>>>
>>>>> main() {
>>>>> print(reader(f));
>>>>> print(reader(f));
>>>>> }
>>>>>
>>>>> ----------
>>>>>>>>>
>>>>>>>>> will print out "aa" (incorrect)
>>>>>
>>>>> ----------
>>>>> File f; // contains string "abc"
>>>>>
>>>>> int reader(void) {
>>>>> return f.read();
>>>>> }
>>>>>
>>>>> main() {
>>>>> print(reader());
>>>>> print(reader());
>>>>> }
>>>>> ----------
>>>>>>>>>
>>>>>>>>> will print out "ab" (correct)
>>>>>
>>>>> this is because the state is stored globally and is not copied
>>>>>
>>>>> i -think- the only way to make it so you can pass the files around
>>>>> without
>>>>> this is to have them be references to global file objects that are on
>>>>> the
>>>>> heap (not stack like these). which seems like a pain.
>>>>>
>>>>> here's where i'd like your assistance:
>>>>> 1) am i missing an easy way to fix this issue?
>>>>>
>>>>> 2)i think i want to avoid using new() since that means after you open()
>>>>> a
>>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>>> delete() so much and people will forget.
>>>>>
>>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>>> is
>>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>>> suppose
>>>>> there's no conflict with existing code since no existing code passes
>>>>> around
>>>>> the file object since there's only one.
>>>>>
>>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>>
>>>>> thanks as always,
>>>>> limor
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
I have an ethernet webserver example that reads from SD, happy to pass it to you if it'd speed you along.

t.


On Feb 26, 2011, at 1:20 PM, Limor wrote:

> OK. probably just close() after every open() that succeeds is good enough. I will also have an example that shows directory traversal which will allow me to port this library for use with my Ethernet Webserver example which is what I set out to do about a month ago :D
>
> limor
>
> On 2/26/2011 1:15 PM, Tom Igoe wrote:
>> W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.
>>
>> t.
>>
>> On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:
>>
>>> You're right that people will probably forget to close files. On the
>>> other hand, it should be pretty easy for them to fix the problem if
>>> someone asks them if they remembered to close their files. I wouldn't
>>> worry about reference counting for an initial implementation. As you
>>> say, we could add it later, although it won't really work with global
>>> variables, which tend to be pretty common in Arduino sketches.
>>>
>>> On Sat, Feb 26, 2011 at 12:42 PM, Limor<> wrote:
>>>>
>>>>
>>>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>>>
>>>>> One of my priorities for the Arduino language is to minimize the
>>>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>>>> them to use pointer or reference notation.
>>>>>
>>>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>>>> object that was allocated on the heap. With something like a file,
>>>>> we're going to want people to explicitly call close anyway, so we
>>>>> should be able to deallocate the memory there, too. People already
>>>>> need to check if opening the file succeeded, so the fact that it could
>>>>> fail from a lack of memory doesn't impose the need for significant
>>>>> additional error checking.
>>>>>
>>>>> Another possibility that avoids new syntax is having some set number
>>>>> of statically allocated file objects. But this seems unnecessary
>>>>> wasteful if people don't need them, and limiting if they need more.
>>>>> Because in this case the additional user requirements for handling
>>>>> dynamic allocation are minimal, I'd prefer that approach.
>>>>>
>>>>> What do you think?
>>>>
>>>> I was thinking of this but dreading that users would forget to close() and
>>>> we'd just have floating chunks of memory that we cant spare. But then I also
>>>> thought of having a basic poor-mans-garbagecollector which could count refs
>>>> to each sdfile and delete it when no more Files are pointing to it. not sure
>>>> if that will make it into my version but it is something that is easy to add
>>>> in the backend and only costs a byte.
>>>>
>>>>
>>>> limor
>>>>
>>>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>>>
>>>>>> hey gang!
>>>>>>
>>>>>> one of the side effects of having multiple files the way i have them now
>>>>>> seems to be that if you want to be able to have stuff like:
>>>>>>
>>>>>> File a = SD.open("/foo.txt");
>>>>>> File b = SD.open("/bar.txt");
>>>>>>
>>>>>> e.g. multiple files opened, that are passed by value so you can return
>>>>>> them
>>>>>> from open() - less memory annoyance
>>>>>>
>>>>>> but there is no underlying 'static' object that is consistent. which is
>>>>>> great because you can return by value. but object data like "location in
>>>>>> file" is copied between function calls, and isn't changed globally.
>>>>>>
>>>>>> for example!
>>>>>>
>>>>>> ----------
>>>>>> File f; // contains string "abc"
>>>>>>
>>>>>> int reader(File x) {
>>>>>> return x.read();
>>>>>> }
>>>>>>
>>>>>> main() {
>>>>>> print(reader(f));
>>>>>> print(reader(f));
>>>>>> }
>>>>>>
>>>>>> ----------
>>>>>>>>>>
>>>>>>>>>> will print out "aa" (incorrect)
>>>>>>
>>>>>> ----------
>>>>>> File f; // contains string "abc"
>>>>>>
>>>>>> int reader(void) {
>>>>>> return f.read();
>>>>>> }
>>>>>>
>>>>>> main() {
>>>>>> print(reader());
>>>>>> print(reader());
>>>>>> }
>>>>>> ----------
>>>>>>>>>>
>>>>>>>>>> will print out "ab" (correct)
>>>>>>
>>>>>> this is because the state is stored globally and is not copied
>>>>>>
>>>>>> i -think- the only way to make it so you can pass the files around
>>>>>> without
>>>>>> this is to have them be references to global file objects that are on
>>>>>> the
>>>>>> heap (not stack like these). which seems like a pain.
>>>>>>
>>>>>> here's where i'd like your assistance:
>>>>>> 1) am i missing an easy way to fix this issue?
>>>>>>
>>>>>> 2)i think i want to avoid using new() since that means after you open()
>>>>>> a
>>>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>>>> delete() so much and people will forget.
>>>>>>
>>>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>>>> is
>>>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>>>> suppose
>>>>>> there's no conflict with existing code since no existing code passes
>>>>>> around
>>>>>> the file object since there's only one.
>>>>>>
>>>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>>>
>>>>>> thanks as always,
>>>>>> limor
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
We don't pass by reference in Arduino-style sketches.

t.

On Feb 25, 2011, at 8:40 PM, A. Schamp wrote:

> Maybe I'm missing something obvious, but aren't pass-by-value /
> pass-by-reference semantics handled on a per-function basis, depending
> on the definition of the function?
>
> So, for example, couldn't you do something like the following?
>
> // pass x by reference
> int reader(File& x) {
> return x.read();
> }
>
> main() {
> File f; // contains string "abc"
> print(reader(f));
> print(reader(f));
> }
>
> That maintains object (i.e., non-pointer) usage, and lets f's state
> persist between function calls like that, as described here:
> http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference
>
> Wouldn't that handle this situation? Or is there some constraint
> preventing pass-by-reference usage?
>
> Andrew
>
>
> On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
>> hey gang!
>>
>> one of the side effects of having multiple files the way i have them now
>> seems to be that if you want to be able to have stuff like:
>>
>> File a = SD.open("/foo.txt");
>> File b = SD.open("/bar.txt");
>>
>> e.g. multiple files opened, that are passed by value so you can return them
>> from open() - less memory annoyance
>>
>> but there is no underlying 'static' object that is consistent. which is
>> great because you can return by value. but object data like "location in
>> file" is copied between function calls, and isn't changed globally.
>>
>> for example!
>>
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(File x) {
>> return x.read();
>> }
>>
>> main() {
>> print(reader(f));
>> print(reader(f));
>> }
>>
>> ----------
>>>>>> will print out "aa" (incorrect)
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(void) {
>> return f.read();
>> }
>>
>> main() {
>> print(reader());
>> print(reader());
>> }
>> ----------
>>>>>> will print out "ab" (correct)
>> this is because the state is stored globally and is not copied
>>
>> i -think- the only way to make it so you can pass the files around without
>> this is to have them be references to global file objects that are on the
>> heap (not stack like these). which seems like a pain.
>>
>> here's where i'd like your assistance:
>> 1) am i missing an easy way to fix this issue?
>>
>> 2)i think i want to avoid using new() since that means after you open() a
>> file, you'll have to close() and delete() and arduino doesnt really use
>> delete() so much and people will forget.
>>
>> 3) or i could make people pass pointers to File's instead of Files which is
>> probably OK but a little nonideal since pointers are a mystery. i suppose
>> there's no conflict with existing code since no existing code passes around
>> the file object since there's only one.
>>
>> anyways, useful suggestions welcome now before i make a decision!
>>
>> thanks as always,
>> limor
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.

hey gang!

one of the side effects of having multiple files the way i have them now
seems to be that if you want to be able to have stuff like:

File a = SD.open("/foo.txt");
File b = SD.open("/bar.txt");

e.g. multiple files opened, that are passed by value so you can return
them from open() - less memory annoyance

but there is no underlying 'static' object that is consistent. which is
great because you can return by value. but object data like "location in
file" is copied between function calls, and isn't changed globally.

for example!

----------
File f; // contains string "abc"

int reader(File x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

----------
>>>> will print out "aa" (incorrect)
----------
File f; // contains string "abc"

int reader(void) {
return f.read();
}

main() {
print(reader());
print(reader());
}
----------
>>>> will print out "ab" (correct)
this is because the state is stored globally and is not copied

i -think- the only way to make it so you can pass the files around
without this is to have them be references to global file objects that
are on the heap (not stack like these). which seems like a pain.

here's where i'd like your assistance:
1) am i missing an easy way to fix this issue?

2)i think i want to avoid using new() since that means after you open()
a file, you'll have to close() and delete() and arduino doesnt really
use delete() so much and people will forget.

3) or i could make people pass pointers to File's instead of Files which
is probably OK but a little nonideal since pointers are a mystery. i
suppose there's no conflict with existing code since no existing code
passes around the file object since there's only one.

anyways, useful suggestions welcome now before i make a decision!

thanks as always,
limor


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
Maybe I'm missing something obvious, but aren't pass-by-value /
pass-by-reference semantics handled on a per-function basis, depending
on the definition of the function?

So, for example, couldn't you do something like the following?

// pass x by reference
int reader(File& x) {
return x.read();
}

main() {
File f; // contains string "abc"
print(reader(f));
print(reader(f));
}

That maintains object (i.e., non-pointer) usage, and lets f's state
persist between function calls like that, as described here:
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference

Wouldn't that handle this situation? Or is there some constraint
preventing pass-by-reference usage?

Andrew


On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. Hi Limor,

I think most C++ folks would say that the standard way of building functions
like this that need to change the state of a passed-in parameter is to make
that parameters call-by-reference. Your code would look something like
this:

File f; // contains string "abc"

int reader(File &x) {
return x.read();
}

main() {
print(reader(f));
print(reader(f));
}

Note the & in the parameter list. This says that x is a reference (read:
address) to a "File" object. X is no longer a copy of f, it's the *same*
object. For students coming from a C background, I explain that references
behave semantically like pointers, but are syntactically more similar to the
comfortable call-by-value. (No frightening dereference * operators!)

Note also that this style is also often superior performance-wise, because
call-by-value copies the entire class each time you call the function.

There should be no need for any heap allocation or static globals or
pointers or anything.

Best regards,

Mikal



> -----Original Message-----
> From: developers- [mailto:developers-
> ] On Behalf Of Limor
> Sent: Friday, February 25, 2011 7:03 PM
> To: Arduino Developer's List
> Subject: [Developers] sd/file pass-by-value not reference
>
> hey gang!
>
> one of the side effects of having multiple files the way i have them
> now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return
> them from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location
> in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
> return x.read();
> }
>
> main() {
> print(reader(f));
> print(reader(f));
> }
>
> ----------
> >>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
> return f.read();
> }
>
> main() {
> print(reader());
> print(reader());
> }
> ----------
> >>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around
> without this is to have them be references to global file objects that
> are on the heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open()
> a file, you'll have to close() and delete() and arduino doesnt really
> use delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files
> which
> is probably OK but a little nonideal since pointers are a mystery. i
> suppose there's no conflict with existing code since no existing code
> passes around the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
One of my priorities for the Arduino language is to minimize the
amount of syntax people need to learn, so I'd like to avoid requiring
them to use pointer or reference notation.

My suggestion is to make File a wrapper for a pointer to an SdFile
object that was allocated on the heap. With something like a file,
we're going to want people to explicitly call close anyway, so we
should be able to deallocate the memory there, too. People already
need to check if opening the file succeeded, so the fact that it could
fail from a lack of memory doesn't impose the need for significant
additional error checking.

Another possibility that avoids new syntax is having some set number
of statically allocated file objects. But this seems unnecessary
wasteful if people don't need them, and limiting if they need more.
Because in this case the additional user requirements for handling
dynamic allocation are minimal, I'd prefer that approach.

What do you think?

On Fri, Feb 25, 2011 at 8:02 PM, Limor <> wrote:
> hey gang!
>
> one of the side effects of having multiple files the way i have them now
> seems to be that if you want to be able to have stuff like:
>
> File a = SD.open("/foo.txt");
> File b = SD.open("/bar.txt");
>
> e.g. multiple files opened, that are passed by value so you can return them
> from open() - less memory annoyance
>
> but there is no underlying 'static' object that is consistent. which is
> great because you can return by value. but object data like "location in
> file" is copied between function calls, and isn't changed globally.
>
> for example!
>
> ----------
> File f; // contains string "abc"
>
> int reader(File x) {
>   return x.read();
> }
>
> main() {
>  print(reader(f));
>  print(reader(f));
> }
>
> ----------
>>>>> will print out "aa" (incorrect)
> ----------
> File f; // contains string "abc"
>
> int reader(void) {
>   return f.read();
> }
>
> main() {
>  print(reader());
>  print(reader());
> }
> ----------
>>>>> will print out "ab" (correct)
> this is because the state is stored globally and is not copied
>
> i -think- the only way to make it so you can pass the files around without
> this is to have them be references to global file objects that are on the
> heap (not stack like these). which seems like a pain.
>
> here's where i'd like your assistance:
> 1) am i missing an easy way to fix this issue?
>
> 2)i think i want to avoid using new() since that means after you open() a
> file, you'll have to close() and delete() and arduino doesnt really use
> delete() so much and people will forget.
>
> 3) or i could make people pass pointers to File's instead of Files which is
> probably OK but a little nonideal since pointers are a mystery. i suppose
> there's no conflict with existing code since no existing code passes around
> the file object since there's only one.
>
> anyways, useful suggestions welcome now before i make a decision!
>
> thanks as always,
> limor
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)


On 2/26/2011 11:14 AM, David A. Mellis wrote:
> One of my priorities for the Arduino language is to minimize the
> amount of syntax people need to learn, so I'd like to avoid requiring
> them to use pointer or reference notation.
>
> My suggestion is to make File a wrapper for a pointer to an SdFile
> object that was allocated on the heap. With something like a file,
> we're going to want people to explicitly call close anyway, so we
> should be able to deallocate the memory there, too. People already
> need to check if opening the file succeeded, so the fact that it could
> fail from a lack of memory doesn't impose the need for significant
> additional error checking.
>
> Another possibility that avoids new syntax is having some set number
> of statically allocated file objects. But this seems unnecessary
> wasteful if people don't need them, and limiting if they need more.
> Because in this case the additional user requirements for handling
> dynamic allocation are minimal, I'd prefer that approach.
>
> What do you think?

I was thinking of this but dreading that users would forget to close()
and we'd just have floating chunks of memory that we cant spare. But
then I also thought of having a basic poor-mans-garbagecollector which
could count refs to each sdfile and delete it when no more Files are
pointing to it. not sure if that will make it into my version but it is
something that is easy to add in the backend and only costs a byte.


limor

> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>> hey gang!
>>
>> one of the side effects of having multiple files the way i have them now
>> seems to be that if you want to be able to have stuff like:
>>
>> File a = SD.open("/foo.txt");
>> File b = SD.open("/bar.txt");
>>
>> e.g. multiple files opened, that are passed by value so you can return them
>> from open() - less memory annoyance
>>
>> but there is no underlying 'static' object that is consistent. which is
>> great because you can return by value. but object data like "location in
>> file" is copied between function calls, and isn't changed globally.
>>
>> for example!
>>
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(File x) {
>> return x.read();
>> }
>>
>> main() {
>> print(reader(f));
>> print(reader(f));
>> }
>>
>> ----------
>>>>>> will print out "aa" (incorrect)
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(void) {
>> return f.read();
>> }
>>
>> main() {
>> print(reader());
>> print(reader());
>> }
>> ----------
>>>>>> will print out "ab" (correct)
>> this is because the state is stored globally and is not copied
>>
>> i -think- the only way to make it so you can pass the files around without
>> this is to have them be references to global file objects that are on the
>> heap (not stack like these). which seems like a pain.
>>
>> here's where i'd like your assistance:
>> 1) am i missing an easy way to fix this issue?
>>
>> 2)i think i want to avoid using new() since that means after you open() a
>> file, you'll have to close() and delete() and arduino doesnt really use
>> delete() so much and people will forget.
>>
>> 3) or i could make people pass pointers to File's instead of Files which is
>> probably OK but a little nonideal since pointers are a mystery. i suppose
>> there's no conflict with existing code since no existing code passes around
>> the file object since there's only one.
>>
>> anyways, useful suggestions welcome now before i make a decision!
>>
>> thanks as always,
>> limor
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
You're right that people will probably forget to close files. On the
other hand, it should be pretty easy for them to fix the problem if
someone asks them if they remembered to close their files. I wouldn't
worry about reference counting for an initial implementation. As you
say, we could add it later, although it won't really work with global
variables, which tend to be pretty common in Arduino sketches.

On Sat, Feb 26, 2011 at 12:42 PM, Limor <> wrote:
>
>
> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>
>> One of my priorities for the Arduino language is to minimize the
>> amount of syntax people need to learn, so I'd like to avoid requiring
>> them to use pointer or reference notation.
>>
>> My suggestion is to make File a wrapper for a pointer to an SdFile
>> object that was allocated on the heap.  With something like a file,
>> we're going to want people to explicitly call close anyway, so we
>> should be able to deallocate the memory there, too.  People already
>> need to check if opening the file succeeded, so the fact that it could
>> fail from a lack of memory doesn't impose the need for significant
>> additional error checking.
>>
>> Another possibility that avoids new syntax is having some set number
>> of statically allocated file objects.  But this seems unnecessary
>> wasteful if people don't need them, and limiting if they need more.
>> Because in this case the additional user requirements for handling
>> dynamic allocation are minimal, I'd prefer that approach.
>>
>> What do you think?
>
> I was thinking of this but dreading that users would forget to close() and
> we'd just have floating chunks of memory that we cant spare. But then I also
> thought of having a basic poor-mans-garbagecollector which could count refs
> to each sdfile and delete it when no more Files are pointing to it. not sure
> if that will make it into my version but it is something that is easy to add
> in the backend and only costs a byte.
>
>
>  limor
>
>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<>  wrote:
>>>
>>>  hey gang!
>>>
>>>  one of the side effects of having multiple files the way i have them now
>>>  seems to be that if you want to be able to have stuff like:
>>>
>>>  File a = SD.open("/foo.txt");
>>>  File b = SD.open("/bar.txt");
>>>
>>>  e.g. multiple files opened, that are passed by value so you can return
>>> them
>>>  from open() - less memory annoyance
>>>
>>>  but there is no underlying 'static' object that is consistent. which is
>>>  great because you can return by value. but object data like "location in
>>>  file" is copied between function calls, and isn't changed globally.
>>>
>>>  for example!
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(File x) {
>>>    return x.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader(f));
>>>   print(reader(f));
>>>  }
>>>
>>>  ----------
>>>>>>>
>>>>>>>  will print out "aa" (incorrect)
>>>
>>>  ----------
>>>  File f; // contains string "abc"
>>>
>>>  int reader(void) {
>>>    return f.read();
>>>  }
>>>
>>>  main() {
>>>   print(reader());
>>>   print(reader());
>>>  }
>>>  ----------
>>>>>>>
>>>>>>>  will print out "ab" (correct)
>>>
>>>  this is because the state is stored globally and is not copied
>>>
>>>  i -think- the only way to make it so you can pass the files around
>>> without
>>>  this is to have them be references to global file objects that are on
>>> the
>>>  heap (not stack like these). which seems like a pain.
>>>
>>>  here's where i'd like your assistance:
>>>  1) am i missing an easy way to fix this issue?
>>>
>>>  2)i think i want to avoid using new() since that means after you open()
>>> a
>>>  file, you'll have to close() and delete() and arduino doesnt really use
>>>  delete() so much and people will forget.
>>>
>>>  3) or i could make people pass pointers to File's instead of Files which
>>> is
>>>  probably OK but a little nonideal since pointers are a mystery. i
>>> suppose
>>>  there's no conflict with existing code since no existing code passes
>>> around
>>>  the file object since there's only one.
>>>
>>>  anyways, useful suggestions welcome now before i make a decision!
>>>
>>>  thanks as always,
>>>  limor
>>>
>>>
>>>  _______________________________________________
>>>  Developers mailing list
>>>  
>>>  http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.

t.

On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:

> You're right that people will probably forget to close files. On the
> other hand, it should be pretty easy for them to fix the problem if
> someone asks them if they remembered to close their files. I wouldn't
> worry about reference counting for an initial implementation. As you
> say, we could add it later, although it won't really work with global
> variables, which tend to be pretty common in Arduino sketches.
>
> On Sat, Feb 26, 2011 at 12:42 PM, Limor <> wrote:
>>
>>
>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>
>>> One of my priorities for the Arduino language is to minimize the
>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>> them to use pointer or reference notation.
>>>
>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>> object that was allocated on the heap. With something like a file,
>>> we're going to want people to explicitly call close anyway, so we
>>> should be able to deallocate the memory there, too. People already
>>> need to check if opening the file succeeded, so the fact that it could
>>> fail from a lack of memory doesn't impose the need for significant
>>> additional error checking.
>>>
>>> Another possibility that avoids new syntax is having some set number
>>> of statically allocated file objects. But this seems unnecessary
>>> wasteful if people don't need them, and limiting if they need more.
>>> Because in this case the additional user requirements for handling
>>> dynamic allocation are minimal, I'd prefer that approach.
>>>
>>> What do you think?
>>
>> I was thinking of this but dreading that users would forget to close() and
>> we'd just have floating chunks of memory that we cant spare. But then I also
>> thought of having a basic poor-mans-garbagecollector which could count refs
>> to each sdfile and delete it when no more Files are pointing to it. not sure
>> if that will make it into my version but it is something that is easy to add
>> in the backend and only costs a byte.
>>
>>
>> limor
>>
>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>
>>>> hey gang!
>>>>
>>>> one of the side effects of having multiple files the way i have them now
>>>> seems to be that if you want to be able to have stuff like:
>>>>
>>>> File a = SD.open("/foo.txt");
>>>> File b = SD.open("/bar.txt");
>>>>
>>>> e.g. multiple files opened, that are passed by value so you can return
>>>> them
>>>> from open() - less memory annoyance
>>>>
>>>> but there is no underlying 'static' object that is consistent. which is
>>>> great because you can return by value. but object data like "location in
>>>> file" is copied between function calls, and isn't changed globally.
>>>>
>>>> for example!
>>>>
>>>> ----------
>>>> File f; // contains string "abc"
>>>>
>>>> int reader(File x) {
>>>> return x.read();
>>>> }
>>>>
>>>> main() {
>>>> print(reader(f));
>>>> print(reader(f));
>>>> }
>>>>
>>>> ----------
>>>>>>>>
>>>>>>>> will print out "aa" (incorrect)
>>>>
>>>> ----------
>>>> File f; // contains string "abc"
>>>>
>>>> int reader(void) {
>>>> return f.read();
>>>> }
>>>>
>>>> main() {
>>>> print(reader());
>>>> print(reader());
>>>> }
>>>> ----------
>>>>>>>>
>>>>>>>> will print out "ab" (correct)
>>>>
>>>> this is because the state is stored globally and is not copied
>>>>
>>>> i -think- the only way to make it so you can pass the files around
>>>> without
>>>> this is to have them be references to global file objects that are on
>>>> the
>>>> heap (not stack like these). which seems like a pain.
>>>>
>>>> here's where i'd like your assistance:
>>>> 1) am i missing an easy way to fix this issue?
>>>>
>>>> 2)i think i want to avoid using new() since that means after you open()
>>>> a
>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>> delete() so much and people will forget.
>>>>
>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>> is
>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>> suppose
>>>> there's no conflict with existing code since no existing code passes
>>>> around
>>>> the file object since there's only one.
>>>>
>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>
>>>> thanks as always,
>>>> limor
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
OK. probably just close() after every open() that succeeds is good
enough. I will also have an example that shows directory traversal which
will allow me to port this library for use with my Ethernet Webserver
example which is what I set out to do about a month ago :D

limor

On 2/26/2011 1:15 PM, Tom Igoe wrote:
> W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.
>
> t.
>
> On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:
>
>> You're right that people will probably forget to close files. On the
>> other hand, it should be pretty easy for them to fix the problem if
>> someone asks them if they remembered to close their files. I wouldn't
>> worry about reference counting for an initial implementation. As you
>> say, we could add it later, although it won't really work with global
>> variables, which tend to be pretty common in Arduino sketches.
>>
>> On Sat, Feb 26, 2011 at 12:42 PM, Limor<> wrote:
>>>
>>>
>>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>>
>>>> One of my priorities for the Arduino language is to minimize the
>>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>>> them to use pointer or reference notation.
>>>>
>>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>>> object that was allocated on the heap. With something like a file,
>>>> we're going to want people to explicitly call close anyway, so we
>>>> should be able to deallocate the memory there, too. People already
>>>> need to check if opening the file succeeded, so the fact that it could
>>>> fail from a lack of memory doesn't impose the need for significant
>>>> additional error checking.
>>>>
>>>> Another possibility that avoids new syntax is having some set number
>>>> of statically allocated file objects. But this seems unnecessary
>>>> wasteful if people don't need them, and limiting if they need more.
>>>> Because in this case the additional user requirements for handling
>>>> dynamic allocation are minimal, I'd prefer that approach.
>>>>
>>>> What do you think?
>>>
>>> I was thinking of this but dreading that users would forget to close() and
>>> we'd just have floating chunks of memory that we cant spare. But then I also
>>> thought of having a basic poor-mans-garbagecollector which could count refs
>>> to each sdfile and delete it when no more Files are pointing to it. not sure
>>> if that will make it into my version but it is something that is easy to add
>>> in the backend and only costs a byte.
>>>
>>>
>>> limor
>>>
>>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>>
>>>>> hey gang!
>>>>>
>>>>> one of the side effects of having multiple files the way i have them now
>>>>> seems to be that if you want to be able to have stuff like:
>>>>>
>>>>> File a = SD.open("/foo.txt");
>>>>> File b = SD.open("/bar.txt");
>>>>>
>>>>> e.g. multiple files opened, that are passed by value so you can return
>>>>> them
>>>>> from open() - less memory annoyance
>>>>>
>>>>> but there is no underlying 'static' object that is consistent. which is
>>>>> great because you can return by value. but object data like "location in
>>>>> file" is copied between function calls, and isn't changed globally.
>>>>>
>>>>> for example!
>>>>>
>>>>> ----------
>>>>> File f; // contains string "abc"
>>>>>
>>>>> int reader(File x) {
>>>>> return x.read();
>>>>> }
>>>>>
>>>>> main() {
>>>>> print(reader(f));
>>>>> print(reader(f));
>>>>> }
>>>>>
>>>>> ----------
>>>>>>>>>
>>>>>>>>> will print out "aa" (incorrect)
>>>>>
>>>>> ----------
>>>>> File f; // contains string "abc"
>>>>>
>>>>> int reader(void) {
>>>>> return f.read();
>>>>> }
>>>>>
>>>>> main() {
>>>>> print(reader());
>>>>> print(reader());
>>>>> }
>>>>> ----------
>>>>>>>>>
>>>>>>>>> will print out "ab" (correct)
>>>>>
>>>>> this is because the state is stored globally and is not copied
>>>>>
>>>>> i -think- the only way to make it so you can pass the files around
>>>>> without
>>>>> this is to have them be references to global file objects that are on
>>>>> the
>>>>> heap (not stack like these). which seems like a pain.
>>>>>
>>>>> here's where i'd like your assistance:
>>>>> 1) am i missing an easy way to fix this issue?
>>>>>
>>>>> 2)i think i want to avoid using new() since that means after you open()
>>>>> a
>>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>>> delete() so much and people will forget.
>>>>>
>>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>>> is
>>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>>> suppose
>>>>> there's no conflict with existing code since no existing code passes
>>>>> around
>>>>> the file object since there's only one.
>>>>>
>>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>>
>>>>> thanks as always,
>>>>> limor
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>

_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
I have an ethernet webserver example that reads from SD, happy to pass it to you if it'd speed you along.

t.


On Feb 26, 2011, at 1:20 PM, Limor wrote:

> OK. probably just close() after every open() that succeeds is good enough. I will also have an example that shows directory traversal which will allow me to port this library for use with my Ethernet Webserver example which is what I set out to do about a month ago :D
>
> limor
>
> On 2/26/2011 1:15 PM, Tom Igoe wrote:
>> W're in teh midst of some SD example documentation right now, it's easy enough to put in a note about good file hygiene, i.e. always close() what you open() and delete() what you're not using. Let me know what you think is necessary and we can make sure it's there.
>>
>> t.
>>
>> On Feb 26, 2011, at 1:11 PM, David A. Mellis wrote:
>>
>>> You're right that people will probably forget to close files. On the
>>> other hand, it should be pretty easy for them to fix the problem if
>>> someone asks them if they remembered to close their files. I wouldn't
>>> worry about reference counting for an initial implementation. As you
>>> say, we could add it later, although it won't really work with global
>>> variables, which tend to be pretty common in Arduino sketches.
>>>
>>> On Sat, Feb 26, 2011 at 12:42 PM, Limor<> wrote:
>>>>
>>>>
>>>> On 2/26/2011 11:14 AM, David A. Mellis wrote:
>>>>>
>>>>> One of my priorities for the Arduino language is to minimize the
>>>>> amount of syntax people need to learn, so I'd like to avoid requiring
>>>>> them to use pointer or reference notation.
>>>>>
>>>>> My suggestion is to make File a wrapper for a pointer to an SdFile
>>>>> object that was allocated on the heap. With something like a file,
>>>>> we're going to want people to explicitly call close anyway, so we
>>>>> should be able to deallocate the memory there, too. People already
>>>>> need to check if opening the file succeeded, so the fact that it could
>>>>> fail from a lack of memory doesn't impose the need for significant
>>>>> additional error checking.
>>>>>
>>>>> Another possibility that avoids new syntax is having some set number
>>>>> of statically allocated file objects. But this seems unnecessary
>>>>> wasteful if people don't need them, and limiting if they need more.
>>>>> Because in this case the additional user requirements for handling
>>>>> dynamic allocation are minimal, I'd prefer that approach.
>>>>>
>>>>> What do you think?
>>>>
>>>> I was thinking of this but dreading that users would forget to close() and
>>>> we'd just have floating chunks of memory that we cant spare. But then I also
>>>> thought of having a basic poor-mans-garbagecollector which could count refs
>>>> to each sdfile and delete it when no more Files are pointing to it. not sure
>>>> if that will make it into my version but it is something that is easy to add
>>>> in the backend and only costs a byte.
>>>>
>>>>
>>>> limor
>>>>
>>>>> On Fri, Feb 25, 2011 at 8:02 PM, Limor<> wrote:
>>>>>>
>>>>>> hey gang!
>>>>>>
>>>>>> one of the side effects of having multiple files the way i have them now
>>>>>> seems to be that if you want to be able to have stuff like:
>>>>>>
>>>>>> File a = SD.open("/foo.txt");
>>>>>> File b = SD.open("/bar.txt");
>>>>>>
>>>>>> e.g. multiple files opened, that are passed by value so you can return
>>>>>> them
>>>>>> from open() - less memory annoyance
>>>>>>
>>>>>> but there is no underlying 'static' object that is consistent. which is
>>>>>> great because you can return by value. but object data like "location in
>>>>>> file" is copied between function calls, and isn't changed globally.
>>>>>>
>>>>>> for example!
>>>>>>
>>>>>> ----------
>>>>>> File f; // contains string "abc"
>>>>>>
>>>>>> int reader(File x) {
>>>>>> return x.read();
>>>>>> }
>>>>>>
>>>>>> main() {
>>>>>> print(reader(f));
>>>>>> print(reader(f));
>>>>>> }
>>>>>>
>>>>>> ----------
>>>>>>>>>>
>>>>>>>>>> will print out "aa" (incorrect)
>>>>>>
>>>>>> ----------
>>>>>> File f; // contains string "abc"
>>>>>>
>>>>>> int reader(void) {
>>>>>> return f.read();
>>>>>> }
>>>>>>
>>>>>> main() {
>>>>>> print(reader());
>>>>>> print(reader());
>>>>>> }
>>>>>> ----------
>>>>>>>>>>
>>>>>>>>>> will print out "ab" (correct)
>>>>>>
>>>>>> this is because the state is stored globally and is not copied
>>>>>>
>>>>>> i -think- the only way to make it so you can pass the files around
>>>>>> without
>>>>>> this is to have them be references to global file objects that are on
>>>>>> the
>>>>>> heap (not stack like these). which seems like a pain.
>>>>>>
>>>>>> here's where i'd like your assistance:
>>>>>> 1) am i missing an easy way to fix this issue?
>>>>>>
>>>>>> 2)i think i want to avoid using new() since that means after you open()
>>>>>> a
>>>>>> file, you'll have to close() and delete() and arduino doesnt really use
>>>>>> delete() so much and people will forget.
>>>>>>
>>>>>> 3) or i could make people pass pointers to File's instead of Files which
>>>>>> is
>>>>>> probably OK but a little nonideal since pointers are a mystery. i
>>>>>> suppose
>>>>>> there's no conflict with existing code since no existing code passes
>>>>>> around
>>>>>> the file object since there's only one.
>>>>>>
>>>>>> anyways, useful suggestions welcome now before i make a decision!
>>>>>>
>>>>>> thanks as always,
>>>>>> limor
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>


_______________________________________________
Developers mailing list

http://arduino.cc/mailman/listinfo/developers_arduino.cc
)
We don't pass by reference in Arduino-style sketches.

t.

On Feb 25, 2011, at 8:40 PM, A. Schamp wrote:

> Maybe I'm missing something obvious, but aren't pass-by-value /
> pass-by-reference semantics handled on a per-function basis, depending
> on the definition of the function?
>
> So, for example, couldn't you do something like the following?
>
> // pass x by reference
> int reader(File& x) {
> return x.read();
> }
>
> main() {
> File f; // contains string "abc"
> print(reader(f));
> print(reader(f));
> }
>
> That maintains object (i.e., non-pointer) usage, and lets f's state
> persist between function calls like that, as described here:
> http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference
>
> Wouldn't that handle this situation? Or is there some constraint
> preventing pass-by-reference usage?
>
> Andrew
>
>
> On Fri, Feb 25, 2011 at 7:02 PM, Limor <> wrote:
>> hey gang!
>>
>> one of the side effects of having multiple files the way i have them now
>> seems to be that if you want to be able to have stuff like:
>>
>> File a = SD.open("/foo.txt");
>> File b = SD.open("/bar.txt");
>>
>> e.g. multiple files opened, that are passed by value so you can return them
>> from open() - less memory annoyance
>>
>> but there is no underlying 'static' object that is consistent. which is
>> great because you can return by value. but object data like "location in
>> file" is copied between function calls, and isn't changed globally.
>>
>> for example!
>>
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(File x) {
>> return x.read();
>> }
>>
>> main() {
>> print(reader(f));
>> print(reader(f));
>> }
>>
>> ----------
>>>>>> will print out "aa" (incorrect)
>> ----------
>> File f; // contains string "abc"
>>
>> int reader(void) {
>> return f.read();
>> }
>>
>> main() {
>> print(reader());
>> print(reader());
>> }
>> ----------
>>>>>> will print out "ab" (correct)
>> this is because the state is stored globally and is not copied
>>
>> i -think- the only way to make it so you can pass the files around without
>> this is to have them be references to global file objects that are on the
>> heap (not stack like these). which seems like a pain.
>>
>> here's where i'd like your assistance:
>> 1) am i missing an easy way to fix this issue?
>>
>> 2)i think i want to avoid using new() since that means after you open() a
>> file, you'll have to close() and delete() and arduino doesnt really use
>> delete() so much and people will forget.
>>
>> 3) or i could make people pass pointers to File's instead of Files which is
>> probably OK but a little nonideal since pointers are a mystery. i suppose
>> there's no conflict with existing code since no existing code passes around
>> the file object since there's only one.
>>
>> anyways, useful suggestions welcome now before i make a decision!
>>
>> thanks as always,
>> limor
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. On 18/03/2011, at 21:08 , Tom Igoe wrote:
> We don't pass by reference in Arduino-style sketches.

What's the reasoning behind this?

The only real differences between pass by pointer and pass by reference are:

* You can't pass NULL
* The client doesn't have to put an & against the variable name in the call

For the novice users, this is a more obvious calling convention for objects like File.

Where does the blanket "we don't use references" come from?

Thanks,
Peter.

--
New Release: Sight Words
New Release: Mounties Feedback Trainer
New Release: Desktop Calendar Maker




_______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.