Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Apr 2011
Offline Last Active Today, 07:51 PM

Posts I've Made

In Topic: A short discussion on PODs

22 October 2014 - 11:05 AM

POD in c++11 is two concepts: standard layout(which guarantees the order of elements), and trivial(no special actions are done while initializing, destructing and copying). Both combined guarantees same behavior with C, the plain old ways.


Identical access control is required for standard layout, since C++ require members with the same access control to be ordered in declaration order, but no requirement regarding different access control. The compiler is allowed to reorder different access control (maybe for optimization or hardware level read/write restrictions, I don't know why one would want to do that but it's their freedom), so having a class with multiple access control could break the layout, thus is non-standard layout.


Trivial-ness of a class is to ensure the compiler can use a no-brainer memcpy on your class and nothing will break. If you need a non-default constructor, that means you are doing something in it and memcpy-ing it could break it.


And ctor() = delete means no default constructor could be used. you need ctor() = default instead.


It's kind of late here so I didn't read all of your wall of text. I wonder why you want your class to be POD? You can still memcpy a non-POD if you know what you are doing, so having a constructor that only set the default values won't harm, and I bet the compiler can still optimize it while using default copy.

POD is only to guarantee to compiler nothing could possibly go wrong while doing certain operations. You can still ensure it yourself, even in a standard conformant way.

In Topic: Fusion Energy Source Advancement - News Today!

15 October 2014 - 10:14 AM

Reminded me of this:


In Topic: The Week of awesome II - The judge Thread!

10 October 2014 - 03:32 AM

Here's my incredibly late post mortem:


In Topic: Lines of code language comparisons

08 October 2014 - 09:49 AM

You can spend time to make your code cost less line/character, and than spend even more time to make it look good.

For example:



definitely shorter than normal c code, also definitely more time coding unless you're copying it by hand.

and a day of eternity to maintain it.


I prefer longer code than shorter code, as it will be easier to read and understand. If you are doing any real programming job, you will always spend more time thinking, reading than actually typing.


Ancient Chinese literature use a different language then the spoken one. As paper was expensive, they compressed the language so they can talk about more nonsense with less money. The result is some cryptic dialect that took us years to learn and still very difficult.


If George RR Martin zip his novel in his head before writing it down and have the publisher decompress it, could he finish The Winds of Winter quicker? He'll need less finger movement. Or maybe he should learn ancient Chinese?


I think LOC is only meaningful while on logarithm scale, to help estimate the size of a project. There's definitely difference between a 1K LOC project and a 100K LOC project, but doesn't mean 200K LOC project will be always more complex than a 100K project.


Other than this, the only use of LOC is to intimidate non-programmers. Telling your designer that feature will cost 1M LOC (citation needed) will probably shut him up.

In Topic: [Solved] Lua "require" other files when loaded from memory

08 October 2014 - 02:48 AM

Some shorter example

int MyLoader(lua_State *L){
	//load the first parameter
	//which is the name of the file, or whatever string identifier for a resource that you passed in with require()
	string filename = lua_tostring(state,1);
	if( exist_in_container(filename)){
		buffer = get_data_from_container(filename);
		//load the buffer
		luaL_loadbuffer(L,buffer.data,buffer.size, filename.c_str());
		return 1;
		lua_pushstring(L, "Error: file not found");
		return 1;

// when you initialize your lua state...

//locate the package.loaders table

//for convienice, we just replace the first one with our loader
//package.loaders[1] = MyLoader
//balance the stack.

Although I'll still recommend you to try to understand the Lua stack and interfacing with C.