Rate my scanner object.
Just thought this may be useful to someone.
This is a generic scanner that can be used to tokenize any (I think!) programming language. The interface is straightforward, easy to use, and also compatible with other STL code.
Please let me know what you think!
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Um... Where is the implementation source?If it is in the library, I don't think we could rate anything but the interface.
The point is that it is a useful object. So test it, and rate it on that merit. You can't see the implementaion for vsprintf(), can you? But how do you rate it? Get my point?
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Just a question. And yes, it is indeed useful but I can't say more because I don't use the STL so iterators and stuffs are almost unknown to me. (I know the theory but not the use, neither interface nor implementation)
But I have one question, your parser does not allow us to check the syntax, does it? For instance, a variable must begin with a letter or an underscore but not a number...
Good point. The next release will allow you to optionally define tokens using BNF notation, meaning you will be able to do that using a rather concise syntax. This would also remove the 'ordinal precedance' requirement that is described in the documention.
If you have never used the STL, I strongly encourage that you learn how to use it. Generic programming is the future, as they say.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
It might be useful to see the implementation. That way we can offer suggestions and people can learn from what you did. I am very interested in programming language design and knowing how you parsed the code might be some use to me (not to copy, hell no, but to see how it works). Perhaps you do it more efficiently than my code?
At some point, yes, I will release the source code. An interesting note is that the scanner was coded in less than 100 lines!
As far as speed goes, a hard-coded scanner would obviously run more efficiently, of course, but the downside is the lengthy development time involved and it's lack of flexibility. If nothing else, the generic one can be used to jump-start a project until a hard-coded implementation is developed.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Thanks, but I already learn about the generic way to do things, I mean templates. If I don't use the STL it is because I prefer more low-level manipulations. I don't know how to use it but if I had to make use of it one day, I could learn quite quickly as I know about almost every concepts there. I studied the library even if I don't use it.If you have never used the STL, I strongly encourage that you learn how to use it. Generic programming is the future, as they say.
Um... And may I ask, are you planning on doing a compiler or an interpreter thing?
Yes, I hope to develop a compiler. In fact, if you or anyone else is interested, please let me know. I think it would be an excellent project, for both personal reasons and for the fact that it would build recognition for all involved. Anyway, I know what you mean about the STL. For a long time I had been using generic programming techniques (even wrote a subset of a 'template' library for the C programming language), but put off using the STL. But the main thing is that it is portable, and other programmers can easily assimilate your code into theirs. That commonality is a very compelling reason for using the STL almost exclusively.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Thanks for the offer but I'm not used to work in team and I don't think it could bring your project any good. (because I have never worked before actually and working together is somethign you learn quite late at school here)
Besides, I don't have much knowledge in algorithm. (though I studied quite basic things, data structures & array and list sort)
Anyway, if you want, I could give you some help.
However, I must warn you that the optimizing part of your compiler will be quite painful. Because I spent quite a while learning assembly for speed purpose, but eventually, I ended up with an unexpected answer to all my questions: my compiler does the work as well as I do or even better than me.
Not that I am saying that you cannot do better work than the compiler but it is hard.
About the STL, well, I don't work for portability and besides, other programmers can easily understand what I'm writting because I use but C to do the work, arrays and pointers. I know quite well pointers and for one who has done much more C than C++, I tend to stick with my pointers. ^^ I know it could be dangerous sometime but not necessarily as much people say. I think the main problem is that people nowadays learn C++ without knowing well what was once called "C" and is now only a part of the world-known language C++. Actually, the only answer you can get from a teacher is "use the standard containers" for what before you would have got "take your pointers and try to understand".
