答:
Don't do this.  Plain and simple, that's a terrible data tier pattern.  It is bad for the following reasons:

Doesn't scale well at all (rows should be created with new data, not objects)

Data access patterns will suffer (it will be a pain, best case scenario, to construct your data queries.  Worst case scenario you will cause extremely poor performance and other possible side effects)

Not maintainable (it will be, again, a pain to even figure out creation and maintenance on things like indexes and statistics)

Lack of data rigidity (think about it, there is no enforced construct to say that all user transaction tables will have the same columns, data types, etc.  You could find yourself in a data consistency/purity problem quite quickly)

I haven't even brought up relational design and how this doesn't subscribe to the accepted constructs there.  But hopefully the supportability and programmability nightmare is enough to steer you away from this direction.

Not to mention... it's just hard.  Why make it more difficult on yourself, as the model of common tables for common data is just so simple and natural.


问:
Who is to blame for this range based for over a reference to temporary?
The following code looks rather harmless on first sight. A user uses the function bar() to interact with some library functionality. (This may have even worked for a long time since bar() returned a reference to a non-temporary value or similar.) Now however it is simply returning a new instance of B. B again has a function a() that returns a reference to an object of the iterateable type A. The user wants to query this object which leads to a segfault since the temporary B object returned by bar() is destroyed before the iteration begins.

I am indecisive who (library or user) is to blame for this.
All library provided classes look clean to me and certainly aren't doing anything different (returning references to members, returning stack instances, ...) than so much other code out there does.
The user doesn't seem to do anything wrong as well, he's just iterating over some object without doing anything concerning that objects lifetime.

(A related question might be: Should one establish the general rule that code shouldn't "range-based-for-iterate" over something that is retrieved by more than one chained calls in the loop header since any of these calls might return a rvalue?)

```<code>#include <algorithm>
#include <iostream>

// "Library code"
struct A
{
    A():
        v{0,1,2}
    {
        std::cout << "A()" << std::endl;
    }

    ~A()
    {
        std::cout << "~A()" << std::endl;
    }

    int * begin()
    {
        return &v[0];
    }

    int * end()
    {
        return &v[3];
    }

    int v[3];
};

struct B
{
    A m_a;

    A & a()
    {
        return m_a;
    }
};

B bar()
{
    return B();
}

// User code
int main()
{
    for( auto i : bar().a() )
    {
        std::cout << i << std::endl;
    }
}
</code>```

答:
I think the fundamental problem is a combination of language features (or lack thereof) of C++. Both the library code and the client code are reasonable (as evidenced by the fact that the problem is far from obvious). If the lifetime of the temporary B was suitable extended (to the end of the loop) there would be no problem.

Making temporaries life just long enough, and no longer, is extremely hard. Not even a rather ad-hoc "all temporaries involved in the creation of the range for a range-based for live until the end of the loop" would be without side effects. Consider the case of B::a() returning a range that's independent of the B object by value. Then the temporary B can be discarded immediately. Even if one could precisely identify the cases where a lifetime extension is necessary, as these cases are not obvious to programmers, the effect (destructors called much later) would be surprising and perhaps an equally subtle source of bugs.

It would be more desirable to just detect and forbid such nonsense, forcing the programmer to explicitly elevate bar() to a local variable. This is not possible in C++11, and probably never will be possible because it requires annotations. Rust does this, where the signature of .a() would be:

```<code>fn a<'x>(bar: &'x B) -> &'x A { bar.a }
// If we make it as explicit as possible, or
fn a(&self) -> &A { self.a }
// if we make it a method and rely on lifetime elision.
</code>```

Here 'x is a lifetime variable or region, which is a symbolic name for the period of time a resource is available. Frankly, lifetimes are hard to explain -- or we haven't yet figured out the best explanation -- so I will restrict myself to the minimum necessary for this example and refer the inclined reader to the official documentation.

The borrow checker would notice that the result of bar().a() needs to live as long as the loop runs. Phrased as a constraint on the lifetime 'x, we write: 'loop <= 'x. It would also notice that the receiver of the method call, bar(), is a temporary. The two pointers are associated with the same lifetime, hence 'x <= 'temp is another constraint.

These two constraints are contradictory! We need 'loop <= 'x <= 'temp but 'temp <= 'loop, which captures the problem pretty precisely. Because of the conflicting requirements, the buggy code is rejected. Note that this is a compile-time check and Rust code usually results to the same machine code as equivalent C++ code, so you need not pay a run-time cost for it.

Nevertheless this is a big feature to add to a language, and only works if all code uses it. the design of APIs is also affected (some designs that would be too dangerous in C++ become practical, others can't be made to play nice with lifetimes). Alas, that means it's not practical to add to C++ (or any language really) retroactively. In summary, the fault is on the inertia successful languages have and the fact that Bjarne in 1983 didn't have the crystal ball and foresight to incorporate the lessons of the last 30 years of research and C++ experience ;-)

Of course, that's not at all helpful in avoiding the problem in the future (unless you switch to Rust and never use C++ again). One could avoid longer expressions with multiple chained method calls (which is pretty limiting, and doesn't even remotely fix all lifetime troubles). Or one could try adopting a more disciplined ownership policy without compiler assistance: Document clearly that bar returns by value and that the result of B::a() must not outlive the B on which a() is invoked. When changing a function to return by value instead of a longer-lived reference, be conscious that this is a change of contract. Still error prone, but may speed up the process of identifying the cause when it does happen.

ContentLicense: CC BY-SA 3.0

Body:
I think the fundamental problem is a combination of language features (or lack thereof) of C++. Both the library code and the client code are reasonable (as evidenced by the fact that the problem is far from obvious). If the lifetime of the temporary B was suitable extended (to the end of the loop) there would be no problem.

Making temporaries life just long enough, and no longer, is extremely hard. Not even a rather ad-hoc "all temporaries involved in the creation of the range for a range-based for live until the end of the loop" would be without side effects. Consider the case of B::a() returning a range that's independent of the B object by value. Then the temporary B can be discarded immediately. Even if one could precisely identify the cases where a lifetime extension is necessary, as these cases are not obvious to programmers, the effect (destructors called much later) would be surprising and perhaps an equally subtle source of bugs.

It would be more desirable to just detect and forbid such nonsense, forcing the programmer to explicitly elevate bar() to a local variable. This is not possible in C++11, and probably never will be possible because it requires annotations. Rust does this, where the signature of .a() would be:

fn a<'x>(bar: &'x B) -> &'x A { bar.a }
// If we make it as explicit as possible, or
fn a(&self) -> &A { self.a }
// if we make it a method and rely on lifetime elision.

Here 'x is a lifetime variable or region, which is a symbolic name for the period of time a resource is available. Frankly, lifetimes are hard to explain -- or we haven't yet figured out the best explanation -- so I will restrict myself to the minimum necessary for this example and refer the inclined reader to the official documentation.

The borrow checker would notice that the result of bar().a() needs to live as long as the loop runs. Phrased as a constraint on the lifetime 'x, we write: 'loop <= 'x. It would also notice that the receiver of the method call, bar(), is a temporary. The two pointers are associated with the same lifetime, hence 'x <= 'temp is another constraint.

These two constraints are contradictory! We need 'loop <= 'x <= 'temp but 'temp <= 'loop, which captures the problem pretty precisely. Because of the conflicting requirements, the buggy code is rejected. Note that this is a compile-time check and Rust code usually results to the same machine code as equivalent C++ code, so you need not pay a run-time cost for it.

Nevertheless this is a big feature to add to a language, and only works if all code uses it. the design of APIs is also affected (some designs that would be too dangerous in C++ become practical, others can't be made to play nice with lifetimes). Alas, that means it's not practical to add to C++ (or any language really) retroactively. In summary, the fault is on the inertia successful languages have and the fact that Bjarne in 1983 didn't have the crystal ball and foresight to incorporate the lessons of the last 30 years of research and C++ experience ;-)

Of course, that's not at all helpful in avoiding the problem in the future (unless you switch to Rust and never use C++ again). One could avoid longer expressions with multiple chained method calls (which is pretty limiting, and doesn't even remotely fix all lifetime troubles). Or one could try adopting a more disciplined ownership policy without compiler assistance: Document clearly that bar returns by value and that the result of B::a() must not outlive the B on which a() is invoked. When changing a function to return by value instead of a longer-lived reference, be conscious that this is a change of contract. Still error prone, but may speed up the process of identifying the cause when it does happen.


问:
Coding style issue: Should we have functions which take a parameter, modify it, and then RETURN that parameter?
I'm having a bit of a debate with my friend over whether these two practices are merely two sides of the same coin, or whether one is genuinely better.

We have a function which takes a parameter, fills out a member of it, and then returns it:

```<code>Item predictPrice(Item item)
</code>```

I believe that as it works on the same object that is passed in, there is no point going on to return the item. In fact, if anything, from the perspective of the caller, it confuses matters as you could expect it to return a new item which it doesn't.

He claims that it makes no difference, and it wouldn't even matter if it did create a new Item and return that. I strongly disagree, for the following reasons:

If you have multiple references to the item passes in (or pointers or whatever), it allocating a new object and returning it is of material importance as those references will be incorrect.

In non-memory managed languages, the function allocating a new instance claims ownership of the memory, and thus we would have to implement a cleanup method which is called at some point.

Allocating on the heap is potentially expensive, and therefore it is important to whether the called function does that.

Hence, I believe it to be very important to be able to see via a methods signature whether it modifies an object, or allocates a new one. As a result, I believe that as the function merely modifies the object passed in, the signature should be:

```<code>void predictPrice(Item item)
</code>```

