# fast math expression parser

28 replies to this topic

### #21phresnel

Member

• Members
• 47 posts

Posted 22 October 2009 - 07:53 PM

.oisyn said:

Nonsense. Naming a header 'stdafx.h' [...]'s nothing unportable about it.
Nitpicky, yes. But only in this case. When code is published that #includes unpublished blackboxes, then
a) (the "mild" form) it might not compile at all
b) (the "evil" form) intended behaviour and actual behaviour might largely vary. Think of #define macros, function overloads, template partial and explicit specializations, et al.

Where is the portability when a) or b) strike?

Quote

In a header, yes. In a sourcefile everybody should decide for himself.

In my opinion, blanket using statements should never exceed function scope. Scope should (imho) be as big as needed, but not bigger.

Quote

All names in de std namespace are defined by the standard.
And as the standard does not define which names may be defined outside "de std namespace", those pulled-in names may very well collide with your code. Sooner or later, with or without tweaking the sourcefile in question.

revision 0:
foo.hh:
#ifndef FOO_HH

#define FOO_HH

#endif
bar.cc:

#include <string>

using namespace std;

#include "foo.hh"

class list {};

int main () {

list frogs;

}

revision 2048:
foo.hh:
#ifndef FOO_HH

#define FOO_HH

#include <list>

#endif

Example consequence (note: bar.cc was never changed anymore!):
main.cc: In function ‘int main()’:

main.cc:10: error: reference to ‘list’ is ambiguous

main.cc:6: error: candidates are: class list

/usr/include/c++/4.3/bits/stl_list.h:416: error:                 template<class _Tp, class _Alloc> class std::list

main.cc:10: error: reference to ‘list’ is ambiguous

main.cc:6: error: candidates are: class list

/usr/include/c++/4.3/bits/stl_list.h:416: error:                 template<class _Tp, class _Alloc> class std::list

main.cc:10: error: expected ;' before ‘frogs’

Quote

Again, nonsense. According to ISO/IEC 14882:2003, paragraph C.2.2.3/1:

Quote

The macro NULL, defined in any of <clocale>, <cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, or <cwchar>, is an implementation-defined C++ null pointer constant in this International Standard (18.1).
int main () {

int *p;

if (NULL == p) {

}

}
main.cc: In function ‘int main()’:

main.cc:3: error: ‘NULL’ was not declared in this scope

I am not sure whether I shall now dive into all my source code files and pull in unrelated #include files just to have NULL defined, or just follow the well established and less redundant convention of using a builtin literal that also happens to be portable.

Quote

Oh, then what is the C++ counterpart of assert()?
The macro assert(). Why?

Anyways, it is good practice to use the C++ counterparts of the C library where available. E.g., math.h defines cos and cosf, whereas cmath only defines the function name cos with three function overloads, thus reducing redundancy, improving readability of template code, helping to avoid the subtle issues when accidentally using 64bit floating point where only 32bit floating point is intended. There are some more less than irrelevant differences.

cassert and assert.h are the same, but why make an exception to the rule for only the assert macro?

~/www/ | picogen.org | metatrace
- --- / .-.. . - / -- -.-- / ... .. --. -. .- - ..- .-. . / .- .--. .--. . .- .-. / --. . . -.- -.--

### #22.oisyn

DevMaster Staff

• Moderators
• 1842 posts

Posted 22 October 2009 - 09:13 PM

phresnel said:

Nitpicky, yes.
No, just wrong. "stdafx.h" is by no means "MSVC++ only"

Quote

In my opinion, blanket using statements should never exceed function scope. Scope should (imho) be as big as needed, but not bigger.
I agree with you on this, but the point is that it is not wrong or evil to do otherwise (as opposed to putting a using directive in a header, which *is* evil). It's just a matter of taste.

Quote

And as the standard does not define which names may be defined outside "de std namespace", those pulled-in names may very well collide with your code. Sooner or later, with or without tweaking the sourcefile in question.
And some think that you shouldn't use those names in the first place to avoid confusion. This is especially true for functions, due to the two phase name lookup in templates.
and obviously I meant "the" std namespace

Quote

int main () {
int *p;
if (NULL == p) {
}
}
main.cc: In function int main():
main.cc:3: error: NULL was not declared in this scope

I am not sure whether I shall now dive into all my source code files and pull in unrelated #include files just to have NULL defined, or just follow the well established and less redundant convention of using a builtin literal that also happens to be portable.
That is besides the point. NULL is not C only. It is just as well C++, and pulling in a header for a language construct is nothing strange (see typeid()). And some think using NULL makes the code more readable. Of course, it has other problems as well (the 0 literal has these as well, but would make these more evident to the programmer), but that will be fixed with nullptr, in which case we will al be using 'nullptr' rather than '0'.

