octave-maintainers
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]