wxlua-users

[wxlua-users] Back to ParseDate

[Andre A. <ar...@ki...>]

using date:ParseDate(value, wx.wxString_const_iterator()) 

seems to work but looking into the run time we see that the pointer to the 
iterator is a bad pointer not very desirable.

supporting a single argument seems preferable.
The following code works.

static int LUACALL wxLua_wxDateTime_ParseDate(lua_State *L)
{
    // wxString date
    wxString date = wxlua_getwxStringtype(L, 2);
    // wxString::const_iterator end
    wxString::const_iterator * end;
	if (lua_type(L, 3) == LUA_TNONE)
		// missing argument
		end = &(wxString::const_iterator)date.end();
	else
		end = (wxString::const_iterator *)wxluaT_getuserdatatype(L, 3, 
wxluatype_wxString_const_iterator);

but a similar change would be needed for each function expecting an optional 
iterator.

currently wxlua_getwxStringtype does not seem to handle a missing argument.
If it returned NULL we could trigger on the result.

maybe a special function 
   end = GetOptionalIterator(L, 3, date);
which returns the_iterator || &date.end() could be used.

Andre

Re: [wxlua-users] Back to ParseDate

[John L. <jla...@gm...>]

On Thu, Jun 7, 2012 at 10:09 AM, Andre Arpin <ar...@ki...> wrote:
> using date:ParseDate(value, wx.wxString_const_iterator())
>
> seems to work but looking into the run time we see that the pointer to the
> iterator is a bad pointer not very desirable.
>
> supporting a single argument seems preferable.

I agree that the current functions are awkward to use. I will make the
input iterator argument optional.

Regards,
    John

Re: [wxlua-users] Back to ParseDate

[Andre A. <ar...@ki...>]

> 
> I agree that the current functions are awkward to use. I will make the
> input iterator argument optional.
> 

I am having a hard time understanding the use of iterator in wxlua.

I guess an iterator is created by wxString::const_iterator end() or 
wxString::const_iterator begin() for wxString which would be coded 
wx.wxString(str):end() but end is a reserve word in Lua. I guess end could be 
renamed.

the code would be
date:ParseDate(aa,  wx.wxString_const_iterator(aa:end()) )
since aa:end()returns a wxString_iterator

Note: that using begin() give unexpected results

aa = wx.wxString("09-06-2012")
print(date:ParseDate(aa, wx.wxString_const_iterator(aa:begin())))
aa = wx.wxString("")
print(date:ParseDate(aa, wx.wxString_const_iterator(aa:begin())))

display:
true
false

I would have expected both of these to be identical.

--------------------------------------------------------

Are iterators useful in wxLua? The addition in wxWidget maybe justified for 
saving copying of strings in a tight loop but most of the time C++ programmer 
will replace their code in the following way and live with the overhead.

old code: foo(v) 
new code: foo(v,&(type::const_iterator)v.end) // would not compile purely for 
illustration.

In wxLua using foo(v) or foo(string.match(v,pattern)) seems so much simpler than 
using an iterator.

ParseDate is not the only function using iterator but all of them seem similar.

Thank you.
Andre

Re: [wxlua-users] Back to ParseDate

[John L. <jla...@gm...>]

On Sat, Jun 9, 2012 at 10:25 AM, Andre Arpin <ar...@ki...> wrote:
> I am having a hard time understanding the use of iterator in wxlua.
>
> I guess an iterator is created by wxString::const_iterator end() or
> wxString::const_iterator begin() for wxString which would be coded
> wx.wxString(str):end() but end is a reserve word in Lua. I guess end could be
> renamed.

That is unfortunate. You can get the function using this...

s = wx.wxString()
e = s['end']
iter_end = e(s)

> aa = wx.wxString("09-06-2012")
> print(date:ParseDate(aa, wx.wxString_const_iterator(aa:begin())))
> aa = wx.wxString("")
> print(date:ParseDate(aa, wx.wxString_const_iterator(aa:begin())))

This is probably not right, you would need to call it like this.

it = aa:const_iterator()
print(date:ParseDate(aa, it))

> Are iterators useful in wxLua? The addition in wxWidget maybe justified for
> saving copying of strings in a tight loop but most of the time C++ programmer
> will replace their code in the following way and live with the overhead.

They're required for using UTF8 since not every code point is a single char.

I think the simplest solution is to return two values, [bool, Lua
String of start of input on failure] where the second Lua String is
only returned on failure and contains the start of the input string up
until the failure. I hope to have time to do it tomorrow night.

Regards,
     John