Forums

Adrian said

I'm not sure about this… isn't this writing a lot of code just to avoid writing a getter/setter pair? The containing class is easier to read, but to understand the class as a whole you can no longer read just one file.

I think that depends on how common the idiom is in the source code. For example, we don't worry about having to look up things like std::map or std::pair — we just use them and expect anybody reading the code to know what they are. The parts of the libraries that get used a lot need to be learned by the developers and when that happens the shorter class definitions are well worth it.

I don't think that the technique has much merit if not used pretty widely.

if ( nLat < 180. || nLat >= 180. )

I stared at this for many minutes thinking “there's nothing wrong there, what does he mean?” before I spotted the missing minus on the first half of the test. Thanks for spotting that.

I'm a bit confused by the third code example. When does this resolve to false:

if ( nLat < 180. || nLat >= 180. )

Vasudha said

Vasudha said

Hi Tai, I am vasudha. Met you in the airoplane. went through your website. wow lots to go through. Hope you are doing fine. Nice snap :) take care Vasudha

hey do you remember we talked abt massages and I told you about ayurveda go through the link below :).. hope its interesting for you

http://en.wikipedia.org/wiki/Ayurveda

Hello Vasudha,

Sorry for the late reply. Cause I was flying all the time. Thank you for the information about Ayurveda. I'll try it next time when I fly to India.

I am glad that you like my husband's website. Hope you might find something useful from it.

Nice to hear from you and keep in touch.

tai

Vasudha said

Hi Tai, I am vasudha. Met you in the airoplane. went through your website. wow lots to go through. Hope you are doing fine. Nice snap :) take care Vasudha

hey do you remember we talked abt massages and I told you about ayurveda go through the link below :).. hope its interesting for you

http://en.wikipedia.org/wiki/Ayurveda

I should have also mentioned that I can give you some Unicode encoding/decoding code to use or to look at if it'll help.

I can't make any g'tees about its portability, at least not until I've been through and ported it at least one other platform anyway.

Kirit Sælensminde said

I think the big advantage here is that there are no type holes. You are forced to address each type within the variants or it won't compile and you also know you won't get any surprises at run time.

Definitely! As I wrote in my blog, the reason to use boost::any was lazyness ;) .. But I will change it to boost::variant in the next version.

Kirit Sælensminde said

It does however imply a widening of scope of TinyJSON to a full JSON library rather than just parsing. Maybe that's Ok for version 2 though? :)

I have to think about it ;)

Thomas said

Parametrization seems to be the right way to do it! Thanks for the great post - and the valuable tips..

Glad that it was useful to you.

I'm not sure if this will sway you on switching to Boost.Variant, but here's what the traversals might look like:

namespace {
    json_string string_to_json( const wstring &s ) {
        return L"\"" + replaceAll( s, L"\"", L"\\\"" ) + L"\"";
    }
    struct atom_to_json : public boost::static_visitor< json_string > {
        json_string operator()( t_null ) const {
            return L"null";
        }
        json_string operator()( const wstring &s ) const {
            return string_to_json( s );
        }
        template< typename T >
        json_string operator()( T i ) const {
            return FSLib::coerce< wstring >( i );
        }
    };
    struct to_json : public boost::static_visitor< json_string > {
        json_string operator()( const Json::atom_t &t ) const {
            return boost::apply_visitor( ::atom_to_json(), t );
        }
        json_string operator()( const Json::array_t &t ) const {
            std::wostringstream s;
            for ( Json::array_t::const_iterator i( t.begin() ); i != t.end(); ++i )
                s << ( i == t.begin() ? wstring() : L"," ) << toJson( **i );
            return L"[" + s.str() + L"]";
        }
        json_string operator()( const Json::object_t &t ) const {
            std::wostringstream s;
            for ( Json::object_t::const_iterator i( t.begin() ); i != t.end(); ++i )
                s << ( i == t.begin() ? wstring() : L"," ) << string_to_json( i->first ) << L":" << toJson( *i->second );
            return L"{" + s.str() + L"}";
        }
    };
}
json_string FSLib::toJson( const Json &json ) {
    return boost::apply_visitor( ::to_json(), json );
}

The string mangling isn't quite up to production quality — it probably ought to do something explicit about control characters and throw for those that aren't supported. I think the call to coerce can be replaced with Boost's lexical cast.

I think the big advantage here is that there are no type holes. You are forced to address each type within the variants or it won't compile and you also know you won't get any surprises at run time.

It does however imply a widening of scope of TinyJSON to a full JSON library rather than just parsing. Maybe that's Ok for version 2 though? :)