5 ms·
That doesn’t prevent you from accessing global variables or reading member variables (which many const functions do). Marking a member function as const doesn’t
by jb1991 4y ago
That doesn’t prevent you from accessing global variables or reading member variables (which many const functions do). Marking a member function as const doesn’t in anyway guarantee purity, and is actually quite unrelated.
In fact, most const class functions are by definition not pure at all, because they will read internal state, otherwise they wouldn’t even need to be members of the class. So I would be willing to argue that nearly all const class functions are impure.
- zabzonk 4y agoum, i seriously doubt that many const functions access global variables. if those in your code do, then i suggest your code has problems - the typical use of a const function is doing something like length() does on a std::string. how, or why. would such a function access a global variable?
- jb1991 4y agoI agree, but most would access internal state, which is equally impure. A pure function has no access to anything outside of its function parameters, and it changes nothing outside the scope of the function. In the context of a pure function, a local member variable is no different than a global variable because it’s outside the scope of the actual function. If you can’t take the function away from the class and have it still work perfectly, then it’s not pure. length() is not pure, but a function like length(string) could be.
- zabzonk 4y agowhy do you think the length member function is not pure?
- jb1991 4y agoIf you read the article and see what pure functions are, you will understand. The length function has no parameters, by definition it must access data outside of the function if it’s going to do anything. This means it is not pure. Can you take that length function outside of the class and run it and have it do something? No, it is tightly coupled to the class that it is attached to.
- jb1991 4y agoIncidentally if this has whetted your appetite for functional programming, I encourage you to read a lot more about it and study languages that are truly functional. It could be quite liberating to see this approach to software development. It is not a panacea but it is a very useful perspective to acquire on software engineering, regardless of language, which is what this article discusses.
- zabzonk 4y agoi find this slightly patronising - i have studied languages such as scheme and haskell. and i don't see how writing a function such as length(string) could be pure if the member function length() was not, as you would pass a copy of the string (ok, pure) and then call a member function (impure, according to you) on it to actually get the length.
- jb1991 4y agoNo, you would not typically call a member function on anything in a pure language. Instead, you would pass a sequence of characters and the function would return the length, by counting them. I didn’t mean to sound patronizing, I apologize for that. Your question suggested that you aren’t that familiar with functional programming, so I was just trying to steer you in the right direction. A function that takes no parameters is not a pure function in general, unless all it does is return a constant value, which wouldn’t make much sense. length() does not make sense in a functional programming style.
- zabzonk 4y agowell, the length function for c++ strings does return a constant object - an integer value. and passing a sequence of characters? hello, C strlen( const char * s); ! with all the problems that has. and if you don't want to pass some horrible pointer, you have to pass some object containing the characters which must have a length function itself. hello, std::string! what you are ignoring here is how functional types either ignore functionality under the hood, or sacrifice it for performance. which is why functional programming will never catch on (look at lisps), imho. programmers really like to know wtf their code is actually doing on a mutable machine.
- dtho 4y agoMember functions have an invisible argument: the pointer to the C++ object. You can access this argument using the 'this' keyword. John Carmack describes pure functions like so: > Pure functions have a lot of nice properties. Thread safety. A pure function with value parameters is completely thread safe. With reference or pointer parameters, even if they are const, you do need to be aware of the danger that another thread doing non-pure operations might mutate or free the data, but it is still one of the most powerful tools for writing safe multithreaded code. Emphasis on 'value parameters'. The invisible 'this' argument is not passed by value, it is passed by reference. By Carmack's definition, C++ member functions are not pure.
- injidup 4y agothe instance of the class is a parameter to the function. As well your definition of pure is not the accepted definition. The definition depends absolutely nothing on the internal implementation as long as some in invariants hold. 1. For the given set of inputs ( including the attached object ) the output is always the same if called again with the same inputs ( including the attached object in the same state ). 2. No side effects. This means that nothing can be observed about the function apart from it's return value. If you wish to quibble as to whether the object is a parameter or not then observe that in c++23 it will be allowed an explicit this parameter to methods This is not to make the methods more pure but to enable other types of optimizations and reduce duplication of code over const and non const methods.
- jb1991 4y agoThat's an odd interpretation of purity. As per the article: > A pure function only looks at the parameters passed in to it, and all it does is return one or more computed values based on the parameters... It doesn’t maintain internal state... Ideally, it isn’t passed any extraneous data If you send in an entire object state as an argument (or as an attached instance, as you argue), this is not a quintessence of functional purity and strays far from these concepts. Consider: your object can have all sorts of data in it that you are passing to every member function, and it is unlikely all that state needs to be used in every function -- as the article points out, this defeats the purpose as it's akin to passing in a big pointer to a bunch of state. In a pure function, it accepts only the specific data it needs, nothing else or extraneous, and returns a value based on these specific inputs. As I mentioned in another comment, you could say for a particular type that since it only has one data member, no harm done -- but in the general sense, most objects have more than one piece of data, and not every function needs every piece of data, so passing all that in is a sloppy approach to purity.
- injidup 4y agoThe object state is a parameter passed to the function. The number of arguments passed to a function does not affect it's purity. The feed forward recognition phase of an LLM is pure but has billions of parameters. The purity is defined by it's behavior in relation to again. 1. Does it always return the same result for the same input parameters 2. Does it modify anything other than return a value These two properties define purity. Simple and not odd at all.