[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Accepting arbitrary strings as structure field names
From: |
Rafael Laboissiere |
Subject: |
Re: Accepting arbitrary strings as structure field names |
Date: |
Sat, 11 Nov 2006 11:29:53 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
* John W. Eaton <address@hidden> [2006-11-10 19:06]:
> On 10-Nov-2006, Rafael Laboissiere wrote:
>
> | Is it possible to insert a NUL character in an Octave string?
>
> Yes:
>
> char ([102, 0, 0, 98, 97, 114])
>
> After sending my message this morning, I tried saving a character
> string like this and that part worked, but reloading it failed, only
> loading up to the first NUL, so I fixed that problem. I didn't check
> all formats, though looking at the code it seemed that the HDF5 format
> would not correctly save character strings with embedded NUL
> characters because it appears to use a C-style string with no
> associated length to pass the data.
>
> When saving a struct, the field name is not saved like character
> data. Instead, it is saved like the name of a variable, like this:
>
> # name: NAME
>
> using code like this:
>
> os << name << std::endl
>
> and it is read back in a similar way, so I think it will fail for
> field names with embedded NUL characters. This is not a problem
> currently because the names of variables are restricted.
Fair enough. It seems that once the save/load of arbitrary strings is
fixed, then anything that would dependent on strings (like fields of
associative arrays, or hashes) will also be fixed.
> Instead of overloading structures directly for this purpose, what
> about making a new data type instead and using functions to add
> elements to the table?
I also think that this is the best solution. We have already the Map type
in Octave's core. It could be used as a basis for creating an octave_map
type inherited from octave_value, in the same way the Cell type serves as a
basis for octave_cell. Should I give a try to it?
If such a new type is created, it would be great to extend the syntax to
allow things like var.("any-string"). This example is unfortunate because
this is the syntax used already for the structure data type. Taking
inspiration from other languages, like Perl's var{"any-string"} and
Javascript's var["any-string"], does not help really.
--
Rafael
- Accepting arbitrary strings as structure field names, Rafael Laboissiere, 2006/11/04
- Re: Accepting arbitrary strings as structure field names, Bill Denney, 2006/11/04
- Re: Accepting arbitrary strings as structure field names, Etienne Grossmann, 2006/11/04
- Re: Accepting arbitrary strings as structure field names, Rafael Laboissiere, 2006/11/05
- Re: Accepting arbitrary strings as structure field names, Rafael Laboissiere, 2006/11/05
- Re: Accepting arbitrary strings as structure field names, Rafael Laboissiere, 2006/11/05
- Re: Accepting arbitrary strings as structure field names, John W. Eaton, 2006/11/10
- Re: Accepting arbitrary strings as structure field names, Rafael Laboissiere, 2006/11/10
- Re: Accepting arbitrary strings as structure field names, John W. Eaton, 2006/11/10
- Re: Accepting arbitrary strings as structure field names,
Rafael Laboissiere <=