Quote

The macro assert(). Why?
I'm sorry, I misread your comment. I thought you said you didn't need <cassert> as assert() is not C++, but I see now that you meant that you should include <cassert> rather than <assert.h>. Of course I can do nothing other than to agree on that
C++ addict
-
Currently working on: the 3D engine for Tomb Raider.

### #23TheNut

Senior Member

• Moderators
• 1701 posts
• LocationCyberspace

Posted 23 October 2009 - 02:01 AM

Man, you guys need to get out more :lol:
http://www.nutty.ca - Being a nut has its advantages.

### #24phresnel

Member

• Members
• 47 posts

Posted 23 October 2009 - 08:35 AM

.oisyn said:

No, just wrong. "stdafx.h" is by no means "MSVC++ only"

Oops, okay. My intention was more to tell about #including unknown code, rather than to complain about what was MSVC once. Bad wording from my side.

Quote

I agree with you on this, but the point is that it is not wrong or evil to do otherwise (as opposed to putting a using directive in a header, which *is* evil). It's just a matter of taste.
Okay. My taste is to pollute namespaces and scope as sparse as possible. I think it makes my code more "future compatible".

Quote

And some think that you shouldn't use those names in the first place to avoid confusion.
But then the problem is that only the fewest know which words are reserved for the standard (I don't belong to them), and it doesn't help that every decade a plethora of new words are reserved. Especially the upcoming standard will describe a lot of new names, of which are some pretty common in some C++ milieus (e.g. I've seen several different mt19937 in the one or another path tracer implementation; I can only hope they [and me] did not use using namespace, as C++0x describes that name [for kicks, g++-4.4 -std=c++0x, header should be <random>], and many, many others).

Quote

That is besides the point. NULL is not C only. It is just as well C++, and pulling in a header for a language construct is nothing strange (see typeid()). And some think using NULL makes the code more readable. Of course, it has other problems as well (the 0 literal has these as well, but would make these more evident to the programmer), but that will be fixed with nullptr, in which case we will al be using 'nullptr' rather than '0'.
That's right. Though I think 0 vs. pointers is evident enough. I personally consider typeid() and NULL a bit, uhm, dirty, for you must include headers for them (in that respect, I find typeid() even dirtier -> typeid()=first class operator, but "return value" of it needs header :wacko: ). Okay, personal opinion.

TheNut said:

Man, you guys need to get out more
Where, ..., there are people? :ohmy:

joke aside, actually I have a significant other, enjoy pubs, and from time to time go for a walk: http://phresnel.deviantart.com/

~/www/ | picogen.org | metatrace
- --- / .-.. . - / -- -.-- / ... .. --. -. .- - ..- .-. . / .- .--. .--. . .- .-. / --. . . -.- -.--

### #25.oisyn

DevMaster Staff

• Moderators
• 1842 posts

Posted 23 October 2009 - 09:15 AM

TheNut said:

Man, you guys need to get out more

C++ addict
-
Currently working on: the 3D engine for Tomb Raider.

### #26poita

Senior Member

• Members
• 322 posts

Posted 24 October 2009 - 02:41 AM

Cool code, thanks for sharing. Recursive decent parsers are always fun.

Personally, I would change the interface of Parse to be:

const bool Parse(string::iterator first, string::iterator last)

or even better

template <class InputIter>
const bool Parse(InputIter first, InputIter last)`

This interface is more flexible, allowing people to parse substrings, or even lists of chars.

### #27v71

Valued Member

• Members
• 354 posts

Posted 24 October 2009 - 07:32 AM

Thanks for the hint, i am working for adding the ^ operator which i included but not added to the parser, and corrected the code to be more oop compliant, further more i would like to add math functions and the derivatie and integral operator, when its finished i will post it here again.

### #28Luz Reyes

Valued Member

• Members
• 112 posts

Posted 27 August 2010 - 10:08 PM

Oisyn that is hilarious! you are spot on, but sometimes i've been on both sides of that cartoon's computer scree, both correcting ppl and being corrected.

### #29v71

Valued Member

• Members
• 354 posts

Posted 28 August 2010 - 08:58 AM

I just want to point ouy that all those posts on gamedev were posted while i was away and someone used my account, only now taht i have seen this old post again i realized what the sarcasm was...

#### 1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users