In every codebase (admittedly C and C++ codebases, not Java which is the language we are working in) I have worked with, the above style has essentially been adhered to, and kept to by considerably more experienced programmers. He claims that as my sample size of codebases and colleagues is small out of all the possible codebases and colleagues, and thus my experience is no true indicator over whether one is superior.

So, any thoughts?

答:
This really is a matter of opinion, but for what it's worth, I find it misleading to return the modified item if the item is modified in place. Separately, if predictPrice is going to modify the item, it should have a name that indicates it's going to do that (like setPredictPrice or some such).

I would prefer (in order)

That predictPrice was a method of Item (modulo a good reason for it not to be, which there could well be in your overall design) which either

Returned the predicted price, or

Had a name like setPredictedPrice instead

That predictPrice didn't modify Item, but returned the predicted price

That predictPrice was a void method called setPredictedPrice

That predictPrice returned this (for method chaining to other methods on whatever instance it's a part of) (and was called setPredictedPrice)


答:
Within an object oriented design paradigm, things shouldn't be modifying objects outside of the object itself.  Any changes to the state of an object should be done through methods on the object.

Thus, void predictPrice(Item item) as a member function of some other class is wrong.  Could have been acceptable in the days of C, but for Java and C++, the modifications of an object imply a deeper coupling to the object that would likely lead to other design issues down the road (when you refactor the class and change its fields, now that 'predictPrice' needs to be changed to in some other file.

Returning back a new object, doesn't have associated side effects, the parameter passed in is not changed.  You (the predictPrice method) don't know where else that parameter is used.  Is Item a key to a hash somewhere? did you change its hash code in doing this? Is someone else holding on to it expecting it not to change?

These design issues are ones that strongly suggest that you shouldn't be modifying objects (I'd argue for immutability in many cases), and if you do, the changes to the state should be contained and controlled by the object itself rather than something else outside of the class.

Lets look at what happens if one fiddles with the fields of something in a hash.  Lets take some code:

import java.util.*;

public class Main {
    public static void main (String[] args) {
        Set set = new HashSet();
        Data d = new Data(1,"foo");
        set.add(d);
        set.add(new Data(2,"bar"));
        System.out.println(set.contains(d));
        d.field1 = 2;
        System.out.println(set.contains(d));
    }

    public static class Data {
        int field1;
        String field2;

        Data(int f1, String f2) {
            field1 = f1;
            field2 = f2;
        }

        public int hashCode() {
            return field2.hashCode() + field1;
        }

        public boolean equals(Object o) {
            if(!(o instanceof Data)) return false;
            Data od = (Data)o;
            return od.field1 == this.field1 && od.field2.equals(this.field2);

        }
    }
}
```

<p><sup>ideone</sup></p>

<p>And I'll admit that this isn't the greatest code (directly accessing fields), but it serves its purpose of demonstrating an issue with mutable data being used as a key to a HashMap, or in this case, just being put into a HashSet.</p>

<p>The output of this code is:</p>

```true
false
```

What has happened is that the hashCode used when it was inserted is where the object is in the hash.  Changing the values used to compute the hashCode doesn't recompute the hash itself.  This is a danger of putting any mutable object as a key to a hash.

Thus, going back to the original aspect of the question, the method being called doesn't "know" how the object it is getting as a parameter is being used. Providing the "lets mutate the object" as the only way to do this means that there are a number of subtle bugs that can creep in. Like losing values in a hash... unless you add more and the hash gets rehashed - trust me, thats a nasty bug to hunt down (I lost the value until I add 20 more items to the hashMap and then suddenly it shows up again).

Unless there is very good reason to modify the object, returning a new object is the safest thing to do.

When there is a good reason to modify the object, that modification should be done by the object itself (invoking methods) rather than through some external function that can twiddle its fields.

This allows the object to be refactored with a lower maintenance cost.

This allows the object to make sure that the values that compute its hashcode don't change (or are not part of its hashcode calculation)

Related: Overwriting and returning the value of the argument used as conditional of an if statement, inside the same if statement

Title: Coding style issue: Should we have functions which take a parameter, modify it, and then RETURN that parameter?

Body:
I'm having a bit of a debate with my friend over whether these two practices are merely two sides of the same coin, or whether one is genuinely better.

We have a function which takes a parameter, fills out a member of it, and then returns it:

```<code>Item predictPrice(Item item)
</code>```

I believe that as it works on the same object that is passed in, there is no point going on to return the item. In fact, if anything, from the perspective of the caller, it confuses matters as you could expect it to return a new item which it doesn't.

He claims that it makes no difference, and it wouldn't even matter if it did create a new Item and return that. I strongly disagree, for the following reasons:

If you have multiple references to the item passes in (or pointers or whatever), it allocating a new object and returning it is of material importance as those references will be incorrect.

In non-memory managed languages, the function allocating a new instance claims ownership of the memory, and thus we would have to implement a cleanup method which is called at some point.

Allocating on the heap is potentially expensive, and therefore it is important to whether the called function does that.

Hence, I believe it to be very important to be able to see via a methods signature whether it modifies an object, or allocates a new one. As a result, I believe that as the function merely modifies the object passed in, the signature should be:

```<code>void predictPrice(Item item)
</code>```

In every codebase (admittedly C and C++ codebases, not Java which is the language we are working in) I have worked with, the above style has essentially been adhered to, and kept to by considerably more experienced programmers. He claims that as my sample size of codebases and colleagues is small out of all the possible codebases and colleagues, and thus my experience is no true indicator over whether one is superior.

So, any thoughts?

Body:
Within an object oriented design paradigm, things shouldn't be modifying objects outside of the object itself.  Any changes to the state of an object should be done through methods on the object.

Thus, void predictPrice(Item item) as a member function of some other class is wrong.  Could have been acceptable in the days of C, but for Java and C++, the modifications of an object imply a deeper coupling to the object that would likely lead to other design issues down the road (when you refactor the class and change its fields, now that 'predictPrice' needs to be changed to in some other file.

Returning back a new object, doesn't have associated side effects, the parameter passed in is not changed.  You (the predictPrice method) don't know where else that parameter is used.  Is Item a key to a hash somewhere? did you change its hash code in doing this? Is someone else holding on to it expecting it not to change?

These design issues are ones that strongly suggest that you shouldn't be modifying objects (I'd argue for immutability in many cases), and if you do, the changes to the state should be contained and controlled by the object itself rather than something else outside of the class.

Lets look at what happens if one fiddles with the fields of something in a hash.  Lets take some code:

import java.util.*;

public class Main {
    public static void main (String[] args) {
        Set set = new HashSet();
        Data d = new Data(1,"foo");
        set.add(d);
        set.add(new Data(2,"bar"));
        System.out.println(set.contains(d));
        d.field1 = 2;
        System.out.println(set.contains(d));
    }

    public static class Data {
        int field1;
        String field2;

        Data(int f1, String f2) {
            field1 = f1;
            field2 = f2;
        }

        public int hashCode() {
            return field2.hashCode() + field1;
        }

        public boolean equals(Object o) {
            if(!(o instanceof Data)) return false;
            Data od = (Data)o;
            return od.field1 == this.field1 && od.field2.equals(this.field2);

        }
    }
}

ideone

And I'll admit that this isn't the greatest code (directly accessing fields), but it serves its purpose of demonstrating an issue with mutable data being used as a key to a HashMap, or in this case, just being put into a HashSet.

The output of this code is:

true
false

What has happened is that the hashCode used when it was inserted is where the object is in the hash.  Changing the values used to compute the hashCode doesn't recompute the hash itself.  This is a danger of putting any mutable object as a key to a hash.

Thus, going back to the original aspect of the question, the method being called doesn't "know" how the object it is getting as a parameter is being used. Providing the "lets mutate the object" as the only way to do this means that there are a number of subtle bugs that can creep in. Like losing values in a hash... unless you add more and the hash gets rehashed - trust me, thats a nasty bug to hunt down (I lost the value until I add 20 more items to the hashMap and then suddenly it shows up again).

Unless there is very good reason to modify the object, returning a new object is the safest thing to do.

When there is a good reason to modify the object, that modification should be done by the object itself (invoking methods) rather than through some external function that can twiddle its fields.

This allows the object to be refactored with a lower maintenance cost.

This allows the object to make sure that the values that compute its hashcode don't change (or are not part of its hashcode calculation)

Related: Overwriting and returning the value of the argument used as conditional of an if statement, inside the same if statement


答:
While I have not a strong preference, I would vote that returning the object leads to better flexibility for an API.

Note that it has sense only while the method has freedom to return other object. If your javadoc says @returns the same value of parameter a then it is useless. But if your javadoc says @return an instance that holds the same data than parameter a, then returning the same instance or another one is an implementation detail.

For example, in my current project (Java EE) I have a business layer; to store in DB(and assign an automatic ID) an Employee, say, an employee I have something like

```<code> public Employee createEmployee(Employee employeeData) {
   this.entityManager.persist(employeeData);
   return this.employeeData;
 }
</code>```

Of course, no difference with this implementation because JPA returns the same object after assigning the Id. Now, if I switched to JDBC

```<code> public Employee createEmployee(Employee employeeData) {
   PreparedStatement ps = this.connection.prepareStatement("INSERT INTO EMPLOYEE(name, surname, data) VALUES(?, ?, ?)");
   ... // set parameters
   ps.execute();
   int id = getIdFromGeneratedKeys(ps);
   ??????
 }
</code>```

Now, at ????? I have three options.

Define a setter for Id, and I'll be returning the same object. Ugly, because setId will be available everywhere.

Do some heavy reflection work and set the id in the Employee object. Dirty, but at least it is limited to the createEmployee record.

Provide a constructor that copies the original Employee and accepts also the id to set.

Retrieve the object from DB (maybe needed if some field values are calculated in the DB, or if you wish to populate a realtionship).

Now, for 1. and 2. you may be returning the same instance, but for 3. and 4. you will be returning new instances. If from the principe you stablished in your API that the "real" value will be the one returned by the method, you have more freedom.

The only real argument I can think against that is that, using implementatios 1. or 2., people using your API may overlook the assignation of the result and their code would break if you change to 3. or 4. implementations).

Anyway, as you can see, my preference is based in other personal preferences (like forbidding a setter for Ids), so maybe it won't apply to everyone.

Body:
While I have not a strong preference, I would vote that returning the object leads to better flexibility for an API.

Note that it has sense only while the method has freedom to return other object. If your javadoc says @returns the same value of parameter a then it is useless. But if your javadoc says @return an instance that holds the same data than parameter a, then returning the same instance or another one is an implementation detail.

For example, in my current project (Java EE) I have a business layer; to store in DB(and assign an automatic ID) an Employee, say, an employee I have something like

 public Employee createEmployee(Employee employeeData) {
   this.entityManager.persist(employeeData);
   return this.employeeData;
 }

Of course, no difference with this implementation because JPA returns the same object after assigning the Id. Now, if I switched to JDBC

 public Employee createEmployee(Employee employeeData) {
   PreparedStatement ps = this.connection.prepareStatement("INSERT INTO EMPLOYEE(name, surname, data) VALUES(?, ?, ?)");
   ... // set parameters
   ps.execute();
   int id = getIdFromGeneratedKeys(ps);
   ??????
 }

Now, at ????? I have three options.

Define a setter for Id, and I'll be returning the same object. Ugly, because setId will be available everywhere.

Do some heavy reflection work and set the id in the Employee object. Dirty, but at least it is limited to the createEmployee record.

Provide a constructor that copies the original Employee and accepts also the id to set.

Retrieve the object from DB (maybe needed if some field values are calculated in the DB, or if you wish to populate a realtionship).

Now, for 1. and 2. you may be returning the same instance, but for 3. and 4. you will be returning new instances. If from the principe you stablished in your API that the "real" value will be the one returned by the method, you have more freedom.

The only real argument I can think against that is that, using implementatios 1. or 2., people using your API may overlook the assignation of the result and their code would break if you change to 3. or 4. implementations).

Anyway, as you can see, my preference is based in other personal preferences (like forbidding a setter for Ids), so maybe it won't apply to everyone.


问:
Why does UTF-8 waste several bits in its encoding
According to the Wikipedia article, UTF-8 has this format:

```
First code Last code Bytes Byte 1    Byte 2    Byte 3    Byte 4
point      point     Used
U+0000     U+007F    1     0xxxxxxx
U+0080     U+07FF    2     110xxxxx  10xxxxxx
U+0800     U+FFFF    3     1110xxxx  10xxxxxx  10xxxxxx
U+10000    U+1FFFFF  4     11110xxx  10xxxxxx  10xxxxxx  10xxxxxx
x means that this bit is used to select the code point.
```

This wastes two bits on each continuation byte and one bit in the first byte. Why is UTF-8 not encoded like the following?

```
First code Last code Bytes Byte 1    Byte 2    Byte 3
point      point     Used
U+0000     U+007F    1     0xxxxxxx
U+0080     U+3FFF    2     10xxxxxx  xxxxxxxx
U+0800     U+1FFFFF  3     110xxxxx  xxxxxxxx  xxxxxxxx
```

It would save one byte when the code point is out of the Basic Multilingual Plane or if the code point is in range [U+800,U+3FFF].

Why is UTF-8 not encoded in a more efficient way?

答: The official way lets the decoder know when it's in the middle of the tuple and it knows to skip bytes (or go backwards) until the byte starts with 0 or 11; this prevents garbage values when a single byte gets corrupted.


答:
This is done so that you can detect when you are in the middle of a multi-byte sequence.  When looking at UTF-8 data, you know that if you see 10xxxxxx, that you are in the middle of a multibyte character, and should back up in the stream until you see either 0xxxxxx or 11xxxxxx.  Using your scheme, bytes 2 or 3 could easily end up with patters like either 0xxxxxxx or 11xxxxxx

Also keep in mind that how much is saved varies entirely on what sort of string data you are encoding.  For most text, even Asian text, you will rarely if ever see four byte characters with normal text.  Also, people's naive estimates about how text will look are often wrong.  I have text localized for UTF-8 that includes Japanese, Chinese and Korean strings, yet it is actually Russian that takes most space.  (Because our Asian strings often have Roman characters interspersed for proper names, punctuation and such and because the average Chinese word is 1-3 characters while the average Russian word is many, many more.)

Title: Why does UTF-8 waste several bits in its encoding

Body:
According to the Wikipedia article, UTF-8 has this format:

```
First code Last code Bytes Byte 1    Byte 2    Byte 3    Byte 4
point      point     Used
U+0000     U+007F    1     0xxxxxxx
U+0080     U+07FF    2     110xxxxx  10xxxxxx
U+0800     U+FFFF    3     1110xxxx  10xxxxxx  10xxxxxx
U+10000    U+1FFFFF  4     11110xxx  10xxxxxx  10xxxxxx  10xxxxxx
x means that this bit is used to select the code point.
```

This wastes two bits on each continuation byte and one bit in the first byte. Why is UTF-8 not encoded like the following?

```
First code Last code Bytes Byte 1    Byte 2    Byte 3
point      point     Used
U+0000     U+007F    1     0xxxxxxx
U+0080     U+3FFF    2     10xxxxxx  xxxxxxxx
U+0800     U+1FFFFF  3     110xxxxx  xxxxxxxx  xxxxxxxx
```

It would save one byte when the code point is out of the Basic Multilingual Plane or if the code point is in range [U+800,U+3FFF].

Why is UTF-8 not encoded in a more efficient way?


答:
Short answer, your proposal does not differentiate between the first byte and continuation bytes.

The bit pattern at the high end of the first byte tells you with how many bytes the actual character is built. These patterns provide also some error recognition while parsing a string. If you are reading the (seemingly) first byte of a character and you get 10xxxxxx then you know that you are out of synch.


问:
Which design pattern is more suitable for logging?
I should log some events in a program but as far as I know it would be better to keep the logging code outside the program because it is not about the real functionality of the program. So may you tell me if I should keep it completely out of code and only use Observers and Listeners to log the events? Or I can add a line of code like the following wherever I need to log something:

```<code>MyGloriousLogger.getXXXLogger().Log(LogPlace, new LogObject(z1, z2, z3, z4, ..., z99));
</code>```

Do I make a mistake to use Observer design pattern? I need another design pattern? Or I should stop thinking about design patterns?

PS1. If I want to log using only listeners and observers I will certainly need to add and improve the observers and listeners of the program.

PS2. I certainly know that there are different libraries for logging in Java and I'm using java.utils.logging but I need to have a wrapper for it to log my special objects.

答:
Chain of responsibility seems to be a good pattern when your output can landup at multiple places.
In the UML you have different logger one that directs to console, other to errorFile and 3rd simply info logger.

Usually I have seen that logLevels are different but the logging file is same.

I don't see observer pattern as bad for logging as it decouples your logging code from application code.
Which is a good practise, migrating to different logging mechanisms is easy this way.
Every time you want to log, fire an event and the appropriate listener will recieve the event and log it.
There should be an intermediate singleton object that holds the list of all registers.

This way I see that we can decouple our logging code from application code.


答:
Can we solve this issue using C++ features?

C++11 has added member function ref-qualifiers, which allows restricting the value category of the class instance (expression) the member function can be called on. For example:

```<code>struct foo {
    void bar() & {} // lvalue-ref-qualified
};

foo& lvalue ();
foo  prvalue();

lvalue ().bar(); // OK
prvalue().bar(); // error
</code>```

When calling the begin member function, we know that most likely we'll also need to call the end member function (or something like size, to get the size of the range). This requires that we operate on an lvalue, since we need to address it twice. You can therefore argue that these member functions should be lvalue-ref-qualified.

However, this might not solve the underlying issue: aliasing. The begin and end member function alias the object, or the resources managed by the object. If we replace begin and end by a single function range, we should provide one that can be called on rvalues:

```<code>struct foo {
    vector<int> arr;

    auto range() & // C++14 return type deduction for brevity
    { return std::make_pair(arr.begin(), arr.end()); }
};

for(auto const& e : foo().range()) // error
</code>```

This might be a valid use case, but the above definition of range disallows it. Since we cannot address the temporary after the member function call, it might be more reasonable to return a container, i.e. an owning range:

```<code>struct foo {
    vector<int> arr;

    auto range() &
    { return std::make_pair(arr.begin(), arr.end()); }

    auto range() &&
    { return std::move(arr); }
};

for(auto const& e : foo().range()) // OK
</code>```

Applying this to the OP's case, and slight code review

```<code>struct B {
    A m_a;
    A & a() { return m_a; }
};
</code>```

This member function changes the value category of the expression: B() is a prvalue, but B().a() is an lvalue. On the other hand, B().m_a is an rvalue. So let's start by making this consistent. There are two ways to do this:

```<code>struct B {
    A m_a;
    A &  a() &  { return m_a; }

    A && a() && { return std::move(m_a); }
    // or
    A    a() && { return std::move(m_a); }
};
</code>```

The second version, as said above, will fix the issue in the OP.

Additionally, we can restrict B's member functions:

```<code>struct A {
    // [...]

    int * begin() & { return &v[0]; }
    int * end  () & { return &v[3]; }

    int v[3];
};
</code>```

This won't have any impact on the OP's code, since the result of the expression after the : in the range-based for loop is bound to a reference variable. And this variable (as an expression used to access its begin and end member functions) is an lvalue.

Of course, the question is whether or not the default rule should be "aliasing member functions on rvalues should return an object which owns all its resources, unless there's a good reason not to". The alias it returns can legally be used, but is dangerous in the way you're experiencing it: it cannot be used to extend the lifetime of its "parent" temporary:

```<code>// using the OP's definition of `struct B`,
// or version 1, `A && a() &&;`

A&&      a = B().a(); // bug: binds directly, dangling reference
A const& a = B().a(); // bug: same as above
A        a = B().a(); // OK

A&&      a = B().m_a; // OK: extends the lifetime of the temporary
</code>```

In C++2a, I think you're supposed to work around this (or a similar) issue as follows:

```<code>for( B b = bar(); auto i : b.a() )
</code>```

instead of the OP's

```<code>for( auto i : bar().a() )
</code>```

The workaround manually specifies that the lifetime of b is the entire block of the for-loop.

Proposal which introduced this init-statement

Live Demo

Title: Who is to blame for this range based for over a reference to temporary?

Body:
The following code looks rather harmless on first sight. A user uses the function bar() to interact with some library functionality. (This may have even worked for a long time since bar() returned a reference to a non-temporary value or similar.) Now however it is simply returning a new instance of B. B again has a function a() that returns a reference to an object of the iterateable type A. The user wants to query this object which leads to a segfault since the temporary B object returned by bar() is destroyed before the iteration begins.

I am indecisive who (library or user) is to blame for this.
All library provided classes look clean to me and certainly aren't doing anything different (returning references to members, returning stack instances, ...) than so much other code out there does.
The user doesn't seem to do anything wrong as well, he's just iterating over some object without doing anything concerning that objects lifetime.

(A related question might be: Should one establish the general rule that code shouldn't "range-based-for-iterate" over something that is retrieved by more than one chained calls in the loop header since any of these calls might return a rvalue?)

```<code>#include <algorithm>
#include <iostream>

// "Library code"
struct A
{
    A():
        v{0,1,2}
    {
        std::cout << "A()" << std::endl;
    }

    ~A()
    {
        std::cout << "~A()" << std::endl;
    }

    int * begin()
    {
        return &v[0];
    }

    int * end()
    {
        return &v[3];
    }

    int v[3];
};

struct B
{
    A m_a;

    A & a()
    {
        return m_a;
    }
};

B bar()
{
    return B();
}

// User code
int main()
{
    for( auto i : bar().a() )
    {
        std::cout << i << std::endl;
    }
}
</code>```

Body:
Can we solve this issue using C++ features?

C++11 has added member function ref-qualifiers, which allows restricting the value category of the class instance (expression) the member function can be called on. For example:

struct foo {
    void bar() & {} // lvalue-ref-qualified
};

foo& lvalue ();
foo  prvalue();

lvalue ().bar(); // OK
prvalue().bar(); // error

When calling the begin member function, we know that most likely we'll also need to call the end member function (or something like size, to get the size of the range). This requires that we operate on an lvalue, since we need to address it twice. You can therefore argue that these member functions should be lvalue-ref-qualified.

However, this might not solve the underlying issue: aliasing. The begin and end member function alias the object, or the resources managed by the object. If we replace begin and end by a single function range, we should provide one that can be called on rvalues:

struct foo {
    vector<int> arr;

    auto range() & // C++14 return type deduction for brevity
    { return std::make_pair(arr.begin(), arr.end()); }
};

for(auto const& e : foo().range()) // error

This might be a valid use case, but the above definition of range disallows it. Since we cannot address the temporary after the member function call, it might be more reasonable to return a container, i.e. an owning range:

struct foo {
    vector<int> arr;

    auto range() &
    { return std::make_pair(arr.begin(), arr.end()); }

    auto range() &&
    { return std::move(arr); }
};

for(auto const& e : foo().range()) // OK

Applying this to the OP's case, and slight code review

struct B {
    A m_a;
    A & a() { return m_a; }
};

This member function changes the value category of the expression: B() is a prvalue, but B().a() is an lvalue. On the other hand, B().m_a is an rvalue. So let's start by making this consistent. There are two ways to do this:

struct B {
    A m_a;
    A &  a() &  { return m_a; }

    A && a() && { return std::move(m_a); }
    // or
    A    a() && { return std::move(m_a); }
};

The second version, as said above, will fix the issue in the OP.

Additionally, we can restrict B's member functions:

struct A {
    // [...]

    int * begin() & { return &v[0]; }
    int * end  () & { return &v[3]; }

    int v[3];
};

This won't have any impact on the OP's code, since the result of the expression after the : in the range-based for loop is bound to a reference variable. And this variable (as an expression used to access its begin and end member functions) is an lvalue.

Of course, the question is whether or not the default rule should be "aliasing member functions on rvalues should return an object which owns all its resources, unless there's a good reason not to". The alias it returns can legally be used, but is dangerous in the way you're experiencing it: it cannot be used to extend the lifetime of its "parent" temporary:

// using the OP's definition of `struct B`,
// or version 1, `A && a() &&;`

A&&      a = B().a(); // bug: binds directly, dangling reference
A const& a = B().a(); // bug: same as above
A        a = B().a(); // OK

A&&      a = B().m_a; // OK: extends the lifetime of the temporary

In C++2a, I think you're supposed to work around this (or a similar) issue as follows:

for( B b = bar(); auto i : b.a() )

instead of the OP's

for( auto i : bar().a() )

The workaround manually specifies that the lifetime of b is the entire block of the for-loop.

Proposal which introduced this init-statement

Live Demo

ContentLicense: CC BY-SA 4.0


问:
Is it bad to feel guilty using lots of libraries?
So I'm an android programmer,have been programming for about 3 years,but it wasn't until 5 months ago that I started really taking it seriously. Recently I got my first internship,and I'm happy with it. The problem that I'm having is that I worry a lot about using too many libraries for certain tasks whether it be complex or simple. I tend to think,"If they can do that,maybe I can take time out of my day to learn how to do all that myself". Should I feel guilty for using "too many" libraries? </p>

答: No. As a programmer, your real job is to solve problems. Use basically any legal and ethical means at your disposal to efficiently solve the problem in a maintainable way.</p>


问:
Is it imaginable to teach a machine how to program itself to a defined specification?
A friend of mine without programming knowledge asked me this question and I found it interesting.

I think it is not possible because it would require a really advanced artificial intelligence capable of analyzing the text of a problem, think about a solution and program it. Just thinking about a machine being able to program a simple calculator seems pretty advanced to me.

But maybe I'm wrong and I would like to know what do you think about it and if you are aware of any articles/researches on the subject, or if it already exists or if the possibility exists of selecting a specification, and getting the machine to self-program to this "spec?"

2023 EDIT: GPT-4 ;-)

答:
Sure, we do this all the time (for extremely limited subsets of problems). It is fairly trivial to imagine taking another step or two and tying something like Siri into the input of these code generators (or something like Wolfram Alpha) which in turn writes code and solves your problem. I would expect that something already exists somewhere to do the most basic of things.

The problem with writing complex software for business isn't making a program to write the code - it's writing a program to get the requirements.


答:
Joel actually answered this one a few years back.  The actual meaning of "teach a machine how to program by itself" is "teach a machine how to take a spec and create a program that corresponds to that spec."  And with that in mind:

The problem, here, is very fundamental. In order to mechanically prove
  that a program corresponds to some spec, the spec itself needs to be
  extremely detailed. In fact the spec has to define everything about
  the program, otherwise, nothing can be proven automatically and
  mechanically. Now, if the spec does define everything about how the
  program is going to behave, then, lo and behold, it contains all the
  information necessary to generate the program! And now certain geeks
  go off to a very dark place where they start thinking about
  automatically compiling specs into programs, and they start to think
  that they’ve just invented a way to program computers without
  programming.

Now, this is the software engineering equivalent of a perpetual motion
  machine. It’s one of those things that crackpots keep trying to do, no
  matter how much you tell them it could never work. If the spec defines
  precisely what a program will do, with enough detail that it can be
  used to generate the program itself, this just begs the question: how
  do you write the spec? Such a complete spec is just as hard to write
  as the underlying computer program, because just as many details have
  to be answered by spec writer as the programmer. To use terminology
  from information theory: the spec needs just as many bits of Shannon
  entropy as the computer program itself would have. Each bit of entropy
  is a decision taken by the spec-writer or the programmer.

So, the bottom line is that if there really were a mechanical way to
  prove things about the correctness of a program, all you’d be able to
  prove is whether that program is identical to some other program that
  must contain the same amount of entropy as the first program,
  otherwise some of the behaviors are going to be undefined, and thus
  unproven. So now the spec writing is just as hard as writing a
  program, and all you’ve done is moved one problem from over here to
  over there, and accomplished nothing whatsoever.

The only way to get around this would be to produce an actual sapient computer with enough intuition to do all the filling-in-of-blanks that you and I do automatically, all the time, when producing software... in which case you'd end up with a computer that programs itself about as well as a human developer. ;)

Title: Is it imaginable to teach a machine how to program itself to a defined specification?

Body:
A friend of mine without programming knowledge asked me this question and I found it interesting.

I think it is not possible because it would require a really advanced artificial intelligence capable of analyzing the text of a problem, think about a solution and program it. Just thinking about a machine being able to program a simple calculator seems pretty advanced to me.

But maybe I'm wrong and I would like to know what do you think about it and if you are aware of any articles/researches on the subject, or if it already exists or if the possibility exists of selecting a specification, and getting the machine to self-program to this "spec?"

2023 EDIT: GPT-4 ;-)


问:
Quantum computers and Turing Machine
As far as I know, a Turing Machine is the widely used model in computational theory to know whether something could be computed and if computed can they can be computed in finite time (P, NP, NPSpace). But I have the following doubts:

Is a Turing Machine essentially a black-box model where a set of inputs give a set of outputs such that there could be no interaction during computation? By no interaction, I mean that during computation the variables wouldn't be altered by an external factor.

As an extension to the above question, are non-deterministic functions Turing complete?

Is Turing Machine an efficient model for Quantum Computing?

Going by what I have learned so far, my answers are:

Turing Machines cannot handle interaction and random behavior and it's not guaranteed even by Turing in his original paper.

Non-deterministic functions may bring Turing machines to a halt.

No since Turing machines cannot efficiently support the superposition of bits.

Note

I am not well-versed in either Computational Theory or Quantum Computing. So a lot of links and some beginner's stuff would be a lot helpful and reading this article inspired this question.

答: Although quantum computers may be faster than classical computers, they can't solve any problems that classical computers can't solve. A Turing machine can simulate these quantum computers, so such a quantum computer could never solve an undecidable problem like the halting problem. There is a common misconception that quantum computers can solve NP-complete problems in polynomial time. That is not known to be true, and is generally suspected to be false. The existence of "standard" quantum computers does not disprove the Church–Turing thesis. The D-Wave machine is solving problems using quantum technology but it is not a "general purpose" or standard computer in any sense of the term. That it does what it is doing is great and it will be fascinating to see what the future brings. See the references cited in the Wikipedia entry.</p>

Title: Quantum computers and Turing Machine


答:
I think @Mason Wheeler's answer holds the key idea. It goes like this:

The Shannon entropy of Tic-tac-toe is really small. So we call tic-tac-toe a "solved" or "deterministic" game. It's not really interesting once you get past grade school. Checkers has a higher entropy, if you consider the entropy of all the possible games you can play. But checkers, too, is a "solved" or "deterministic" game. If you move first, you should only win or draw. Chess has a much, much higher entropy, but no human has beat the best computer players since 2006. So, in a way, computers have mastered chess in a way that humans cannot. Big Blue analyzed wikipedia, and then played Jeopardy against human players, and beat them soundly.

What's next? What's the entropy of a novel, or Shakepeare's sonnets?

Similarly, in the programming space, what will probably emerge is an increasing set of competencies. Prolog addressed a set of computer problems where you set up problem and the computer resolved the answer. Someone will probably find classes of simple programming problems that a computer will be able to satisfy, etc. Then someone will build on that to produce "on demand customization" within some problem space. And so it goes.

I think the question turns into, how long does it take an AI to master a given amount of entropy... and how many computing resources are required? I think it's unimaginable that a computer could not master the entropy mastered by the best human brain -- there's nothing magic about brains -- but the question is, how many cores do you need, and how many centuries will it take to get there?

But... will a computer ever be able to do my job? Inconceivable!


问:
Which of these is the better way to structure functions in JavaScript?
I am new to programming (self teaching Javascript so I am missing some of the basics). I'm not sure if this falls under a style or best-practice question.

When writing a function that will be used often, and that has many slightly varied output expectations, should an internal if-statement be run to determine the output, or should the function be broken down into specific functions.

eg. What is better (try to ignore the contents!)

1:

```<code>function changeColour(colour){
  this.removeColour();
  switch(colour){
    case "red":
      this.colour('red');
    break;
    case "blue":
     this.colour('blue');
   break;
 }
}
</code>```

or

2.

```<code>function makeRed()
function makeBlue().. etc
</code>```

答:
In this case - a simple function that takes only one argument and can be handled with a simple switch statement - you should do that. You gain  nothing from breaking this down into separate functions except extra code to maintain. A function should perform one operation clearly and succintly - a simple switch statement such as yours certainly does not break that rule.

By breaking your logic into specific functions for the different colors, you also weaken your design by complicating your program  logic in other places: When you change colors, you will have to arbitrarily know (never good) or include logic to determine which function you need to call that point. With your parametrized function it will be much easier to call the function at run-time and dynamically manipulate colors without having to know which particular function you need to call.

Do a "cost/benefit analysis" when designing your functions: Is this function becoming too long and complex? Is trying to do too many things at once? Does it correcly express the idea you want to implement? Will the next developer who deals with this code understand it easily? Be able to modify it easily? Use it in other situtations? Your current function with the switch meets all these criteria (except for the last one - more on that below.)

However, what does merit some consideration is your first line:

```<code> this.removeColour();
</code>```

I understand that you need to remove the old color before setting the new one and it is convenient to wrap the call to removeColour together with setting the new color. But this might be an example of what we call "bundling" - combining several not necessarily related operations into one function.

In your case, this is probably a non-issue - you must clear the old color - AFAIK (I am not a JavaScript guy) - before setting the new one, so removeColour belongs in this function - it is an essential element of the changeColouroperation. So my point here is simply didactic. But it is all too common to find code that is guilty of "bundling" in such manner when that is not the case: Simply bundling a group of unrelated operations together for convenience's sake.

Such a practice leads to difficult to maintain, not robust code: The time will come when you need to execute only one or some of the unrelated operations, and not all of them. When that happens you will have to either duplicate code or change the bundled code and break it out into separate functions - extra work/time/money. That is one (of many) sorts of scenarios when you should be thinking about writing separate functions to handle different operations.

Something else to consider is this line:

```<code>this.colour('blue');
</code>```

Perhaps another example of "bundling": By setting the color of this within this function, you have restricted its scope and usability: Now the function only works for this but not for other widgets. You might want to consider just having the function return a string with the name of color.

```<code>return 'blue'...
</code>```

And have the caller use the result to set  this.colour(colorName):

```<code>colorName = changeColor(blue);
this.colour(colorName):
</code>```

Then you (or someone else) could also write:

```<code>colorName = changeColor(red);
aWidget.color(colorName):
</code>```

etc..

Should you do so, besides having to modify the function to return a string and dealing with the removeColor operation, you should probably change the name of the function to GetColorName(colour) - because you are not actually changing the color in the function, but simply getting the string representation of the desired color. A function name should clearly describe what the function is doing.

Body:
In this case - a simple function that takes only one argument and can be handled with a simple switch statement - you should do that. You gain  nothing from breaking this down into separate functions except extra code to maintain. A function should perform one operation clearly and succintly - a simple switch statement such as yours certainly does not break that rule.

By breaking your logic into specific functions for the different colors, you also weaken your design by complicating your program  logic in other places: When you change colors, you will have to arbitrarily know (never good) or include logic to determine which function you need to call that point. With your parametrized function it will be much easier to call the function at run-time and dynamically manipulate colors without having to know which particular function you need to call.

Do a "cost/benefit analysis" when designing your functions: Is this function becoming too long and complex? Is trying to do too many things at once? Does it correcly express the idea you want to implement? Will the next developer who deals with this code understand it easily? Be able to modify it easily? Use it in other situtations? Your current function with the switch meets all these criteria (except for the last one - more on that below.)

However, what does merit some consideration is your first line:

 this.removeColour();

I understand that you need to remove the old color before setting the new one and it is convenient to wrap the call to removeColour together with setting the new color. But this might be an example of what we call "bundling" - combining several not necessarily related operations into one function.

In your case, this is probably a non-issue - you must clear the old color - AFAIK (I am not a JavaScript guy) - before setting the new one, so removeColour belongs in this function - it is an essential element of the changeColouroperation. So my point here is simply didactic. But it is all too common to find code that is guilty of "bundling" in such manner when that is not the case: Simply bundling a group of unrelated operations together for convenience's sake.

Such a practice leads to difficult to maintain, not robust code: The time will come when you need to execute only one or some of the unrelated operations, and not all of them. When that happens you will have to either duplicate code or change the bundled code and break it out into separate functions - extra work/time/money. That is one (of many) sorts of scenarios when you should be thinking about writing separate functions to handle different operations.

Something else to consider is this line:

this.colour('blue');

Perhaps another example of "bundling": By setting the color of this within this function, you have restricted its scope and usability: Now the function only works for this but not for other widgets. You might want to consider just having the function return a string with the name of color.

return 'blue'...

And have the caller use the result to set  this.colour(colorName):

colorName = changeColor(blue);
this.colour(colorName):

Then you (or someone else) could also write:

colorName = changeColor(red);
aWidget.color(colorName):

etc..

Should you do so, besides having to modify the function to return a string and dealing with the removeColor operation, you should probably change the name of the function to GetColorName(colour) - because you are not actually changing the color in the function, but simply getting the string representation of the desired color. A function name should clearly describe what the function is doing.


问:
Finding common prefixes for a set of strings
I am trying to find common prefixes for a sorted set of strings. i.e. if the following strings are given:

```<code>AB123456
AB123457
ABCDEFGH
ABCDEFGX1
ABCDEFGY
XXXX
</code>```

then my function should return three prefixes and their suffixes:

```<code>AB12345  6,7
ABCDEFG  H,X1,Y
XXXX     (no suffixes)
</code>```

Some background information: I'm trying to compress a large amount of sorted strings. A traditional implementation of prefix compression would just store the difference of each string to the previous string. This does not allow fast random inserts or lookups, because all the previous strings have to be decompressed first. That's why I want to find common prefixes. Each string will just store the difference to this common prefix. Then I get fast random access for the cost of a few additional bytes (compared to the traditional implementation).

I'm not yet having a really good idea how to implement this. In my dreams I imagine a window which slides over the input stream, trying to find the best result. This smells like dynamic programming, a topic that I haven't been in touch with since university (long long ago).

If, however, computing the "best" result turns out to be extremely performance intensive I am willing to use the second-best result. Performance is important.

EDIT:
After reading the first few answers, I understand that my question maybe was not precise enough. Maybe I can rephrase it a bit:

I am looking for the lowest cost (= minimum space utilization) in a graph. The graph starts with a sorted set of unique strings. (They are not compressed and therefore require the maximum space.) I now want to find common prefixes of the strings, so that the utilized space can be reduced. There should be just one level of prefixes, i.e. no prefix hierarchy (as it would be assumed in a trie).

答: You should be able to use a substring of the string you want to check unless the prefix length varies. You can use an if statement to make sure the string is long enough to have the prefix.</p>


答:
You want to store strings in compressed form (to save space, I guess), but you want fast lookup, is this right?
If I were you, I would go for the speed and use a trie (for the first few characters).
It has O(log n) lookup, and it will automatically condense common prefixes.

A lot depends on the statistics of the strings, like how many there are, and their typical length.

ADDED: For the strings you gave, the trie would look like this:

```<code>- A B - 1 2 3 4 5 - 6 .
  |     |           |
  |     |           7 .
  |     |
  |     C D E F G - H .
  |                 |
  |                 X 1 .
  |                 |
  |                 Y .
  |
  X X X X .
</code>```

Each node of the trie contains a little "dictionary" of "words", initially 1 letter long,
and each "word" points to a sub-node.
If that sub-node contains only one "word" in its own "dictionary", then that "word" can be absorbed into its parent's "word", and that's how you build up the prefixes.

Title: Finding common prefixes for a set of strings

Body:
I am trying to find common prefixes for a sorted set of strings. i.e. if the following strings are given:

```<code>AB123456
AB123457
ABCDEFGH
ABCDEFGX1
ABCDEFGY
XXXX
</code>```

then my function should return three prefixes and their suffixes:

```<code>AB12345  6,7
ABCDEFG  H,X1,Y
XXXX     (no suffixes)
</code>```

Some background information: I'm trying to compress a large amount of sorted strings. A traditional implementation of prefix compression would just store the difference of each string to the previous string. This does not allow fast random inserts or lookups, because all the previous strings have to be decompressed first. That's why I want to find common prefixes. Each string will just store the difference to this common prefix. Then I get fast random access for the cost of a few additional bytes (compared to the traditional implementation).

I'm not yet having a really good idea how to implement this. In my dreams I imagine a window which slides over the input stream, trying to find the best result. This smells like dynamic programming, a topic that I haven't been in touch with since university (long long ago).

If, however, computing the "best" result turns out to be extremely performance intensive I am willing to use the second-best result. Performance is important.

EDIT:
After reading the first few answers, I understand that my question maybe was not precise enough. Maybe I can rephrase it a bit:

I am looking for the lowest cost (= minimum space utilization) in a graph. The graph starts with a sorted set of unique strings. (They are not compressed and therefore require the maximum space.) I now want to find common prefixes of the strings, so that the utilized space can be reduced. There should be just one level of prefixes, i.e. no prefix hierarchy (as it would be assumed in a trie).

Body:
You want to store strings in compressed form (to save space, I guess), but you want fast lookup, is this right?
If I were you, I would go for the speed and use a trie (for the first few characters).
It has O(log n) lookup, and it will automatically condense common prefixes.

A lot depends on the statistics of the strings, like how many there are, and their typical length.

ADDED: For the strings you gave, the trie would look like this:

- A B - 1 2 3 4 5 - 6 .
  |     |           |
  |     |           7 .
  |     |
  |     C D E F G - H .
  |                 |
  |                 X 1 .
  |                 |
  |                 Y .
  |
  X X X X .

Each node of the trie contains a little "dictionary" of "words", initially 1 letter long,
and each "word" points to a sub-node.
If that sub-node contains only one "word" in its own "dictionary", then that "word" can be absorbed into its parent's "word", and that's how you build up the prefixes.


问:
Given a number which is power of 2, check if it is even power or odd power
I am given a number n , which is always a power of 2.
I want to check whether n is odd power of 2 or even power of 2.

For example: n=4 , ans= even
n=8, ans=odd (because 8 is 2^3)
n=1024 , ans=even.

Can I do it using bitwise operations/ or some faster method.

答:
Lets start off with the statement 'bitwise operations on unbounded integers is meaningless'.  You're not going to be testing if the number 2128 has an even exponent or not.  The problem area is constrained to, lets say, unsigned 32 bits.  This could also be 64 easily (the long data type), but its easier to type 32 bit numbers.

The number 2n, when written in binary has exactly one 1 in it:

20 = 0...0001

21 = 0...0010

22 = 0...0100

23 = 0...1000

and so forth.  The question then is "what bitwise operation will have a value that is 0 or not 0 when done against such a number?"

The value would be 22 + 20 which gives us 5. This pattern repeats itself for all of the even exponents.

So, the bitwise operation is & 5 (or & A).  The value of 52 is 0101 with the odd values as 0, while 102 is 1010 with the even values as 0.  This value is then done for each nyble (half a byte) in the number: the value we are interested in is 0101 0101 0101 0101 0101 0101 0101 0101 or 0x55555555

n & 0x55555555 will give a value of 0 when the power of 2 is odd and some other value when the power of 2 is even.  n & 0xAAAAAAAA will do the opposite (0 when the power of 2 is even and some other value when it is odd).

n & 0x55555555 is in effect n & (20 + 22 + 24 + 26 + ... + 230) which again, gives us the answer we are after.


问:
performance issues when synchronizing on an interned String
I want to lock a remote file with the string "ip + filename" using java.

```<code>public boolean execCmd(String ip,String filename, String command)
{
    String file = ip + filename;
    String lock = file.intern();

    try
    {
        synchronized (lock)
        {
            System.out.println(file + "get the lock");
            // ssh to remote machine and exec command
            System.out.println(file + "release the lock");
        }
    }
    catch(Exception e)
    {
    }
}
</code>```

this function is called by multi-threads, but I found the execution is a little slow, it seems to be sequential even for different files.

Now the result is like this:

```<code>file1 get the lock
file2 get the lock
file3 get the lock
file1 release the lock
file2 release the lock
file3 release the lock
file4 get the lock
file4 release the lock
file5 get the lock
file5 release the lock
file6 get the lock
file6 release the lock
...
</code>```

the first three log output seems to be concurrent, but the following task seems to be sequential, I tried for many times, the result is almost the same.

Is this a normal result? or there is something wrong with the program?

答:
Your code is right, but the synchronized on String.intern() is not a good idea.

By the way, If you want to lock the file in remote machine, you can implement it in shell script. flock can be a good way to lock a file in linux.


问:
Can every language be compiled? And can every language be interpreted?
I was wondering whether every interpreted language can be compiled?  And can every compiled language be interpreted?</p>

答:
Yes. As a trivial example we can make every compiled language interpreted by having the interpreter interpret assembly or whatever the compiled result is. Dually, we can bundle the whole interpreter + the program into one executable giving a "compiled" result.

You didn't say "compiled well" :)


答:
For a C program there's no reason the compiler can't be wrapped in about the follow two lines:

```<code>cc -g source.c
./a.out
</code>```

Which makes it pretty interpreted. I added the -g to emphasize that it's possible to keep C code close to the source.

And any interpreted language can be compiled for efficiency. Javascript can be uglified. Python drops those lovely .pyc files.

In short: the dichotomy you have been taught is nonsense. Programming languages exist on the entire spectrum from native code to virtual machine code to DSLs that you can write in Java or Scala to interpreted chains of compiled code feeding into each other, which is precisely the Unix philosophy (and any Bash script).

Languages described as interpreted tend to not have "compile" time errors. But then there's lint collectors which may as well be built into the compiler and halt if an error happens, much in the style of my toy code above.

Perhaps interpreted means more "dynamic," which just means fewer things cause compile errors or runtime errors. But even a language like Java, which people call stricter, can load malformed classes and throw runtime errors.

And a "compiled" language like C compiles into assembly/machine code. And what is machine code if not code that is interpreted by the CPU? Compiled code has to land somewhere.

Which is just the same process that the Java compiler goes from Java source to Java bytecode, which is intepreted by the JVM in much the same way Python code is interpeted by the Python runtime. So we have a compiled language compiling into an interpreted one which runs on a virtual machine that is programmed in a native language (C++).

And of course toy languages like brainfuck you can implement in Java or C or Ruby, and they're simple enough you can write them in assembly just as an exercise in learning assembly. But then again Ruby can be put on the JVM via JRuby, which makes Ruby a lot more like a compiled language.

Get it yet?

Title: Can every language be compiled? And can every language be interpreted?

Body: I was wondering whether every interpreted language can be compiled?  And can every compiled language be interpreted?</p>

Body:
For a C program there's no reason the compiler can't be wrapped in about the follow two lines:

cc -g source.c
./a.out

Which makes it pretty interpreted. I added the -g to emphasize that it's possible to keep C code close to the source.

And any interpreted language can be compiled for efficiency. Javascript can be uglified. Python drops those lovely .pyc files.

In short: the dichotomy you have been taught is nonsense. Programming languages exist on the entire spectrum from native code to virtual machine code to DSLs that you can write in Java or Scala to interpreted chains of compiled code feeding into each other, which is precisely the Unix philosophy (and any Bash script).

Languages described as interpreted tend to not have "compile" time errors. But then there's lint collectors which may as well be built into the compiler and halt if an error happens, much in the style of my toy code above.

Perhaps interpreted means more "dynamic," which just means fewer things cause compile errors or runtime errors. But even a language like Java, which people call stricter, can load malformed classes and throw runtime errors.

And a "compiled" language like C compiles into assembly/machine code. And what is machine code if not code that is interpreted by the CPU? Compiled code has to land somewhere.

Which is just the same process that the Java compiler goes from Java source to Java bytecode, which is intepreted by the JVM in much the same way Python code is interpeted by the Python runtime. So we have a compiled language compiling into an interpreted one which runs on a virtual machine that is programmed in a native language (C++).

And of course toy languages like brainfuck you can implement in Java or C or Ruby, and they're simple enough you can write them in assembly just as an exercise in learning assembly. But then again Ruby can be put on the JVM via JRuby, which makes Ruby a lot more like a compiled language.

Get it yet?


问:
Integrating Holidays and Attendance in an HR Management System
I'm developing a small HRMS system for my company, and am currently thinking of how to integrate attendance and holidays. We currently have an in_time/out_time based daily attendance system, but the HR (naturally) also wants to be able to define holidays, special days off, etc.

Broadly, I can think of the following two tables:

```<code>attendance:
    emp_id,
    date,
    in_time,
    out_time,
    att_count (1, 0.5, etc.),
    type (weekend, holiday, etc.),
    comments (if needed)

holidays:
    date,
    att_count(1, 0.5, etc.),
    comments
</code>```

Here's where I'm stuck: The HR has to be able to define holidays for existing attendance also. In other words, on the 30th of that month, he/she might say, "Oh, the 13th was a holiday but I forgot to include it in our earlier list. Let me add that now." In such a case, I'll need to scan every record existing in the attendance table to see if the date matches. Although our company is small (30-35 people), is this a good strategy when designing a database? What are the best practices you can recommend?

答:
I feel like "best practice" here would be for HR to define the holidays before they happen, or at least before employees submit time sheets against those dates. After the fact, HR has to go to each employee that claims to have worked on that day and determine if they actually worked on the holiday, or if they incorrectly submitted their hours as if they had worked the whole week.

Your system can do a lot to help HR with this.

Most holidays are entirely predictable, as are weekends, as is any interaction between the holiday and weekend (example: if a holiday occurring on a weekend causes the next work day to be a "holiday"). Just calculate all such dates for them, and populate them in your holidays table.

If "special days off" are predictable (example: every 17th Tuesday), do as for holidays.

Some special days off might not be entirely predictable, but might follow a pattern, and your system could warn HR of the upcoming special day, and that they need to enter it as soon as they know the exact date. An example of this might be if you offer a special day off at the end of Ramadan; you know when Ramadan can start, and once you know when it started you know when Ramadan can end, but it would be up to HR to input the dates (or your application might be able to automatically pull it from some other source).

So all that should ever cause issues are unpredictable special days off. HR just needs to be on the ball about them. Maybe have the system prompt them a few days before the last work day of every month, or every week, depending on how far in advance they might know about the unpredictable holidays.

They key take away from this is that HR should be relied on as little as possible to populate holidays, and that where they are responsible they should be reminded, and then it's up to HR to fulfil their role (defining the remaining holidays/special days off).


答:
The system, as currently defined, is very rudimentary and would require significant refactoring for changes.  As this is in a state of flux ("Because our company is still evolving, these are not well defined, unfortunately"), the thing to do is to design with the intent to be flexible.  Note that the design with flexibility will come at a cost of longer time to do the design (rather than diving right in and coding).

The first thing that is apparent is there are different types of days.  These are currently being stuffed in a field (type (weekend, holiday, etc.))  There are different types of things here again.  There are the predictable, and the less predictable.

Weekends are very predictable.  Holidays are less so.  What this boils down to is you need a function or stored procedure that gives you a set of types of days given a date.  This is especially important when the same day can have multiple day types - Dec 25, 2016 is on a Sunday; this is both a weekend and a holiday.

One could do this as isWeekend(date) and isHoliday(date).  Or you could have some other function that returns a structure of some sort that indicates all the date types.  Or you could stick that information in a table with the appropriate many to many relationship.

I'm also going to point out something that needs to be taken into account.  Updating history.  Its well and fine to have a function that lets you do isHoliday('Oct 31, 2014') that returns false.  But if you also get paid on the the end of the month and on Nov 3rd HR decides that Halloween is a half day vacation... yea. Things can get messy rapidly.  This is an area that the requirements need to get flushed out more clearly.  You might want to invest in Mastering the Requirements Process: Getting Requirements Right and consider what the requirements are and how to work with them.  This may just be funny money within the system, or it may be that you are punching in and out and working hourly and punching in at 8:15 rather than 8:00 affects your pay rather than just record keeping.

Another thing to consider is the "can a special day belong to one person?"  The answer is "very likely."  This may range from things like "jury duty" to the policy that a previous employer had of your birthday as a holiday (this is likely different for each person).

Defining a table that contains the special day type works better than defining an enum or set in most cases.  The biggest point here is that day types can have additional information associated with them - enums and sets cannot.

So, I'd be looking at something like:

```<code>+--------------------+  +----------------+    +---------------+     +----------+
| shift              |  | special_shift  |    | special       |     | type     |
+--------------------+  +----------------+    +---------------+     +----------+
| id                 +--+ shift_id       |  +-+ id            |  +--+ id       |
| emp_id             |  | special_id     +--+ | date          |  |  | text     |
| date               |  | id             |    | emp_id (null) |  |  |          |
| start              |  |                |    | hours         |  |  |          |
| end                |  |                |    | type_id       +--+  |          |
|                    |  |                |    |               |     |          |
+--------------------+  +----------------+    +---------------+     +----------+
</code>```

If there is no corresponding row in special_shift for a given shift, that shift isn't special.  I would have a trigger on special_shift for an on insert that kicks off some other processes (logic for does a paycheck need to be reprinted?)

Within the special table, emp_id may be null. If there is an employee id, this special field is for that employee only.  Vacation, sick day, family leave, birthday, jury duty.  The 'hours' would be how many hours that employee is credited with for that special day - it may be null.  There may also be a rate (weekends are +0.5x, holidays are +0.5x, weekend holiday would then be +1.0x).  This allows for triggers to be added for an on insert in the shift table so that if the date matches a row in special_shift can be automatically created.

There is nothing wrong with having a script go in and populate all the weekends automatically so that these are part of the table.  Fortunately, you can be fairly assured that weekends do not change after the fact.

You will see that I've gone with the many to many table here.  A given shift may have many special dates attached to it, and a special date may apply to many shifts.

This then has a foreign key to the type.  Currently, I've just got a text field in there for what it is (vacation, sick day, etc...).  However, this may include information such as 'hr approval needed?'

By no means is this meant to represent the final, best answer.  But rather give you some things to consider and approaches to take when designing such a system.  I'd really suggest sitting down with HR and trying to nail down as much of their logic as possible in plain english before tackling too much of this (if you get some day as a 1.5x pay bonus and have jury duty what happens? Can you use a sick day on a holiday? If you are taking a week of vacation and come in and work, is that over time (yes, this is a real situation)? Do you need approval to work on a holiday or weekend?).

Look around though, there are likely business rule triggers all over and you will need to think about how to handle this.  Do you store updates until they are processed? Are the business rules written in the trigger? or some sort of extract / transform / load approach where the business logic is stored in a rules engine?

Designing the payroll tracking is a huge project.  There are entire segments of the software industry built around just this problem - and there is a reason that they can charge the amount they do for their software (it's not easy).  While you aren't likely going to implement C3, you may wish to read Why Is Payroll Hard.

Title: Integrating Holidays and Attendance in an HR Management System

Body:
I'm developing a small HRMS system for my company, and am currently thinking of how to integrate attendance and holidays. We currently have an in_time/out_time based daily attendance system, but the HR (naturally) also wants to be able to define holidays, special days off, etc.

Broadly, I can think of the following two tables:

```<code>attendance:
    emp_id,
    date,
    in_time,
    out_time,
    att_count (1, 0.5, etc.),
    type (weekend, holiday, etc.),
    comments (if needed)

holidays:
    date,
    att_count(1, 0.5, etc.),
    comments
</code>```

Here's where I'm stuck: The HR has to be able to define holidays for existing attendance also. In other words, on the 30th of that month, he/she might say, "Oh, the 13th was a holiday but I forgot to include it in our earlier list. Let me add that now." In such a case, I'll need to scan every record existing in the attendance table to see if the date matches. Although our company is small (30-35 people), is this a good strategy when designing a database? What are the best practices you can recommend?

Body:
The system, as currently defined, is very rudimentary and would require significant refactoring for changes.  As this is in a state of flux ("Because our company is still evolving, these are not well defined, unfortunately"), the thing to do is to design with the intent to be flexible.  Note that the design with flexibility will come at a cost of longer time to do the design (rather than diving right in and coding).

The first thing that is apparent is there are different types of days.  These are currently being stuffed in a field (type (weekend, holiday, etc.))  There are different types of things here again.  There are the predictable, and the less predictable.

Weekends are very predictable.  Holidays are less so.  What this boils down to is you need a function or stored procedure that gives you a set of types of days given a date.  This is especially important when the same day can have multiple day types - Dec 25, 2016 is on a Sunday; this is both a weekend and a holiday.

One could do this as isWeekend(date) and isHoliday(date).  Or you could have some other function that returns a structure of some sort that indicates all the date types.  Or you could stick that information in a table with the appropriate many to many relationship.

I'm also going to point out something that needs to be taken into account.  Updating history.  Its well and fine to have a function that lets you do isHoliday('Oct 31, 2014') that returns false.  But if you also get paid on the the end of the month and on Nov 3rd HR decides that Halloween is a half day vacation... yea. Things can get messy rapidly.  This is an area that the requirements need to get flushed out more clearly.  You might want to invest in Mastering the Requirements Process: Getting Requirements Right and consider what the requirements are and how to work with them.  This may just be funny money within the system, or it may be that you are punching in and out and working hourly and punching in at 8:15 rather than 8:00 affects your pay rather than just record keeping.

Another thing to consider is the "can a special day belong to one person?"  The answer is "very likely."  This may range from things like "jury duty" to the policy that a previous employer had of your birthday as a holiday (this is likely different for each person).

Defining a table that contains the special day type works better than defining an enum or set in most cases.  The biggest point here is that day types can have additional information associated with them - enums and sets cannot.

So, I'd be looking at something like:

+--------------------+  +----------------+    +---------------+     +----------+
| shift              |  | special_shift  |    | special       |     | type     |
+--------------------+  +----------------+    +---------------+     +----------+
| id                 +--+ shift_id       |  +-+ id            |  +--+ id       |
| emp_id             |  | special_id     +--+ | date          |  |  | text     |
| date               |  | id             |    | emp_id (null) |  |  |          |
| start              |  |                |    | hours         |  |  |          |
| end                |  |                |    | type_id       +--+  |          |
|                    |  |                |    |               |     |          |
+--------------------+  +----------------+    +---------------+     +----------+

If there is no corresponding row in special_shift for a given shift, that shift isn't special.  I would have a trigger on special_shift for an on insert that kicks off some other processes (logic for does a paycheck need to be reprinted?)

Within the special table, emp_id may be null. If there is an employee id, this special field is for that employee only.  Vacation, sick day, family leave, birthday, jury duty.  The 'hours' would be how many hours that employee is credited with for that special day - it may be null.  There may also be a rate (weekends are +0.5x, holidays are +0.5x, weekend holiday would then be +1.0x).  This allows for triggers to be added for an on insert in the shift table so that if the date matches a row in special_shift can be automatically created.

There is nothing wrong with having a script go in and populate all the weekends automatically so that these are part of the table.  Fortunately, you can be fairly assured that weekends do not change after the fact.

You will see that I've gone with the many to many table here.  A given shift may have many special dates attached to it, and a special date may apply to many shifts.

This then has a foreign key to the type.  Currently, I've just got a text field in there for what it is (vacation, sick day, etc...).  However, this may include information such as 'hr approval needed?'

By no means is this meant to represent the final, best answer.  But rather give you some things to consider and approaches to take when designing such a system.  I'd really suggest sitting down with HR and trying to nail down as much of their logic as possible in plain english before tackling too much of this (if you get some day as a 1.5x pay bonus and have jury duty what happens? Can you use a sick day on a holiday? If you are taking a week of vacation and come in and work, is that over time (yes, this is a real situation)? Do you need approval to work on a holiday or weekend?).

Look around though, there are likely business rule triggers all over and you will need to think about how to handle this.  Do you store updates until they are processed? Are the business rules written in the trigger? or some sort of extract / transform / load approach where the business logic is stored in a rules engine?

Designing the payroll tracking is a huge project.  There are entire segments of the software industry built around just this problem - and there is a reason that they can charge the amount they do for their software (it's not easy).  While you aren't likely going to implement C3, you may wish to read Why Is Payroll Hard.


答:
It depends on your definitions of interpreted and compiled.

For example I recall that Perl has certain constructs that can only be interpreted at runtime, which makes it impossible to compile.

On the other hand interpretation usually implies that you don't get to parse all the source code before the program is started. I cannot come up with an example from the top of my head, but I wouldn't be surprised if this means some languages have to be compiled.

Finally it's unclear how such features as source code generation (e.g. Lisp meta programming, C macros, Eclipse EMF) and bytecode manipulation (e.g. AspectJ) should fit into this picture.


答:
Every language possible must support both compilation and interpretation by definition

The trick is in the underlying meanings of the idea of "compilation" and "interpretation."

Interpretation is "take this program written in language X, and create a process which applies the rules of language X to the program."  It's a fancy way of saying "interpretation is running the program."

Compiling is take this program written in language X, and write a new program in language Y which, if interpreted, would create the same results as interpreting the program in X directly.  It is a mapping operation from one language to another.  It's a fancy way of saying "take some time to make a program that, at a later time, would do what I wrote, but faster."

Every language can be mapped to another language.  If not, then the language cannot really run on computers.  Thus every language can technically be compiled.  And, since any compiled program can be written in the form "interpret the act of compiling the program, then interpret the result," every program can be interpreted as well.

The line is even fuzzy with assembly.  One assumes that x86 code is interpreted, because the job of a CPU is to interpret your instructions.  However, in reality, x86 is too slow if interpreted literally.  Instead, every modern CPU will compile x86 into its own "native" microcode.  This means that literally every "interpreted" language gets compiled at some point.

Some languages are hard to compile or interpret

Some languages do not lend themselves well to compiling or interpreting.  One expectation of a "good" language is speed.  Slow languages tend to be less desirable than fast languages.  C++ has rules which take advantage of the fact that it is traditionally compiled rather than interpreting.  It has very slow rules (such as function overloading resolution) which compilers can bake down into very fast assembly (with simple fast rules).  A naiive C++ interpreter would spend a great deal of time repeatedly doing these slow rules.

Likewise, some languages do not lend themselves well to compiling.  Python, for instance, relies on duck-typing for everything.  These rules are much faster than C++'s compiling rules, but slower than assembly's rules.  Compiling Python wouldn't buy you much because you couldn't map Python into anything much simpler.

... or could you?

If you look at PyPy, Psyco, or IronPython, there is an effort to compile Python.  They do techniques known as Just in Time Compiling (JIT) to find bits of Python which do reward compiling.  They compile those parts, while interpreting parts which are hard to compile.  In many commonly-occuring cases, the result of using IronPython to JIT compile Python code is as fast or faster than C++ or C#!

This shows just how blurry the line between compiled and interpreted actually is.


问:
How to debug minified javascript on production?
I have a front end single page app deployed on S3. It is minified on production.
It creates error only when it is minified via grunt on production.
I cannot repro the issue in dev.
How do I go about debugging such issue?

Thank you.

答: The Chrome debugger will allow you to expand minified code into multiple lines to make it easier to step through and set breakpoints in it.  It has a {} symbol below the code window.  When you click on it, it expands multiple statements per line into one line per statement and indents code so you can then read it and step through it.  It doesn't do anything about those "hard to read" single letter variables since the meaningful names for minimized variables are gone at this point, but it does allow you to use the minified code in the debugger.


问:
Good way to count unique anonymous visitors of articles
I'm building a website with articles, and I'd like to count unique-per-day visits for each article.

The idea to use cookies suggests itself, but I simply can't set a cookie for each and every article visited - ofc the user typically won't go through everything, but better to be safe. If I put all into one cookie, I'll run out of per-cookie space soon, too.

What'd be the best (most practical and lightweight) solution to this?

I have an sqlite database, so maybe some kind of persistent "session" data? That'll put extra load on the server and db, though. Ideas?

答:
If you are concerned about load you could use redis or in-memory storage, and them periodically offload the results, see:

Python example, could be adapted to php

Uses Redis bitmaps to store the counts


答:
Can use right shift instead of bitwise? something like this (no input checking for simplicity):</p>

```<code>public bool IsEvenPower(int n)
{
    int count = 0;
    int remaining = n;
    do
    {
        remaining = remaining >> 1;
        count++;
    }
    while(remaining > 1);
    return count % 2 == 0;
}
</code>```

Title: Given a number which is power of 2, check if it is even power or odd power

Body:
I am given a number n , which is always a power of 2.
I want to check whether n is odd power of 2 or even power of 2.

For example: n=4 , ans= even
n=8, ans=odd (because 8 is 2^3)
n=1024 , ans=even.

Can I do it using bitwise operations/ or some faster method.

Body:
Can use right shift instead of bitwise? something like this (no input checking for simplicity):

public bool IsEvenPower(int n)
{
    int count = 0;
    int remaining = n;
    do
    {
        remaining = remaining >> 1;
        count++;
    }
    while(remaining > 1);
    return count % 2 == 0;
}


问:
What advantages are there to using Flex/Bison over just writing a compiler straight in a programming language?
I have written an Interpreter / Compiler simply as a programming algorithm using features such as recursive functions and concepts from finite-State machines. To me, these things are ideally suited to building a compiler (Although it does end up getting pretty complex).

Doing a little bit of research on the subject, I came across Flex/Bison. I'm wondering how these tools make it better to develop a compiler. Is is simpler to use that or is the end product better in some way?

答:
Compiler generators (such as Bison) use pretty much the same concepts from finite state machines as you have used in your hand-crafted parser.

The main differences between compiler generators and hand-crafted parsers are

Most hand-crafted parsers use a top-down parsing strategy, while compiler generators often create a bottom-up parser. This has a slight impact on the languages that can be supported, although most languages of real interest can be handled by both (possibly after slight tweaks to the grammar rules). This has mostly to do with recursion in the grammar.

With a compiler generator, you specify the language's grammar directly, in a form that is usually close to the BNF form that is commonly used for describing language grammars. With a hand-crafted parser, it can sometimes be hard to recognize the language's grammar in the code, which can make it more difficult to diagnose errors resulting from incorrect interpretation of the language rules.

With a compiler generator, you may have to learn a new language (the language accepted by the generator). Hand-crafted parsers can be written in most languages.