How to design a programming language (ii) what is a pit (b)

I've never seen a powder in another language that's so easy to show the ugly side of human nature, even if it's started more than 10 years ago, C + + and the Jet, GC and non-GC to spray, static type dynamic type on the jet, or even cloud wind out of the spray C + + black so earth-shattering time, there has been no such a brain-crippled thing. This kind of thing only happens in the go language of the brain residue powder, what does this represent? People who want to learn the go language better be careful. Learn how to use go does not matter, went to study because can not stand to jump to another language does not matter, even if it is shaking m very like to be toss so insist on using go also does not matter, but the study of their own brain residue powder, their mind irreversible transformation, that is not good.

Of course, the last example of an article should be I have not made it clear, so some people have this "plus a virtual destructor can be" illusion is understandable. base* base = new Derived; After that you go to delete no problem, because destructors can also be declared as virtual. But base* base = new DERIVED[10]; then you go to delete[] there's a problem because Derived and base lengths are different, so when you start trying to compute &base[1, You actually got a position in the middle of the first derived object, not the second derived at all. This is a time when you're doing all sorts of things like calling destructors, and you can't even get the right this pointer, and you're useless. But VC + + simply do delete[], in this case is not a problem, I guess it not only recorded the length of the array, but also recorded the size of each element. Of course, when you directly use Bases[1]->dosomething (), the accident is necessary.

So today, when the fans are talking about the example of yesterday, one of our chicory said:

When you use C + +, a subset of C is best to touch less

I agree with you. Anyway, C + + already has a variety of built-in types, such as typeid out of the press (I have forgotten) Ah, initialization_list Ah, range or something. Why not create a type for new t[x]? However, it has become a reality, nothing more use vector and shared_ptr it, do not think of what their own new delete.

Today we're going to talk about a little bit of "advanced" pits. This is a real example of what I have come across after work. Of course, the language of the pits are there, people jump into the pit is certainly because they do not know enough to cause. But there are three kinds of pits, the first one is obvious, just follow some seemingly stupid but effective principles (say if (1 = =) ... ) can be removed. The second kind of pit is because you don't know some advanced knowledge (such as the things that the lambda and the variables rub together in the life cycle) to jump the pits. The third is simply due to the lack of foresight-for example, the following examples.

On a bright spring morning, I received a new task to write an image-processing pipeline with another person who is not our group. This pipeline node is nothing more than the histogram ah, convolution ah, gray scale and take the edge of something. So on the first day of the meeting, I got a spec that wrote the interface of C + + that they had designed but not yet written (yes, the kind of genre that would use interface if there was only one implementation), let me go back and take a look, Come with them in a few days and get this thing done. Of course, these interface are definitely going to have matrices:

Template<typename t>
class Imatrix
{public
:
    virtual ~imatrix () {}
    
    Virtual t* GetData () =0;
    virtual int GetRows () =0;
    virtual int getcolumns () =0;
    virtual int getstride () =0;
    Virtual T get (int r, int c) =0;
    virtual void Set (int r, int c, T t) =0;

In fact, to tell the truth, Imatrix so write really no big problem. So we worked very happily for a few days, and then we finished all the math-related algorithms and started doing the convolution thing. The bunch of numbers that the convolution needs. He's not a matrix, but because it doesn't make sense to specialize in a class like this, we use the same number of matrices as filter. The initial interface is defined in this way, because the ibitmap may have different storage methods, so how to do convolution in fact only ibitmap realize that they know:

Template<typename tchannel>
class Ibitmap
{
...
    virtual void Apply (imatrix<float>& filter) =0;
......
};

So we happily spent a few days, until one day a person jumped out and said: "Apply inside can not modify the filter, why not give him a const?" So he showed us his modified interface:

Template<typename tchannel>
class Ibitmap
{
...
    virtual void Apply (Imatrix<const float>& filter) =0;
......
};