4 ms·

> It would be really nice to compose objects hierarchally: for example, if I had a widget class composed of several different renderable Rectangles, I want to b

> It would be really nice to compose objects hierarchally: for example, if I had a widget class composed of several different renderable Rectangles, I want to be able to automatically generate the rendering code for my widget based on the existing rendering logic for its constituent shapes. So one thing that I've learned about programming: Don't overthink it. How many different object types do you want to serialize? Maybe a hundred? So just write those 100 lines of boilerplate. Not a huge amount of work, even when there is the the occasional modification. An additional benefit is that you're not painting yourself in a corner - for example, you can leave out that additional bit of redundant information that you hacked in as an optimization. What's really huge for maintainability is this thing called aspect-oriented programming: Don't litter each of your classes with a line of boilerplate for this and another line for that. Make a file "serialize.cpp" that contains the serialization code for all the types, and nothing else. In other words, object-oriented is the wrong tool, for almost everything (sorry if that's old news).

twoodfin 10y ago
Hopefully the next version of the C++ standard will incorporate some form of the unified call syntax proposal, which will make the use of this style of code organization more consistent with traditional one-per-class declaration files.
SolarNet 10y ago
> > It would be really nice to compose objects hierarchally: for example, if I had a widget class composed of several different renderable Rectangles, I want to be able to automatically generate the rendering code for my widget based on the existing rendering logic for its constituent shapes. Actually, what's interesting is that both Lisp macros and C++ templates allow this to work pretty easily if you set up the boiler plate well enough. All this article is really talking about is making it easier to set up and use that boilerplate (e.g. put it in the language). > What's really huge for maintainability is this thing called aspect-oriented programming: Don't litter each of your classes with a line of boilerplate for this and another line for that. Make a file "serialize.cpp" that contains the serialization code for all the types, and nothing else. And that works if your project is not meant to ever be extended. But generally the point of having object oriented systems is being able to make new objects that can take the place of old ones. Of having abstraction.
- jstimpfle 10y ago
  If by "abstraction" you mean ADTs - of course there are some (not many) places where they are useful. And you can easily have them or change to them later. It's just another few lines of boilerplate to make a few method tables. But I don't like to have the implementation logic in the places where method dicts are wired, especially for interfaces with very little coherency, like GameModel3d: render, click, contextString, serialize... Doing that instead of aspect-oriented is a violation of the "separation of concerns" principle.
  - tcbawo 10y ago
    Isn't the dream of a reflection library to build serialization using an Observer pattern, where the serialization logic is unbounded and business logic never mixes? It would be great if the standard came up with something that would be so broadly useful and allow developers to focus on their domain instead of serialization.
maccard 10y ago
> So just write those 100 lines of boilerplate. Although I agree with your ide, I've written some boilerplate code before to do something very similar. As the project grew its become a constant source of bugs where someone has updated the code for one type and not another. At this point they're too far gone to have any hope of merging them, but had I known two years ago how much hassle it would have caused I would have refactored it into common code
- fsloth 10y ago
  Yeah - I agree with both of you. First start with the boilerplate approach, and once there is boilerplate in place for a low number of entity types, say, 2<n<10, figure out if that can be refactored into something less boilerplatey. But yeah, very seldom starting with a complex abstraction for a code you've never written before is a good idea.
StillBored 10y ago
C++ has "built in" serialization the same way that C does.. Except its not acceptable to use anymore, even though its orders of magnitude faster than the alternatives.. AKA you write your structures out directly as binary data. Bonus if you align them. The limitation is that you can't have classes/structures with actual pointers in them (rather using offsets) and you have to encourage your compiler to pack/align them consistently. Bonus if you override the new/placement allocator so that you can serialize gigabytes of data (including pointers) with a simple map/unmap call. Frankly, the idea that data should be human readable is complete crap, especially for things which are going to be machine processed far more than human processed. AKA use XML for your config file, not for the gigabytes of data you send over the wire/store on disk/etc, that will never be read by a human. Its funny that HTML/etc has everyone in this strange mindset that somehow its more efficient to build human readable markup, which 99.9999% of the time is never read by a human, and has to be compressed with algorithms that further burn up tons of CPU time in order to squash the resulting data. The untold tons of carbon wasted transfering more data than necessary and/or compressing/decompressing it is insane for the possibility that someone will want to read it as it flys over the wire, rather than decoding it at the endpoint and viewing it in a debugger...
- jstimpfle 10y ago
  > AKA you write your structures out directly as binary data. What does that even mean? Depends on what the output should be and how much control you need, I guess. To comment on the binary vs text digression - computation overhead is probably not that much if the data is converted to a (non-portable) internal DOM representation and then typeset / rasterized anyway. And is bandwidth/storage overhead? I assume a short video quickly outweighs the costs for 100%, or in extreme cases 1000%, overhead compared to a compressed DOM representation. And the human factors are definitely there.
