Takes 64 bytes because bool takes 1 byte. You should probably just do l & (1 << i) to get the i'th bit. Or use a bitset. Though why would you need this?
I'd like to know some advices and suggestions : ...
I did suggest to just do integers and also not to borrow too much C++ syntax. Also, these look like array declarations.
Did you look at BNF? If you have, you should be able to write a grammar for this yourself...
My guess is it's 4 or 8 bytes because CPU time is more expensive than memory, and CPUs are slower when operating on integers bigger or smaller than their native size.
@Aramil of Elixia
Just because Google uses something, doesn't make it good. Google also uses Java and Go, after all.
As stated, it is for efficiency. It is much faster to deal with the native integer size than a single bit. If you need to have a lot of booleans, use the std::vector<bool> specialization - it uses compact storage at the cost of efficiency.
If sizeof(bool) is 1 for you, either your compiler isn't optimizing for speed or you're compiling for an 8-bit system.[citation needed]
sizeof(bool) is usually 1. sizeof(A) where A is a type that contains only a bool may or may not be 1.
The compiler doesn't pad absolutely everything, or the code it generates would be really inefficient in space. Imagine creating a buffer of chars that takes up 4 times as much space as necessary.
If sizeof(bool) is 1 for you, either your compiler isn't optimizing for speed or <Insert Random Joke Here>
Well that's all I remind from experience, I'm used to test everything in debug mode - But yeah, I believe that for a CPU it's faster to handle a CPU-register-sized variable than a even-less-sized variable.
Again, because of this fact, and because you can't use efficiently the bool's data, I often use the char/unsigned char's if I need to store more bools and handle bits.
Firstly, thanks everyone who replied me and give me helpful information, and hamsterman, who helped me solving my 'union' question!!!
Second, now, I'm confused. A programming language interpreter (a parser language) always needs a very complex structure (In my opinion at least it contains a primary loader class and many child data structures - In short it's called "Tree structure") So IMO That is a very huge step - I think.
Recently I've tried making an interpreter structure... But it's quite complex and looks awful...So It really gives me a headache... Finally now I've decided to delete it immediately - I don't want to see it anymore, and after that I have to start again. :( Important categories : Variables (Basic and structures), structures (class, struct), functions, const definition, commands, code tracking (goto), array, multiple dimensional arrays, functions inside structures, handmade functions, attributes, returning value, parameter list, multiple structure accesses (sirparent-> parent-> child -> subchild...), value data, data pointer etc........??????....
I would like to discuss and know how to build an interpreter structure. Which way is best, simplest, shortest, smartest? Which way is most comfortable, convenient? To build an interpreter properly, I'll need to know helpful comments, suggestions, opinions, and advices... It's really a big problem and this is (maybe) the most important step. And more importantly, I've already defined my own grammar completely. I've just written an example and now I'm totally ready to start the interpreter construction. But I don't know where the right start point is...
(Any help would be greatly appreciated <:))
Basically, it's a more verbose form of reverse Polish notation. Once you can evaluate simple arithmetical expressions, expand the language with jumps and branches:
I like assembly...but maybe It takes a plenty of time...
I'm taking about C++... So ? New assembly?... This is really a gigantic step, IMO...
Edit : ("New child language" not "New programming language") <:)
Who are you going to trust? Your misguided intuition, or the advice of more experienced people?
Implementing an Assembler is two or three orders of magnitude simpler than implementing a C++... well, a C++ anything, really.
You said making a programming language is easier and simpler than making an interpreter (script) language?
I know Assembly -> everything (language etc)...
But I have no idea. Should I choose the assembly interface - it can make a new programming language (very high-performance), or a programming language interface....???
Actually, I'd like to know is there any way which can make an interpreter with a programming language. And also I want to know how to run the code immediately after the code checking process.
Therefore, I can't wait anymore...!! The construction process should start now...
You said making a programming language is easier and simpler than making an interpreter (script) language?
No. First of all, a scripting language is a programming language. Second, I'm not suggesting any particular form of execution (although interpretation is easy to implement).
What I'm saying is that implementing the language I described above is ridiculously simple compared to this:
Should I choose the assembly interface - it can make a new programming language (very high-performance), or a programming language interface....???
Sorry, by that time I was confused... [:D
Um... I'm now constructing the script programming language. Certainly it's based on C++, and the start point will look like this :