{"action":"created","issue":{"url":"https://api.github.com/repos/google/flatbuffers/issues/3901","repository_url":"https://api.github.com/repos/google/flatbuffers","labels_url":"https://api.github.com/repos/google/flatbuffers/issues/3901/labels{/name}","comments_url":"https://api.github.com/repos/google/flatbuffers/issues/3901/comments","events_url":"https://api.github.com/repos/google/flatbuffers/issues/3901/events","html_url":"https://github.com/google/flatbuffers/issues/3901","id":158848364,"number":3901,"title":"ORM like encoding/decoding for C++ ?","user":{"login":"bog-dan-ro","id":2239316,"avatar_url":"https://avatars.githubusercontent.com/u/2239316?v=3","gravatar_id":"","url":"https://api.github.com/users/bog-dan-ro","html_url":"https://github.com/bog-dan-ro","followers_url":"https://api.github.com/users/bog-dan-ro/followers","following_url":"https://api.github.com/users/bog-dan-ro/following{/other_user}","gists_url":"https://api.github.com/users/bog-dan-ro/gists{/gist_id}","starred_url":"https://api.github.com/users/bog-dan-ro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bog-dan-ro/subscriptions","organizations_url":"https://api.github.com/users/bog-dan-ro/orgs","repos_url":"https://api.github.com/users/bog-dan-ro/repos","events_url":"https://api.github.com/users/bog-dan-ro/events{/privacy}","received_events_url":"https://api.github.com/users/bog-dan-ro/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-06-07T06:25:22Z","updated_at":"2016-06-08T18:09:15Z","closed_at":null,"body":"Because currently is not easy to change a message (e.g. set a longer string, change a vector size, etc.), when it has lots of (nested) tables, I'd like to propose a new optional way (probably slower) of encoding/decoding flatbuffers messages in C++.\r\nFlatc will generate (separate) classes which will have set/get methods for every field, this way it will be very easy to change any fields. \r\nThey will also have two methods: \r\n- ```bool encode(void **ptr, size_t *sz)```  which encodes the message (it will go through all nested tables), sets ***ptr*** and ***sz*** values and returns ***true*** on success. \r\n- ```size_t decoding (void *ptr);``` decodes the message (fills all the classes/nested classes fields) and returns the size of the message in bytes (***0*** of course means it needs more data).\r\n\r\nI know it will be a little bit slower, but the code will be much more readable and maintainable."},"comment":{"url":"https://api.github.com/repos/google/flatbuffers/issues/comments/224678733","html_url":"https://github.com/google/flatbuffers/issues/3901#issuecomment-224678733","issue_url":"https://api.github.com/repos/google/flatbuffers/issues/3901","id":224678733,"user":{"login":"gwvo","id":6145400,"avatar_url":"https://avatars.githubusercontent.com/u/6145400?v=3","gravatar_id":"","url":"https://api.github.com/users/gwvo","html_url":"https://github.com/gwvo","followers_url":"https://api.github.com/users/gwvo/followers","following_url":"https://api.github.com/users/gwvo/following{/other_user}","gists_url":"https://api.github.com/users/gwvo/gists{/gist_id}","starred_url":"https://api.github.com/users/gwvo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gwvo/subscriptions","organizations_url":"https://api.github.com/users/gwvo/orgs","repos_url":"https://api.github.com/users/gwvo/repos","events_url":"https://api.github.com/users/gwvo/events{/privacy}","received_events_url":"https://api.github.com/users/gwvo/received_events","type":"User","site_admin":false},"created_at":"2016-06-08T18:09:15Z","updated_at":"2016-06-08T18:09:15Z","body":"We've considered this quite a few times in the past. The reason we don't support this is that it goes against everything FlatBuffers is trying to achieve for the user: not allocating a tree of objects. Doing so is exactly what makes Protobuf slow, so supporting it would erase one of the major reasons to use FlatBuffers.\r\n\r\nThis is why we implemented the reflection functionality as a \"FlatBuffer friendly\" way of achieving this kind of functionality. But I agree it is rather clumsy.\r\n\r\nThat said, this would be useful for quick editing tasks in non-performance critical parts of an ecosystem that uses FlatBuffers generally, and one could argue that our support of slower languages like Python also means that not all uses of FlatBuffers always need to have maximum performance. So I have to admit I am open to the idea of optionally adding the kinds of interfaces you suggest.\r\n\r\nThe way I'd see the interface is that a new switch, `--gen-objects` that would add a `TableObject *CreateTree()` to each table, and then each `TableObject` derived class would have a `Offset<Table> Serialize(FlatBufferBuilder &fbb)` method. The cool thing is that this way you can do it partially, i.e. create a tree out of only part of a buffer, and serialize them back to part of a buffer."}}
{"actor":{"display_login":"gwvo"}}