- frozenport 10y ago
  Dumping raw binary is a problem if you want your data to be readable across platforms or versions of the same code. It is also a bad idea if reading a complete structure into memory is not possible, or a poor use of time. For example, if you need to read a single part of a gigabyte data set.

twoodfin 10y ago

Hopefully the next version of the C++ standard will incorporate some form of the unified call syntax proposal, which will make the use of this style of code organization more consistent with traditional one-per-class declaration files.

SolarNet 10y ago

> > It would be really nice to compose objects hierarchally: for example, if I had a widget class composed of several different renderable Rectangles, I want to be able to automatically generate the rendering code for my widget based on the existing rendering logic for its constituent shapes. Actually, what's interesting is that both Lisp macros and C++ templates allow this to work pretty easily if you set up the boiler plate well enough. All this article is really talking about is making it easier to set up and use that boilerplate (e.g. put it in the language). > What's really huge for maintainability is this thing called aspect-oriented programming: Don't litter each of your classes with a line of boilerplate for this and another line for that. Make a file "serialize.cpp" that contains the serialization code for all the types, and nothing else. And that works if your project is not meant to ever be extended. But generally the point of having object oriented systems is being able to make new objects that can take the place of old ones. Of having abstraction.

jstimpfle 10y ago
If by "abstraction" you mean ADTs - of course there are some (not many) places where they are useful. And you can easily have them or change to them later. It's just another few lines of boilerplate to make a few method tables. But I don't like to have the implementation logic in the places where method dicts are wired, especially for interfaces with very little coherency, like GameModel3d: render, click, contextString, serialize... Doing that instead of aspect-oriented is a violation of the "separation of concerns" principle.
- tcbawo 10y ago
  Isn't the dream of a reflection library to build serialization using an Observer pattern, where the serialization logic is unbounded and business logic never mixes? It would be great if the standard came up with something that would be so broadly useful and allow developers to focus on their domain instead of serialization.

maccard 10y ago

> So just write those 100 lines of boilerplate. Although I agree with your ide, I've written some boilerplate code before to do something very similar. As the project grew its become a constant source of bugs where someone has updated the code for one type and not another. At this point they're too far gone to have any hope of merging them, but had I known two years ago how much hassle it would have caused I would have refactored it into common code

fsloth 10y ago
Yeah - I agree with both of you. First start with the boilerplate approach, and once there is boilerplate in place for a low number of entity types, say, 2<n<10, figure out if that can be refactored into something less boilerplatey. But yeah, very seldom starting with a complex abstraction for a code you've never written before is a good idea.

StillBored 10y ago

C++ has "built in" serialization the same way that C does.. Except its not acceptable to use anymore, even though its orders of magnitude faster than the alternatives.. AKA you write your structures out directly as binary data. Bonus if you align them. The limitation is that you can't have classes/structures with actual pointers in them (rather using offsets) and you have to encourage your compiler to pack/align them consistently. Bonus if you override the new/placement allocator so that you can serialize gigabytes of data (including pointers) with a simple map/unmap call. Frankly, the idea that data should be human readable is complete crap, especially for things which are going to be machine processed far more than human processed. AKA use XML for your config file, not for the gigabytes of data you send over the wire/store on disk/etc, that will never be read by a human. Its funny that HTML/etc has everyone in this strange mindset that somehow its more efficient to build human readable markup, which 99.9999% of the time is never read by a human, and has to be compressed with algorithms that further burn up tons of CPU time in order to squash the resulting data. The untold tons of carbon wasted transfering more data than necessary and/or compressing/decompressing it is insane for the possibility that someone will want to read it as it flys over the wire, rather than decoding it at the endpoint and viewing it in a debugger...

jstimpfle 10y ago
> AKA you write your structures out directly as binary data. What does that even mean? Depends on what the output should be and how much control you need, I guess. To comment on the binary vs text digression - computation overhead is probably not that much if the data is converted to a (non-portable) internal DOM representation and then typeset / rasterized anyway. And is bandwidth/storage overhead? I assume a short video quickly outweighs the costs for 100%, or in extreme cases 1000%, overhead compared to a compressed DOM representation. And the human factors are definitely there.
frozenport 10y ago
Dumping raw binary is a problem if you want your data to be readable across platforms or versions of the same code. It is also a bad idea if reading a complete structure into memory is not possible, or a poor use of time. For example, if you need to read a single part of a gigabyte data set.