Hi I was wondering when is the appropriate place to use htmlspecialchars(). Is it before inserting data to database or when retrieving them from the database?

## Answers

The callback function passed to `array_walk`

expects the second parameter to be the key of the array element:

Typically,

funcnametakes on two parameters. Thearrayparameter's value being the first, and the key/index second.

But `htmlspecialchars`

expects the second parameter to be the quoting style (typically specified by one of the `ENT_*`

constants of the type integer).

Try `array_map`

instead. It just uses the array’s values.

There is only one, universal replacement character: U+FFFD. If you are writing out UTF-8, then this codepoint is appropriately encoded. If not, you get the corresponding character reference `�`

instead.

There is no reversible mapping. By definition, the original byte sequence was *invalid*, i.e. it does not *have* a value (valid = has a value).

Bytes (not really "characters") that are replaced are those that are not valid in the assumed source encoding. For example, if your source encoding was UTF-16 and you had a lone surrogate, that would be "invalid" (though technically any text processor is supposed to abort fatally in that situation). As a better example, if the source encoding is ASCII, then any value above 127 is an invalid character.

Avoiding the cost of a function call is only half the story.

do:

- use
`inline`

instead of`#define`

**very small**functions are good candidates for`inline`

: faster code and smaller executables (more chances to stay in the code cache)- the function is small
**and**called very often

don't:

- large functions: leads to larger executables, which significantly impairs performance regardless of the faster execution that results from the calling overhead
- inline functions that are I/O bound
- the function is seldom used
- constructors and destructors: even when empty, the compiler generates code for them
- breaking binary compatibility when developing libraries:
- inline an existing function
- change an inline function or make an inline function non-inline: prior version of the library call the old implementation

when developing a library, in order to make a class extensible in the future you should:

- add non-inline virtual destructor even if the body is empty
- make all constructors non-inline
- write non-inline implementations of the copy constructor and assignment operator unless the class cannot be copied by value

Remember that the `inline`

keyword is a hint to the compiler: the compiler may decide not to inline a function and it can decide to inline functions that were not marked `inline`

in the first place. I generally avoid marking function `inline`

(apart maybe when writing very very small functions).

About performance, the wise approach is (as always) to profile the application, then eventually `inline`

a set of functions representing a bottleneck.

References:

- To Inline or Not To Inline
- [9] Inline functions
- Policies/Binary Compatibility Issues With C++
- GotW #33: Inline
- Inline Redux
- Effective C++ - Item 33: Use inlining judiciously

EDIT: Bjarne Stroustrup, The C++ Programming Language:

A function can be defined to be

`inline`

. For example:

```
inline int fac(int n)
{
return (n < 2) ? 1 : n * fac(n-1);
}
```

The

`inline`

specifier is a hint to the compiler that it should attempt to generate code for a call of`fac()`

inline rather than laying down the code for the function once and then calling through the usual function call mechanism. A clever compiler can generate the constant`720`

for a call`fac(6)`

. The possibility of mutually recursive inline functions, inline functions that recurse or not depending on input, etc., makes it impossible to guarantee that every call of an`inline`

function is actually inlined. The degree of cleverness of a compiler cannot be legislated, so one compiler might generate`720`

, another`6 * fac(5)`

, and yet another an un-inlined call`fac(6)`

.To make inlining possible in the absence of unusually clever compilation and linking facilities, the definition–and not just the declaration–of an inline function must be in scope (§9.2). An

`inline`

especifier does not affect the semantics of a function. In particular, an inline function still has a unique address and so has`static`

variables (§7.1.2) of an inline function.

EDIT2: ISO-IEC 14882-1998, 7.1.2 Function specifiers

A function declaration (8.3.5, 9.3, 11.4) with an

`inline`

specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by 7.1.2 shall still be respected.

### Short answer

If 6 significant decimal digits are enough for you, `exp(x)-1`

is okay up to x being 1e-10. In general, you are going to lose N decimal digits of accuracy when x is about `10**(-N)`

. We start with about 16 digits in double precision.

Why not always use `expm1`

? Because `expm1(x) + 1`

has absolutely no benefit over `exp(x)`

, no matter how small `x`

is. It only makes sense to use `expm1`

when your computation actually requires something like `exp(x) - 1`

. One has to consider the wider context of the computation.

### Long answer

It's not really about how small x is, but about how `exp(x)`

is used in your computation. The purpose of `expm1`

should be understood in wider context of Loss of significance. Some formulas are subject to loss of significance for certain ranges of parameters; one has to analyze the formula to see if and when it happens. And if there is a potential loss of significance in some range, rework the formula into something algebraically equivalent but numerically stable. Wikipedia explains this well on the example of quadratic equation.

If your goal is to compute `exp(x)`

, or `3*exp(x) + 4`

or such, you should use `exp`

. There is no loss of significance here, and no benefit of putting `expm1`

in such a formula, regardless of how small `x`

is. Writing `expm1(x) + 1`

instead of `exp(x)`

is entirely pointless.

If your formula is `exp(x) - 1`

or `exp(x) - cos(x)`

, then there is potential loss of significance for small `x`

. This is not always a reason to rewrite; if you only plan to use this formula when x is 1 or more, there is no issue. If you are okay with *absolute error* being at machine epsilon level (1e-16 or so), and don't care much about *relative* error, there is no issue.

When the loss of significance occurs, it's up to the ultimate user of information to decide how much loss is acceptable. Often, getting 6 significant digits is quite enough for practical purposes, so losing 10 decimal digits out of double precision accuracy may be acceptable then. In this context, the formula `exp(x) - 1`

incurs unacceptable loss of precision when `x`

is smaller than `1e-10`

. Indeed, the value of `exp(x) - 1`

is close to `x`

but `exp(x)`

looks like 1.00000000... with 10 digits after dot being 0; so only 6 digits remain from x itself.

Rewriting functions in a numerically safer form requires some human effort, to work out whatever algebraic or trigonometric identities are needed. Examples of such rewriting:

```
f = lambda x: np.exp(x) - np.cos(x)
g = lambda x: np.sqrt(x**2 + 1) - 1
```

Numerically safer form of the above:

```
f_safe = lambda x: np.expm1(x) + 2*np.sin(x/2)**2
g_safe = lambda x: x / (np.sqrt(x**2 + 1) + 1)
```

Rewriting `np.exp(x) - np.cos(x)`

as `np.expmp(x) - np.cos(x) + 1`

would have no benefit at all; one has to think through the entire computation to eliminate the subtraction of nearly-equal numbers.

You should only call this method when echoing the data into HTML.

Don't store escaped HTML in your database; it will just make queries more annoying.

The database should store your actual data, not its HTML representation.