问:
Should I use C style in C++?
As I've been developing my position on how software should be developed at the company I work for, I've come to a certain conclusion that I'm not entirely sure of.

It seems to me that if you are programming in C++, you should not use C style anything if it can be helped and you don't absolutely need the performance improvement. This way people are kept from doing things like pointer arithmetic or creating resources with new without any RAII, etc. If this idea was enforced, seeing a char* would possibly be a thing of the past.

I'm wondering if this is a conclusion others have made? Or am I being too puritanical about this?

答:
If this idea was enforced, seeing a char* would possibly be a thing of
  the past.

I tend to blend C and C++ together, making me that kind of funny "C/C++" developer. I think at least some of the reasons I list below will be legit hopefully. Often I'm using C interfaces with C++ implementations, or C++ interfaces with C-like implementations, though most of the time still C++ interfaces with C++ implementations.

There's several reasons I reach for C interfaces or C implementations (in descending order of importance):

API/ABI (interface)

Exception-Safety (implementation: huh?)

Lack of Type-Safety (implementation: huh?)

Performance (implementation: rare)

Build Times (implementation)

Aesthetics (implementation)

API/ABI

A lot of the codebases I've worked on have always been rather large and designed for third parties to extend, with plugin developers actually basing their livelihood on writing plugins for our products. As a result, the central, abstract interfaces are actually software development kits for both internal and third party developers to use when writing plugins to extend the product.

The third party plugin writers use a wide range of compilers and standard library implementations.

With this requirement, using C++ interfaces at the core API level is often out due to the ABI difficulties associated.

If we started passing std::vector through our central APIs, we end up facing ABI incompatibilities from one vendor implementation to another, and so we actually rolled our own vector-like container, but it's fully standard-compliant down to fill ctors, range ctors, range erase, etc. with performance tests to make sure it matches up with std::vector.

If we use vtables and virtual functions to model our abstract interfaces, we end up requiring plugin writers to use the same compilers we use, and will also break ABI the moment we introduce a single virtual function. As a result, the interfaces I design at the central core API level are C interfaces, mostly tables of function pointers, but with a C++ wrapper SDK which is statically-linked to plugins which wrap these into classes that conform to RAII and so forth. The wrappers are free to also use standard containers since they're internally linked to the plugin.

If we used exception-handling across module boundaries, we also face the same dilemma, so I use C error codes at the module boundary level (but often translated to/from exceptions). The statically-linked C++ wrapper SDK takes these error codes and translates them back into exceptions, but safely throwing from inside the plugin to the plugin itself.

Exception-Safety Part 1

This is a weird one, but since throwing an exception during stack unwind leads to std::terminate behavior, killing the process, it's extremely dangerous if any kind of release of resources can encounter an external error. Another is recursively throwing from a catch handler when doing so would end up aborting an outer transaction which shouldn't be aborted.

In these cases, occasionally we're tempted to allocate a resource for some reason that could possibly fail (rare but sometimes necessary). For example, I might need to allocate memory in an obscure case during the release of a resource from a general destructor or the roll back of a side effect from within a scope guard's destructor.

In those cases, sometimes a failure is not critical and can kind of be ignored (not ideal but perfect exception-safety is hard!). For example, failing to allocate memory might allow us to skip some work that's a nicety, but isn't absolutely crucial (like logging a message). In these cases, I find it easier to just use C-style error codes for failures to avoid the possibility of a recursive throw for functions which are often triggered in release/roll back/catch contexts.

Exception-Safety Part 2

When interacting with ABI, it's not safe to throw exceptions to the caller from within a callee inside a different module, especially when caller uses a different compiler/build settings from callee.

As a result, we have to swallow up exceptions before they leak past API boundaries. Because of this, sometimes if I have a relatively simple implementation for a C API, I'll just go ahead and use C all the way which can't possibly throw so that I don't have to worry about the possibility of throwing and sprinkle try/catch blocks at every entry point into the API.

Lack of Type-Safety

Okay, this is a weird one, but when we're doing low-level communication with the hardware or treating memory as just raw bits and bytes, type safety can get in the way with code that inevitably has to have a whole bunch of really ugly explicit casts. An example is a fixed allocator provided through the central C API. In that case, I often just do the implementation in C instead of C++ since memory allocators don't have much use for type safety -- they're working at the bits and bytes level.

Performance (Careful!)

This is very tied to the lack of type safety above. It isn't necessarily that C style is faster or anything like that. It's just that when it comes to doing things that are really critical with respect to how they're paying attention with the interaction of the CPU cache and so forth, it's hard to avoid things like raw pointers here and there.

Take a stride interface design like this:

```<code>void process_points(int num_points,
                    float* x, int stride,
                    float* y, int stride,
                    float* z, int stride);
</code>```

It's really hard to wrap that into a very safe design. The stride, after all, has to use a stride across these floats passed in that may not even provide a contiguous index access (they might just be skipping over bytes).

This unfortunately violates type safety, but these designs are often essential for those interfaces that handle a very heavy load with no better than linear-complexity requirements (have to touch everything), while still enabling potential optimizations like SoA SIMD access when each individual field has a stride that matches sizeof(float).

I've tried to make these types of interfaces semi-safe before by using all kinds of type-safe wrappers, but I didn't like the inflation of build times and also just came to like the aesthetic (albeit lacking type safety) of plain old data passed through in bulk with custom strides (OpenGL API style).

This is only for very select areas of the codebase, like particle systems, and they also happen to be the designs I often write tests for the most, since they're so dangerous.

Build Times

This might be slightly superstitious, but C just seems to build faster even if we're including the same number of headers and so forth and still judiciously use pimpls and such in C++ when appropriate. It might just be due to my tendencies when I'm writing more C-like code, but as a result, I tend to use C when I'm implementing something that's not very complex behind a C API to try to keep the build times down.

I really hate build times so I favor using Lua as much as possible for a large amount of code for anything that isn't performance-critical (though LuaJIT even lets me do some things that are slightly performance-critical), then C++ for a middle amount of code, then C for a small amount of code for these reasons cited.

Aesthetics

This is probably the most biased section of them all, but occasionally I just like the lightweight, minimalist C aesthetic. I love C++ for its type-safety, ability to design rich interfaces and data types, genericity, etc. But there's a C aesthetic I also admire which is just minimalist -- dangerous but minimalist.

So sometimes I'm just in the "mood" for C. I'll choose to kind of arbitrarily implement one of the C API interfaces with a C implementation for some of the simpler areas just because I'm in the mood for it. It's a horrible reason, I know, but I wanted to include it because I think both languages are beautiful and can be blended together -- one doesn't have to supersede the other.

Conclusion

So anyway, these are the main reasons I use C or C-like coding from time to time even while primarily using C++. I don't know if they're great reasons or not. I try not to be that kind of dogmatic superstitious programmer, but I've found it beneficial to reach for C here and there, and essential for when it comes to ABI when targeting multiple compilers and possibly even multiple languages with a dylib API.

Title: Should I use C style in C++?

Body:
If this idea was enforced, seeing a char* would possibly be a thing of
  the past.

I tend to blend C and C++ together, making me that kind of funny "C/C++" developer. I think at least some of the reasons I list below will be legit hopefully. Often I'm using C interfaces with C++ implementations, or C++ interfaces with C-like implementations, though most of the time still C++ interfaces with C++ implementations.

There's several reasons I reach for C interfaces or C implementations (in descending order of importance):

API/ABI (interface)

Exception-Safety (implementation: huh?)

Lack of Type-Safety (implementation: huh?)

Performance (implementation: rare)

Build Times (implementation)

Aesthetics (implementation)

API/ABI

A lot of the codebases I've worked on have always been rather large and designed for third parties to extend, with plugin developers actually basing their livelihood on writing plugins for our products. As a result, the central, abstract interfaces are actually software development kits for both internal and third party developers to use when writing plugins to extend the product.

The third party plugin writers use a wide range of compilers and standard library implementations.

With this requirement, using C++ interfaces at the core API level is often out due to the ABI difficulties associated.

If we started passing std::vector through our central APIs, we end up facing ABI incompatibilities from one vendor implementation to another, and so we actually rolled our own vector-like container, but it's fully standard-compliant down to fill ctors, range ctors, range erase, etc. with performance tests to make sure it matches up with std::vector.

If we use vtables and virtual functions to model our abstract interfaces, we end up requiring plugin writers to use the same compilers we use, and will also break ABI the moment we introduce a single virtual function. As a result, the interfaces I design at the central core API level are C interfaces, mostly tables of function pointers, but with a C++ wrapper SDK which is statically-linked to plugins which wrap these into classes that conform to RAII and so forth. The wrappers are free to also use standard containers since they're internally linked to the plugin.

If we used exception-handling across module boundaries, we also face the same dilemma, so I use C error codes at the module boundary level (but often translated to/from exceptions). The statically-linked C++ wrapper SDK takes these error codes and translates them back into exceptions, but safely throwing from inside the plugin to the plugin itself.

Exception-Safety Part 1

This is a weird one, but since throwing an exception during stack unwind leads to std::terminate behavior, killing the process, it's extremely dangerous if any kind of release of resources can encounter an external error. Another is recursively throwing from a catch handler when doing so would end up aborting an outer transaction which shouldn't be aborted.

In these cases, occasionally we're tempted to allocate a resource for some reason that could possibly fail (rare but sometimes necessary). For example, I might need to allocate memory in an obscure case during the release of a resource from a general destructor or the roll back of a side effect from within a scope guard's destructor.

In those cases, sometimes a failure is not critical and can kind of be ignored (not ideal but perfect exception-safety is hard!). For example, failing to allocate memory might allow us to skip some work that's a nicety, but isn't absolutely crucial (like logging a message). In these cases, I find it easier to just use C-style error codes for failures to avoid the possibility of a recursive throw for functions which are often triggered in release/roll back/catch contexts.

Exception-Safety Part 2

When interacting with ABI, it's not safe to throw exceptions to the caller from within a callee inside a different module, especially when caller uses a different compiler/build settings from callee.

As a result, we have to swallow up exceptions before they leak past API boundaries. Because of this, sometimes if I have a relatively simple implementation for a C API, I'll just go ahead and use C all the way which can't possibly throw so that I don't have to worry about the possibility of throwing and sprinkle try/catch blocks at every entry point into the API.

Lack of Type-Safety

Okay, this is a weird one, but when we're doing low-level communication with the hardware or treating memory as just raw bits and bytes, type safety can get in the way with code that inevitably has to have a whole bunch of really ugly explicit casts. An example is a fixed allocator provided through the central C API. In that case, I often just do the implementation in C instead of C++ since memory allocators don't have much use for type safety -- they're working at the bits and bytes level.

Performance (Careful!)

This is very tied to the lack of type safety above. It isn't necessarily that C style is faster or anything like that. It's just that when it comes to doing things that are really critical with respect to how they're paying attention with the interaction of the CPU cache and so forth, it's hard to avoid things like raw pointers here and there.

Take a stride interface design like this:

void process_points(int num_points,
                    float* x, int stride,
                    float* y, int stride,
                    float* z, int stride);

It's really hard to wrap that into a very safe design. The stride, after all, has to use a stride across these floats passed in that may not even provide a contiguous index access (they might just be skipping over bytes).

This unfortunately violates type safety, but these designs are often essential for those interfaces that handle a very heavy load with no better than linear-complexity requirements (have to touch everything), while still enabling potential optimizations like SoA SIMD access when each individual field has a stride that matches sizeof(float).

I've tried to make these types of interfaces semi-safe before by using all kinds of type-safe wrappers, but I didn't like the inflation of build times and also just came to like the aesthetic (albeit lacking type safety) of plain old data passed through in bulk with custom strides (OpenGL API style).

This is only for very select areas of the codebase, like particle systems, and they also happen to be the designs I often write tests for the most, since they're so dangerous.

Build Times

This might be slightly superstitious, but C just seems to build faster even if we're including the same number of headers and so forth and still judiciously use pimpls and such in C++ when appropriate. It might just be due to my tendencies when I'm writing more C-like code, but as a result, I tend to use C when I'm implementing something that's not very complex behind a C API to try to keep the build times down.

I really hate build times so I favor using Lua as much as possible for a large amount of code for anything that isn't performance-critical (though LuaJIT even lets me do some things that are slightly performance-critical), then C++ for a middle amount of code, then C for a small amount of code for these reasons cited.

Aesthetics

This is probably the most biased section of them all, but occasionally I just like the lightweight, minimalist C aesthetic. I love C++ for its type-safety, ability to design rich interfaces and data types, genericity, etc. But there's a C aesthetic I also admire which is just minimalist -- dangerous but minimalist.

So sometimes I'm just in the "mood" for C. I'll choose to kind of arbitrarily implement one of the C API interfaces with a C implementation for some of the simpler areas just because I'm in the mood for it. It's a horrible reason, I know, but I wanted to include it because I think both languages are beautiful and can be blended together -- one doesn't have to supersede the other.

Conclusion

So anyway, these are the main reasons I use C or C-like coding from time to time even while primarily using C++. I don't know if they're great reasons or not. I try not to be that kind of dogmatic superstitious programmer, but I've found it beneficial to reach for C here and there, and essential for when it comes to ABI when targeting multiple compilers and possibly even multiple languages with a dylib API.


问:
Refactoring a long method which is based on large number of switch cases
We are using Java as a backend development language.

One year back, we wrote a method which uses switch cases based on Enums values. Since we are continuously adding enum members and according adding cases in the method, the method has grown to very large extent. Currently, we have around 100 enum fields and corresponding number of switch cases.e.g.

```<code> class AClass{

   enum option{ o1, o2, o3...on}

   Value method(Option o){

      switch(o){
        case o1:
          value = deriveValue(p1,p2,p3);
        case o2:
          value = deriveValue(p2,p3,p4);
        .
        .
        .
        case on:
          value = deriveValue(p1,p2,p3);
      }
   }
 }
</code>```

Thus each time a business requirement comes, we add enum and corresponding switch case. Now the method has become too long and looks unmanageable, if we keep on adding the same logic in future.

To clean, we thought of replacing switch case with polymorphism by creating classes for the same, but again, we will end up creating n number of classes.

We are looking for small, simple and manageable solution.

-----------------  Update ---------------------

As suggested, to elaborate more, Enum values are fields names for which a client needs a value. Thus if a client need the value of a new field, we add the field in enum, and the corresponding definition of how to fetch value for the newly added field, by adding the corresponding switch case.

In the switch case, we have a common reusable method e.g. deriveValue() (Please refer to the example given) to which we pass parameters required for deriving the value for the newly added field.

答: Changing to classes won't help you. In terms of clarity, robustness, compactness, maintainability and performance it doesn't get any better than enums and a switch statement. What you should be asking yourself is if you are dealing with types at all. Considering that you are frequently and continuously adding enums, it seems to me you are dealing with data, not types. You might need a single class and multiple instances. This is what DesignerAnalyst implies with the table proposal. You may still hard-code your input data for your object instances or slap the input in a text file, the big question remains: what ARE those enum values really? How do they classify?</p>

ContentLicense: CC BY-SA 3.0


问:
Designs and practices to guard against erroneous null entries from database
One part of my program fetches data from many tables and columns in my database for processing. Some of the columns might be null, but in the current processing context that is an error.

This should "theoretically" not happen, so if it does it points to bad data or a bug in the code. The errors have different severities, depending which field is null; i.e. for some fields the processing should be stopped and somebody notified, for others the processing should be allowed to continue and just notify somebody.

Are there any good architecture or design principles to handle the rare but possible null entries?

The solutions should be possible to implement with Java but I didn't use the tag because I think the problem is somewhat language-agnostic.

Some thoughts that I had myself:

Using NOT NULL

Easiest would be to use a NOT NULL constraint in the database.

But what if the original inserting of the data is more important that this later processing step? So in case the insert would put a null into the table (either because of bugs or maybe even some valid reason), I wouldn't want the insert to fail. Let's say that many more parts of the program depend on the inserted data, but not on this particular column. So I would rather risk the error in the current processing step instead of the insert step. That's why I don't want to use a NOT NULL constraint.

Naively depending on NullPointerException

I could just use the data as if I expect it to be always there (and that should really be the case), and catch resulting NPEs at an appropriate level (e.g. so that the processing of the current entry stops but not the whole processing progress). This is the "fail fast" principle and I often prefer it. If it is a bug at least I get a logged NPE.

But then I lose the ability to differentiate between various kinds of missing data. E.g. for some missing data I could leave it out, but for others the processing should be stopped and an admin notified.

Checking for null before each access and throwing custom exceptions

Custom exceptions would let me decide the correct action based on the exception, so this seems like the way to go.

But what if I forget to check it somewhere? Also I then clutter my code with null checks which are never or rarely expected (and so definitely not part of the business logic flow).

If I choose to go this way, what patterns are best suited for the approach?

Any thoughts and comments on my approaches are welcomed. Also better solutions of any kind (patterns, principles, better architecture of my code or models etc.).

Edit:

There is another constraint, in that i am using an ORM to do the mapping from DB to persistence object, so doing null checks on that level would not work (as the same objects are used in parts where the null does not do any harm). I added this because the answers provided so far both mentioned this option.

答:
There are many ways to handle nulls, so we'll move on from the database layer up to the application layer.

Database layer

You can forbid nulls; although here it is impractical.

You can configure a default on a per column basis:

it requires that the column be absent from the insert, so does not cover explicit null insertion

it prevents the detection from rows where the insert erroneously missed this column

You can configure a trigger, so that upon insertion the missing values are automatically computed:

it requires that the necessary information to perform this computation be present

it will slow down the insert

Query layer

You can skip rows where an inconvenient null is present:

it simplifies the main logic

it prevents detecting the "bad rows", so another process would be needed to check on them

it requires that each query be instrumented

You can provide a default value in the query:

it simplifies the main logic

it prevents detecting the "bad rows", so another process would be needed to check on them

it requires that each query be instrumented

Note: instrumenting each query is not necessarily an issue if you have some automated way of generating them.

Application layer

You can pre-check the table for forbidden null:

it simplifies the main logic

it improves the time-to-failure

it requires keeping the pre-check and application logic consistent

You can interrupt the processing when encountering a forbidden null:

it avoids duplicating the knowledge of which columns can be null and which cannot

it is still relatively simple (just a check + return/throw)

it requires that your process be resumable (if you already sent an e-mail, don't want to send it twice, or a hundred times!)

You can skip the row when encountering a forbidden null:

it avoids duplicating the knowledge of which columns can be null and which cannot

it is still relatively simple (just a check + return/throw)

it does not require that your process be resumable

You can send a notification when encountering a forbidden null, either one at a time or by batch, which is complimentary to the other ways presented above. What matters most however is "what then?", most notably, if you expect the row to be patched and in need of being re-processed you may need to ensure that you have some way to distinguish already processed rows from rows in need of being re-processed.

Given your situation, I would handle the situation at the application and combine either:

interrupt and notify

skip and notify

I would tend toward just skipping if possible to somehow guarantee a modicum of progress, especially if the processing can take time.

If you do not need to re-process the skipped rows, then simply logging them should be sufficient and an e-mail sent at the end of process with the number of skipped rows will be an apt notification.

Otherwise, I would use a side-table for the rows to be fixed (and re-processed). This side-table may either be a simple reference (without foreign key) or a full-blown copy: the latter, even if more expensive, is necessary if you do not have the time to address the null before having to cleanup the main data.


答:
It sounds like inserting a null is an error but you are afraid to enforce this error on insertion because you don't want to lose data. However, if a field shouldn't be null but is, you are losing data. Therefore the best solution is to ensure that null fields are not erroneously getting saved in the first place.

To this end, enforce that the data is correct in the one authoritative, permanent repository for that data, the database. Do so by adding not null constraints. Then your code might fail but these failures immediately notify you of bugs, allowing you to correct issues that are already causing you to lose data. Now that you are easily able to identify bugs, test your code and test it twice. You'll be able to correct bugs leading to data loss and in the process, greatly simplify downstream processing of the data because you won't need to worry about nulls.

Title: Designs and practices to guard against erroneous null entries from database

Body:
One part of my program fetches data from many tables and columns in my database for processing. Some of the columns might be null, but in the current processing context that is an error.

This should "theoretically" not happen, so if it does it points to bad data or a bug in the code. The errors have different severities, depending which field is null; i.e. for some fields the processing should be stopped and somebody notified, for others the processing should be allowed to continue and just notify somebody.

Are there any good architecture or design principles to handle the rare but possible null entries?

The solutions should be possible to implement with Java but I didn't use the tag because I think the problem is somewhat language-agnostic.

Some thoughts that I had myself:

Using NOT NULL

Easiest would be to use a NOT NULL constraint in the database.

But what if the original inserting of the data is more important that this later processing step? So in case the insert would put a null into the table (either because of bugs or maybe even some valid reason), I wouldn't want the insert to fail. Let's say that many more parts of the program depend on the inserted data, but not on this particular column. So I would rather risk the error in the current processing step instead of the insert step. That's why I don't want to use a NOT NULL constraint.

Naively depending on NullPointerException

I could just use the data as if I expect it to be always there (and that should really be the case), and catch resulting NPEs at an appropriate level (e.g. so that the processing of the current entry stops but not the whole processing progress). This is the "fail fast" principle and I often prefer it. If it is a bug at least I get a logged NPE.

But then I lose the ability to differentiate between various kinds of missing data. E.g. for some missing data I could leave it out, but for others the processing should be stopped and an admin notified.

Checking for null before each access and throwing custom exceptions

Custom exceptions would let me decide the correct action based on the exception, so this seems like the way to go.

But what if I forget to check it somewhere? Also I then clutter my code with null checks which are never or rarely expected (and so definitely not part of the business logic flow).

If I choose to go this way, what patterns are best suited for the approach?

Any thoughts and comments on my approaches are welcomed. Also better solutions of any kind (patterns, principles, better architecture of my code or models etc.).

Edit:

There is another constraint, in that i am using an ORM to do the mapping from DB to persistence object, so doing null checks on that level would not work (as the same objects are used in parts where the null does not do any harm). I added this because the answers provided so far both mentioned this option.


问:
When is a circular reference to a parent pointer acceptable?
This Stack Overflow question is about a child having reference to its parent, through a pointer.

Comments were pretty critical initially of the design being a horrible idea.

I understand this is probably not the best idea in general. From a general rule of thumb it seems fair to say, "don't do this!"

However, I am wondering what sorts of conditions would exist where you would need to do something like this. This question here and associated answers/commentary suggests even for graphs to not do something like this.

答:
[...] suggests even for graphs to not do something like this.

Sometimes you just need to access things in a bottom-up fashion from a different data structure than the tree, while the tree needs to access things in a top-down way.

As an example, a quadtree might store elements in a vector graphics software. However, the user's selection is stored in a separate selection list of vector element references/pointers. When the user wants to delete that selection, we have to update the quadtree, and there it might be a whole lot more efficient to update the tree in a bottom-up fashion starting from the leaves rather than top-down. Otherwise you'd have to, for each element, work from root to leaf and then back up again.


问:
Is there a name for this in type theory? Specify that a value satisfies multiple interfaces without specifying the concrete type
I have often wanted the same feature which is asked for e.g. here  and in many other questions on SO:

Being able to specify that something satisfies multiple interfaces without specifying the concrete type.

e.g. in C# pseudo syntax

```<code>(IEnumerable<string>, INotifyCollectionChanged) GetStringData() {
    return /* an object which implements both interfaces */;
}
</code>```

It is possible to emulate this for method parameters using generics, but not for return values, fields, properties, etc.

Is there a name for this in type theory which I could use to find more information about this?

Are there any (strongishly typed) languages which implement this?

One example where this could be usefull would be an imaginary implementation of Stream.

Currently there is an abstract class with many methods / properties and feature-check properties which enable/disable functionality.

With this feature you could have many interfaces IReadStream, IWriteStream, ISeekable, IHasFixedLength, etc. and then say Ok, I need something where I can read and seek, so I take (IReadStream + ISeekable).

===============
(Too long for a comment)

I think the best way to implement this in C# would be a combination of returning object / explicit casting and checkers implemented with Roslyn which verify that you only cast to 'allowed' interfaces. e.g.

```<code>[MultiReturn(typeof(IReaderStream), typeof(ISeekable))]
object GetSeekableReaderStream() {
    var stream = new ConcreteReaderWriterSeekableStream();
    // stream actually implements IReaderStream, ISeekable AND IWriterStream
    // but I only want to expose the first two
    return stream;
}
</code>```

This could then be used like

```<code>var stream = GetSeekableReaderStream();
(stream as ISeekable).Seek(5); // OK
(stream as IReaderStream).Read(...); // OK
(stream as IWriterStream).Write(...); // legal for the compiler AND at runtime, but the custom analyzer would scream
</code>```

Something similar (but different) which is discussed here in roslyn would be "structural interfaces", but they are similar to ducktyping, they only enforce that specific methods are implemented, not that the object implements specific interfaces. Still this would be "near enough" that most of it would be possible.

答:
Scala allows this and calls the resulting type a Compound Type. Your example would look something like this in Scala:

```<code>def seekAndRead(stream: IReaderStream with ISeekable) {
    stream.seek(5) // OK
    stream.read(...) // OK
    stream.write(...) // Not OK
}
</code>```

IReaderStream with ISeekable is the compound type.

You're also allowed to say that a type variable is a subtype of a compound type:

```<code>class UsesStreams[A <: IReaderStream with ISeekable] {
    // use variables of type A in here
}
</code>```

Body:
Scala allows this and calls the resulting type a Compound Type. Your example would look something like this in Scala:

def seekAndRead(stream: IReaderStream with ISeekable) {
    stream.seek(5) // OK
    stream.read(...) // OK
    stream.write(...) // Not OK
}

IReaderStream with ISeekable is the compound type.

You're also allowed to say that a type variable is a subtype of a compound type:

class UsesStreams[A <: IReaderStream with ISeekable] {
    // use variables of type A in here
}


答:
In regard to this sentence in the question:

This should "theoretically" not happen, so if it does it points to bad data or a bug in the code.

I have always appreciated this quote (courtesy of this article):

I find it amusing when novice programmers believe their main job is preventing programs from crashing. I imagine this spectacular failure argument wouldn't be so appealing to such a programmer. More experienced programmers realize that correct code is great, code that crashes could use improvement, but incorrect code that doesn't crash is a horrible nightmare.

Basically: it sounds like you are endorsing Postel's Law, "be conservative in what you send, be liberal in what you accept". While great in theory, in practice this "robustness principle" leads to software that is not robust, at least in the long term -- and sometimes in the short term as well. (Compare Eric Allman's paper The Robustness Principle Reconsidered, which is a very thorough treatment of the subject, albeit mostly focused on network protocol use cases.)

If you have programs that are incorrectly inserting data into your database, those programs are broken and need to be fixed. Papering over the problem only allows it to continue to get worse; this is the software engineering equivalent of enabling an addict to continue their addiction.

Pragmatically speaking, though, sometimes you do need to enable "broken" behavior to continue, at least temporarily, especially as part of a seamless transition from a lax, broken state to a strict, correct state. In that case, you want to find a way to allow the incorrect insertions to succeed, but still allow the "canonical" data store to always be in a correct state. There are various ways to do this:

Use a database trigger to convert malformed inserts into correct inserts, e.g. by replacing missing/null values with defaults

Have the incorrect programs insert into a separate database table that is allowed to be "incorrect", and have a separate scheduled process or other mechanism that moves corrected data from that table into the canonical data store

Use query-side filtering (e.g. a view) to ensure that the data retrieved from the database is always in a correct state, even if the data at rest is not

One way to sidestep all of these issues is to insert an API layer that you control between programs that issue writes and the actual database.

It sounds like part of your problem is that you don't even know all the places that are generating incorrect writes -- or that there are simply too many of them for you to update. That's a scary state to be in, but it should never have been allowed to arise in the first place.

As soon as you get more than a handful of systems that are allowed to modify data in a canonical production data store you are going to be in trouble: there is no way to centrally maintain anything about that database. Better would be to allow as few processes as possible to issue writes, and use those as "gatekeepers" that can preprocess the data before inserting as necessary. The exact mechanism for this really depends on your specific architecture.


答:
The OP is presuming an answer that couples business rules with database technical details.

This should "theoretically" not happen, so if it does it points to bad data or a bug in the code. The errors have different severities, depending which field is null; i.e. for some fields the processing should be stopped and somebody notified, for others the processing should be allowed to continue and just notify somebody.

This is all business rules. The business rules do not care about null per-se. For all it knows the database could have null, 9999, "BOO!" ... It is just another value. That, in a RDBMS, null has interesting properties and unique uses is moot.

The only thing that matters is what "null-ness" means for the given business object(s)...

Are there any good architecture or design principles to handle the rare but possible null entries?

Yes.

Put business rules in classes.

The transliteration should be in an appropriate code layer decoupling the business classes and data store. If you can't put it in the ORM code at least don't put it in the database.

Make the database dumb as possible, no business rules here. Even innocuous things like defaulting a value will bite you. Been there.

Validate data going to and coming from the database. And of course this is done w/in the context of the business objects.

Throwing an exception upon data retrieval does not make sense.

The question is "should I store 'bad' data"? It depends:

Bad data might be used - Never save invalid objects, or object composites. Complex data/business relationships all over the place. Users can do any function at any given time, possibly using that business entity in a number of contexts. The effect (if any) of bad data, at the time it is saved, is not known because it is highly dependent on future use. There is no unified/single process of that data.

Cannot progress if there is bad data - Allow saving of bad data. However the next step in a process cannot continue until everything is valid. For example doing one's income taxes. When retrieved from the database the software points out the errors and it cannot be submitted to the IRS without validity checking.


答:
Just make a new interface that implements both IEnumerable<string> and INotifyCollectionChanged like this:

```<code>interface IBoth : IEnumerable<string>, INotifyCollectionChanged
{
}
</code>```

And then have your method return this new interface:

```<code>IBoth GetStringData() {
    return /* an object which implements both interfaces */;
}
</code>```

That's it.

Title: Is there a name for this in type theory? Specify that a value satisfies multiple interfaces without specifying the concrete type

Body:
I have often wanted the same feature which is asked for e.g. here  and in many other questions on SO:

Being able to specify that something satisfies multiple interfaces without specifying the concrete type.

e.g. in C# pseudo syntax

```<code>(IEnumerable<string>, INotifyCollectionChanged) GetStringData() {
    return /* an object which implements both interfaces */;
}
</code>```

It is possible to emulate this for method parameters using generics, but not for return values, fields, properties, etc.

Is there a name for this in type theory which I could use to find more information about this?

Are there any (strongishly typed) languages which implement this?

One example where this could be usefull would be an imaginary implementation of Stream.

Currently there is an abstract class with many methods / properties and feature-check properties which enable/disable functionality.

With this feature you could have many interfaces IReadStream, IWriteStream, ISeekable, IHasFixedLength, etc. and then say Ok, I need something where I can read and seek, so I take (IReadStream + ISeekable).

===============
(Too long for a comment)

I think the best way to implement this in C# would be a combination of returning object / explicit casting and checkers implemented with Roslyn which verify that you only cast to 'allowed' interfaces. e.g.

```<code>[MultiReturn(typeof(IReaderStream), typeof(ISeekable))]
object GetSeekableReaderStream() {
    var stream = new ConcreteReaderWriterSeekableStream();
    // stream actually implements IReaderStream, ISeekable AND IWriterStream
    // but I only want to expose the first two
    return stream;
}
</code>```

This could then be used like

```<code>var stream = GetSeekableReaderStream();
(stream as ISeekable).Seek(5); // OK
(stream as IReaderStream).Read(...); // OK
(stream as IWriterStream).Write(...); // legal for the compiler AND at runtime, but the custom analyzer would scream
</code>```

Something similar (but different) which is discussed here in roslyn would be "structural interfaces", but they are similar to ducktyping, they only enforce that specific methods are implemented, not that the object implements specific interfaces. Still this would be "near enough" that most of it would be possible.

Body:
Just make a new interface that implements both IEnumerable<string> and INotifyCollectionChanged like this:

interface IBoth : IEnumerable<string>, INotifyCollectionChanged
{
}

And then have your method return this new interface:

IBoth GetStringData() {
    return /* an object which implements both interfaces */;
}

That's it.


问:
Double-check locking around initialisation which performs a web request
I've just refactored some code that managed a global state cache of values that didn't have locking to use double check locking. Other than moving the initialisation to a single source (the cache was being set in a controller method), the main reason was to make sure only one thread was performing the initialisation at a time.

The lifetime of the cache is for the lifetime of the application, so once it is set, it should be fine.

I've locked around the code that does the web request.

My colleague, who wrote the initial code, said he was concerned about the queued threads waiting for because the initialisation makes a web request, and if the request is failing, the last thread has to wait for all the rest to go through so may have to wait awhile and so the request should be outside of the lock, but my thoughts are that a request is expensive and unreliable, and should be minimised.

As this cache doesn't expire, it's not a big deal, but what are your thoughts? I suggested that if we wanted the correct solution, we could test the locks, using Monitor.TryLock etc for some more sophisticated locking, but it's probably overkill.

答:
If you want to do lazy initialization, you should consider using Lazy<T>.  Don't reinvent this wheel.

If you would prefer to do eager initialization, you should consider using Task<T>.


问:
What is the origin of "Program to an interface, not an implementation"?
What is the origin of "Program to an interface, not an implementation"?

Does it originate from Design Patterns, 1994, by GoF, or from a computer scientist or from some concepts in computer science earlier?

答:
"Program to an interface, not an implementation" is succinct way of describing a process by which to build software, and this formulation is largely attributed to the Gang of Four.

However, the process they were describing has its roots far earlier, and originates from Kent Beck and Ward Cunningham who came up with the idea of using "pattern languages" (a concept attributed to Christopher Alexander, an architect) to write object-oriented programs.

From their OOPSLA-87 talk, "Using Pattern Languages for Object-Oriented Programs":

We propose a radical shift in the burden of design and implementation, using concepts adapted from the work of Christopher Alexander, an architect and founder of the Center for Environmental Structures. Alexander proposes homes and offices be designed and built by their eventual occupants. These people, he reasons, know best their requirements for a particular structure. We agree, and make the same argument for computer programs. Computer users should write their own programs. The idea sounds foolish when one considers the size and complexity of both buildings and programs, and the years of training for the design professions. Yet Alexander offers a convincing scenario. It revolves around a concept called a "pattern language."

A pattern language guides a designer by providing workable solutions to all of the problems known to arise in the course of design. It is a sequence of bits of knowledge written in a style and arranged in an order which leads a designer to ask (and answer) the right questions at the right time. Alexander encodes these bits of knowledge in written patterns, each sharing the same structure. Each has a statement of a problem, a summary of circumstances creating the problem and, most important, a solution that works in those circumstances. A pattern language collects the patterns for a complete structure, a residential building for example, or an interactive computer program. Within a pattern language, patterns connect to other patterns where decisions made in one influence the others. A written pattern includes these connections as prologue and epilogue. Alexander has shown that nontrivial languages can be organized without cycles in their influence and that this allows the design process to proceed without any need for reversing prior decisions.

ContentLicense: CC BY-SA 4.0


问:
Are null references really a bad thing?
I've heard it said that the inclusion of null references in programming languages is the "billion dollar mistake".  But why?  Sure, they can cause NullReferenceExceptions, but so what?  Any element of the language can be a source of errors if used improperly.

And what's the alternative?  I suppose instead of saying this:

Customer c = Customer.GetByLastName("Goodman"); // returns null if not found
if (c != null)
{
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }
```

<p>You could say this:</p>

<pre class="lang-cs prettyprint-override"><code>if (Customer.ExistsWithLastName("Goodman"))
{
    Customer c = Customer.GetByLastName("Goodman") // throws error if not found
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }
</code>```

But how is that better?  Either way, if you forget to check that the customer exists, you get an exception.

I suppose that a CustomerNotFoundException is a bit easier to debug than a NullReferenceException by virtue of being more descriptive.  Is that all there is to it?

答:
Basically the central idea is that null pointer reference issues should get caught at compile time instead of run time. So if you are writing a function that takes some object and you don't want anyone to call it with null references then type system should allow you to specify that requirement so that compiler can use it to provide guarantee that call to your function would never compile if caller does not satisfy your requirement. This can be done in many ways, for example, decorating your types or using option types (also called nullable types in some languages) but obviously that's lot more work for compiler designers.

I think it is understandable why in 1960s and 70s, compiler designer didn't go all-in to implement this idea because machines were limited in resources, compilers needed to be kept relatively simple and no one really knew how bad this would turn out 40 years down the line.

Title: Are null references really a bad thing?


问:
Is it true that calling _exit() instead of exit() won't prevent static destructors from being called?
On comp.lang.c++.moderated@googlegroups.com, Greg Herlihy posted the following extern "C" function:

```<code>extern "C"
{
    int func()
    {
        wchar_t memoryName[256];
        wchar_t mutexName[256];
        wchar_t eventName[256];
        mbstowcs(memoryName, "MemoryName", 256);
        mbstowcs(mutexName, "MutexName", 256);
        mbstowcs(eventName, "EventName", 256);
        std::wstring memoryString(memoryName);
        std::wstring mutexString(mutexName);
        std::wstring eventString(eventName);
        CDataTransferServer *srv = new CDataTransferServer();
        srv->Initialize(1, CC_SAMPLETYPE_MPEG4,128,256,64);
        printf("Inside entry point tester 1\n");
        srv->AddUser(5, memoryString, mutexString, eventString);
        printf("Inside entry point tester 2\n");
        delete srv;
        printf("Exiting entry point tester 3\n");
    }
}
</code>```

which is a g++ entry point different than main(int argc, char*argv[]).

Greg Herlihy then wrote:

Calling _exit() (which presumably should be "_Exit()") - does not "prevent"
  C++ global objects from being destroyed. The destruction of a C++ program's
  global objects is not inevitable. Instead a C++ program is responsible for
  destroying its own global objects - and can do so in one of two ways: the
  program returns from main() or it calls exit(). So a C++ program that fails
  to exit main() and neglects to call exit() before it terminates - will not
  have destroyed its global objects by the time it ended.

I don't believe that follows from what is written in the standard.

As far as I can see, when I call exit(), the spec guarantees that:

Destructors for objects with automatic storage duration
will not be called.

Destructors for objects with with static storage duration
will be called, in reverse order of construction.

The worrying thing is that the standard doesn't say anything about
    exit() or _exit(), so I'm relying on implementation-dependent behavior.

Not so. The C++ Standard specifies that calling exit() destroys global
  objects[3.6.3/1] And _Exit() is part of the C99 Standard (and will
  presumably be incorporated into the next C++ Standard by reference).

Right, the C++ standard says what exit() does, but it doesn't say what
_exit() or _Exit() do. And the C standard certainly doesn't say
anything about C++ destructors.

I don't see any implementation-defined behavior here. Calling _Exit() is no
  more likely to destroy a C++ program's global objects than calling printf()
  - or calling any other function that is not exit().

_exit() and _Exit() are specified not to call any functions registered
atexit() or on_exit(). However, that's not useful for C++ because the
C++ spec doesn't say by what means the runtime takes care of calling
destructors of objects with static storage duration. A compliant
implementation could use a mechanism other than atexit() or on_exit()
to invoke static destructors.

In other words, the C++ spec does not say anything all about the
behavior of _exit() or _Exit(). Therefore, I cannot make any assumptions
about whether or not calling either function will cause destructors
of static objects to run or not.

Any comments are welcome.

答:
I found by research and testing today that the destructors of static objects is not the issue here.
  I got the following C++ program to work.</p>

```<code>#include  <stdio.h>
#include  <iostream>
#include  <dlfcn.h>
#include "CameraControlDefs.h"
#include "DataServer.h"

using namespace std;

int main(int argc,char** argv)
{

   bool (*sayHello)(CDataTransferServer* _this, int nCameraID, CC_SAMPLETYPE nDataType,
                                unsigned int nImageWidth, unsigned int nImageHeight,
                                unsigned int nMaxFrames);

 // API api;
  unsigned int tmp;

  //...

  void* handle = dlopen("libDataServer.so", RTLD_LAZY);
  if (!handle)
  {
    std::cerr << dlerror() << std::endl;
    return 1;
  }

  // load the symbols
    create_t* create_triangle = (create_t*) dlsym(handle, "create");
    const char* dlsym_error = dlerror();
    if (dlsym_error) {
        cerr << "Cannot load symbol create: " << dlsym_error << '\n';
        return 1;
    }

    destroy_t* destroy_triangle = (destroy_t*) dlsym(handle, "destroy");
    dlsym_error = dlerror();
    if (dlsym_error) {
        cerr << "Cannot load symbol destroy: " << dlsym_error << '\n';
        return 1;
    }

    // create an instance of the class
    CDataTransferServer* poly = create_triangle();

  *(bool **)(&sayHello) = (bool *)dlsym(handle,"_ZN19CDataTransferServer10InitializeEi13CC_SAMPLETYPEjjj");
  if (dlerror())
  {
    std::cerr << dlerror() << std::endl;
    return 2;
  }

  printf("ywc = %x\n",poly);

// destroy the class

   (*sayHello)(poly, 5, CC_SAMPLETYPE_MPEG4,128,256,64);
    destroy_triangle(poly);

    // unload the triangle library
  dlclose(handle);

    //...

  return 0;

}
</code>```

Body:
I found by research and testing today that the destructors of static objects is not the issue here.
  I got the following C++ program to work.

#include  <stdio.h>
#include  <iostream>
#include  <dlfcn.h>
#include "CameraControlDefs.h"
#include "DataServer.h"

using namespace std;

int main(int argc,char** argv)
{

   bool (*sayHello)(CDataTransferServer* _this, int nCameraID, CC_SAMPLETYPE nDataType,
                                unsigned int nImageWidth, unsigned int nImageHeight,
                                unsigned int nMaxFrames);

 // API api;
  unsigned int tmp;

  //...

  void* handle = dlopen("libDataServer.so", RTLD_LAZY);
  if (!handle)
  {
    std::cerr << dlerror() << std::endl;
    return 1;
  }

  // load the symbols
    create_t* create_triangle = (create_t*) dlsym(handle, "create");
    const char* dlsym_error = dlerror();
    if (dlsym_error) {
        cerr << "Cannot load symbol create: " << dlsym_error << '\n';
        return 1;
    }

    destroy_t* destroy_triangle = (destroy_t*) dlsym(handle, "destroy");
    dlsym_error = dlerror();
    if (dlsym_error) {
        cerr << "Cannot load symbol destroy: " << dlsym_error << '\n';
        return 1;
    }

    // create an instance of the class
    CDataTransferServer* poly = create_triangle();

  *(bool **)(&sayHello) = (bool *)dlsym(handle,"_ZN19CDataTransferServer10InitializeEi13CC_SAMPLETYPEjjj");
  if (dlerror())
  {
    std::cerr << dlerror() << std::endl;
    return 2;
  }

  printf("ywc = %x\n",poly);

// destroy the class

   (*sayHello)(poly, 5, CC_SAMPLETYPE_MPEG4,128,256,64);
    destroy_triangle(poly);

    // unload the triangle library
  dlclose(handle);

    //...

  return 0;

}


问:
Starting an HTML canvas game with no graphics skills
I want to do some hobby game development, but I have some unfortunate handicaps that have me stuck in indecision; I have no artistic talent, and I also have no experience with 3D graphics.  But this is just a hobby project that might not go anywhere, so I want to develop the stuff I care about; if the game shows good potential, my graphic "stubs" can be replaced with something more sophisticated.  I do, however, want my graphics engine to render something approximate to the end goal.

The game is tile-based, with each tile being a square.  Each tile also has an elevation.  My target platform (subject to modification) is JavaScript rendering to the HTML 5 canvas, either with a 2D or WebGL context.

My question to those of you with game development experience is whether it's easier to develop an isometric game using a 2D graphics engine and sprites or a 3D game using rudimentary 3D primitives and basic textures?  I realize that there are limitations to isometric projection, but if it makes developing my throwaway graphics engine easier, I'm OK with the visual warts that would be introduced.  Or is representing a 3D world with an actual 3D engine easier?

答:
This is an extremely late answer but if you're still at it or working on something similar lately...

Sprites all the way! I worked for a long time in 3D graphics, and it's complicated. The research is always changing there, game engines are going to crazy heights, etc. You can end up spending months just learning about how to implement the latest effects and shaders, e.g. Just animating a character with bones when you start can take quite a bit of time from designing the scene graph and motion hierarchy to the IK solver.

3D modeling is also time-consuming. It can sometimes be faster if you are going for a very blocky 3D look or something since you just make a simple model and don't have to draw all the individual frames. If you're trying to make an elaborate 3D model with complex textures though, just the process of UV mapping and painting and rigging/skinning (if it's a character) might take longer than it takes you to plow through a dozen sprite sheets.

Isometric does make it a little bit tricky -- it's hard to draw isometric graphics... I'll get to that below.

I have no artistic talent, and I also have no experience with 3D
  graphics [...]

How about retro style? It's getting a resurgence. By that, I mean really chunky pixel art, like this:

It's old-school-stylish and this kind of style can actually pass for a commercial indy game.

The game is tile-based, with each tile being a square. Each tile also
  has an elevation.

Does it absolutely have to be isometric? Isometric graphics are really hard to draw. I used to do pixel art ages ago (not at all as an artist, just as a starving indy gamedev) and isometric was so hard. My lack of artistic skills showed through the most there with that kind of perspective, since I couldn't draw things properly in perspective.

It's easier to use goofy perspective like in that screenshot above, or more appropriately for yours, a top-down view. If the concept of elevation is not absolutely crucial to convey visually, like in a tactical RPG or strategy game, you can always use tiles that kind of represent that concept another way. Example:

... you can use this kind of tile view with mountains and forests and stuff with varying elevation if it's a turn-based game. It doesn't communicate the concept of elevation so directly visually, but if it's not crucial to do so, this would really help you focus on the gameplay a lot more and this kind of style still tends to be popular on web and mobile kind of contexts.

At least I used to draw sprites and tiles like in this immediate game above, and that was still time-consuming. Isometric would eat all my time, even though I still think 2D is easier. Maybe it would be useful to hook up with an artist buddy if the elevation concept is crucial to communicate visually, like in this game:


问:
What does (Lua) game scripting mean?
I've read that Lua is often used for embedded scripting and in particular game for scripting. I find it hard to picture how it is used exactly.
Can you describe why and for which features and for which audience it is used?

This questions isn't specifically addressing Lua, but rather any embedded scripting that serves a purpose similar to Lua scripting.

Is it used for end-users to make custom adjustments?
Is it used for game developers to speed up creation of game logic (levels, AI, ...)?
Is it used to script game framework code since scripting can be faster?

Basically I'm wondering how deep between plain configuration and framework logic such scripting usage goes. And how much scripting is done. A few configuration lines or a considerable amount?

答:
Is it used for end-users to make custom adjustments?

It can be used for a wide range of purposes from just configs to implementing the bulk of the game's high-end logic, e.g. It depends on the game, but Lua is just embedded scripting. People can use that as much or as little as they want.

Title: What does (Lua) game scripting mean?


问:
Name of design pattern for single-observer
Is there an existing named software design pattern similar to Observer, but for the case where only a single observer is supported rather than a collection of observers.

I find that I use this pattern fairly often, particularly in cases where an adapter has the ability to provide fan-out (notify multiple observers) on behalf of the object with the simpler call-back behavior. I would like to be able to use a name for what I'm doing that will make the most sense to others.

答:
There are two cases:

The observer is specified (passed or otherwise injected) at construction time.

The observer is registered and unregistered after construction time.

If the observer is specified at construction time, it could be thought of as a peer.

If the observer is registered and unregistered after construction time, then the fact that only one observer is supported is best considered to be an implementation detail, and not exposed in any way, shape, or form. Pretend that you support multiple observers, assert that only one ever gets registered. This way, if you ever decide to allow multiple observers in the future, nothing but the implementation needs to change.


问:
Broken Old/Legacy Unit Tests
I work for a big company and I'm responsible for a large java application with thousands of junit tests.  Since I moved to this role, there have been 200-300 broken tests (likely broken for years).  The tests are old and fragile and they're a mess of spaghetti dependencies that typically end with live sandbox data.

My goal is 100% passing tests so we can break the build on unit test failures, but I can't do it until I address the broken tests. I have very little budget because the maintenance budget is primarily for support, but my team has identified and fixed the low-hanging fruit tests (mostly config/local resource issues) and we're down to 30-40 really ugly tests.

What are some opinions on best practice?  I don't think the tests are valuable, but I also don't know what they're testing or why they don't work without digging in, which takes time and money we probably don't have.

I'm thinking we should document the statuses of the broken tests with anything we know, then either delete or ignore the broken tests completely and enter a lower-priority bug/work item to investigate and fix them.  We'll then be at 100% and start to get real value out of the other tests and if we have a maintenance/refactoring windfall we'll be able to pick them up again.

What would be the best approach?

Edit: I think this is a different question than this question because I have a clear direction for the tests that we should be writing going forward, but I inherited legacy failing tests to address before the large current set of tests becomes meaningful.

答:
In a way you're lucky. It's better to have tests that fail and shouldn't (they give you a warning at least that something's wrong) than to have tests that pass and shouldn't (which give you a false sense of security).

Of course if you have the former it's quite likely you have the latter as well (so tests that pass but should be failing).

As stated already, for now disable those failing tests but have them print a message in your test log as a constant reminder about them.

But you should definitely find the resources to go over your entire test suite in order to find and weed out the tests that pass and shouldn't, because each of them means there's a bug in your code that you're currently not detecting in your test cycles.

Using that dark cloud hanging over the code base you might well be able to get some budget for a full review of your tests, if you play it right and don't just tell them you think some tests should be looked at because they seem to fail when they shouldn't, but that you don't trust that your tests are detecting errors in your code properly, that the test set can't be trusted to do its job.

When I did that at a previous company I was working for such a review found that hundreds of tests were written with incorrect assumptions about what the code SHOULD do, leading to the code (which was written using the same incorrect assumptions) passed the tests when really it should not have. Fixing this solved many a nasty corner case bug that (while most weren't critical) could have brought down some important systems.

Title: Broken Old/Legacy Unit Tests


问:
Licensing Ghostscript in a commercial product
We are studying a prospect of using Ghostscript in a commercial product (Windows desktop application).

I read about sidestepping licensing GS altogether by simply suggesting to the users that they can download and install GS on their own to improve their experience (the software actually works without it, too, but most users would want to render/load PDF documents).

So, suppose we don't ship Ghostscript ourselves, but instead have our software check its availability and, in case if it is absent, suggest how to obtain it (short explanatory text and link to their download page). In case if it is installed, the program would use the Ghostscript API.

To me it sounds legal, as Artifex says something like "you are not allowed to ship GS if your application doesn't meet so-and-so conditions". Would anybody care to share an opinion on this?

答:
IANAL, but as long as you do not distribute Ghostscript, you do not make any copies of the program or parts of it, and you do not build any "derived work" from it, Artifex has no legal foothold against you. They obviously cannot charge you for designing your program in a way it can run an arbitrary command line utility with a configurable name and configurable parameters for PDF conversion. And I am pretty sure they cannot charge you for making the default configuration matching the signature of the current Ghostscript version.

Everything else happens by the user of the software - whatever conversion utility he installs is up to him - it is his responsibility, not yours, to use only legally obtained software for this task. And downloading, installing and just using the current Ghostscript version is perfectly legal, it is explictly allowed, encouraged and free of charge by the distributor.

So in short, what you have in mind IMHO obeys the license conditions of the current Ghostscript version.


问:
What are the complexities of memory-unmanaged programming?
Or in other words, what specific problems did automated garbage collection solve? I've never done low-level programming, so I don't know how complicated can freeing resources get.

The kind of bugs that GC addresses seem (at least to an external observer) the kind of things that a programmer that knows well his language, libraries, concepts, idioms, etc, wouldn't do. But I could be wrong: is manual memory handling intrinsically complicated?

答:
Physical Leaks

The kind of bugs that GC addresses seem (at least to an external
  observer) the kind of things that a programmer that knows well his
  language, libraries, concepts, idioms, etc, wouldn't do. But I could
  be wrong: is manual memory handling intrinsically complicated?

Coming from the C end which makes memory management about as manual and pronounced as possible so that we're comparing extremes (C++ mostly automates memory management without GC), I'd say "not really" in the sense of comparing to GC when it comes to leaks. A beginner and sometimes even a pro may forget to write free for a given malloc. It definitely does happen.

However, there are tools like valgrind leak detection which will immediately spot, on executing the code, when/where such mistakes occur down to the exact line of code. When that's integrated into the CI, it becomes almost impossible to merge such mistakes, and easy as pie to correct them. So it's never a big deal in any team/process with reasonable standards.

Granted, there might be some exotic cases of execution that flys under the radar of testing where free failed to be called, perhaps on encountering an obscure external input error like a corrupt file in which case maybe the system leaks 32 bytes or something. I think that can definitely happen even under pretty good testing standards and leak detection tools, but it would also not be quite so critical to leak a little bit of memory on something that almost never happens. We'll see a much bigger issue where we can leak massive resources even in common execution paths below in a way that GC can't prevent.

It's also difficult without something resembling a pseudo-form of GC (reference counting, e.g.) when the lifetime of an object needs to be extended for some form of deferred/asynchronous processing, perhaps by another thread.

Dangling Pointers

The real issue with more manual forms of memory management is not leaks to me. How many native applications written in C or C++ do we know of that are really leaky? Is the Linux kernel leaky? MySQL? CryEngine 3? Digital audio workstations and synthesizers? Does Java VM leak (it's implemented in native code)? Photoshop?

If anything, I think when we look around, the leakiest applications tend to be the ones written using GC schemes. But before that's taken as a slam on garbage collection, native code has a significant issue that's not related at all to memory leaks.

The issue for me was always safety. Even when we free memory through a pointer, if there are any other pointers to the resource, they will become dangling (invalidated) pointers.

When we try to access the pointees of those dangling pointers, we end up running into undefined behavior, though almost always a segfault/access violation leading to a hard, immediate crash.

All those native applications I listed above potentially have an obscure edge case or two which can lead to a crash primarily because of this issue, and there are definitely a fair share of shoddy applications written in native code which are very crash-heavy, and often in large part due to this issue.

... and it's because resource management is hard regardless of whether you use GC or not. The practical difference is often either leaking (GC) or crashing (without GC) in the face of a mistake leading to resource mismanagement.

Resource Management: Garbage Collection

Complex resource management is a difficult, manual process no matter what. GC can't automate anything here.

Let's take an example where we have this object, "Joe". Joe is referenced by a number of organizations to which he is a member. Every month or so they extract a membership fee from his credit card.

We also have one reference to Joe to control his lifetime. Let's say, as programmers, we no longer need Joe. He's starting to pester us and we no longer need these organizations he belongs to waste their time dealing with him. So we attempt to wipe him off the face of the earth by removing his lifeline reference.

... but wait, we're using garbage collection. Every strong reference to Joe will keep him around. So we also remove references to him from the organizations to which he belongs (unsubscribing him).

... except whoops, we forgot to cancel his magazine subscription! Now Joe remains around in memory, pestering us and using up resources, and the magazine company also ends up continuing to process Joe's membership every month.

This is the main mistake which can cause a lot of complex programs written using garbage collection schemes to leak and start using up more and more memory the longer they run, and possibly more and more processing (the recurring magazine subscription). They forgot to remove one or more of those references, making it impossible for the garbage collector to do its magic until the entire program is shut down.

The program doesn't crash, however. It's perfectly safe. It's just going to keep hogging up memory and Joe will still linger around. For many applications, this kind of leaky behavior where we just throw more and more memory/processing at the issue might be far preferable to a hard crash, especially given how much memory and processing power our machines have today.

Resource Management: Manual

Now let's consider the alternative where we use pointers to Joe and manual memory management, like so:

These blue links don't manage Joe's lifetime. If we want to remove him from the face of the earth, we manually request to destroy him, like so:

Now that would normally leave us with dangling pointers all over the place, so let's remove the pointers to Joe.

... whoops, we made the exact same mistake again and forgot to unsubscribe Joe's magazine subscription!

Except now we have a dangling pointer. When the magazine subscription tries to process Joe's monthly fee, the entire world will explode -- typically we get the hard crash instantly.

This same basic resource mismanagement mistake where the developer forgot to manually remove all pointers/references to a resource can lead to a lot of crashes in native applications. They don't hog up memory the longer they run typically because they will often outright crash in this case.

Real-World

Now the above example is using a ridiculously simple diagram. A real-world application might require thousands of images stitched together to cover a full graph, with hundreds of different types of resources stored in a scene graph, GPU resources associated to some of them, accelerators tied to others, observers distributed across hundreds of plugins watching a number of entity types in the scene for changes, observers observing observers, audios synced to animations, etc. So it might seem like it's easy to avoid the mistake I described above, but it's generally nowhere near this simple in a real-world production codebase for a complex application spanning millions of lines of code.

The chance that someone, some day, will mismanage resources somewhere in that codebase tends to be quite high, and that probability is the same with or without GC. The main difference is what will happen as a result of this mistake, which also affects potentially affects how quickly this mistake will be spotted and fixed.

Crash vs. Leak

Now which one is worse? An immediate crash, or a silent memory leak where Joe just mysteriously lingers around?

Most might answer the latter, but let's say this software is designed to be run for hours on end, possibly days, and each of these Joe's and Jane's we add increases the memory usage of the software by a gigabyte. It's not a mission-critical software (crashes don't actually kill users), but a performance-critical one.

In this case, a hard crash that immediately shows up when debugging, pointing out the mistake you made, might actually be preferable to just a leaky software that might even fly under the radar of your testing procedure.

On the flip side, if it is a mission-critical software where performance isn't the goal, just not crashing by any means possible, then leaking might actually be preferable.

Weak References

There is kind of a hybrid of these ideas available in GC schemes known as weak references. With weak references, we can have all these organizations weak-reference Joe but not prevent him from being removed when the strong reference (Joe's owner/lifeline) goes away. Nevertheless, we get the benefit of being able to detect when Joe is no longer around through these weak references, allowing us to get an easily-reproducible error of sorts.

Unfortunately weak references aren't used nearly as much as they probably should be used, so often a lot of complex GC applications might be susceptible to leaks even if they're potentially far less crashy than a complex C application, e.g.

In any case, whether or not GC makes your life easier or harder depends on how important it is for your software to avoid leaks, and whether or not it deals with complex resource management of this sort.

In my case, I work in a performance-critical field where resources do span hundreds of megabytes to gigabytes, and not releasing that memory when users request to unload because of a mistake like the above can actually be less preferable to a crash. Crashes are easy to spot and reproduce, making them often the programmer's favorite kind of bug, even if it's the user's least favorite, and a lot of these crashes will show up with a sane testing procedure before they even reach the user.

Anyway, those are the differences between GC and manual memory management. To answer your immediate question, I would say manual memory management is difficult, but it has very little to do with leaks, and both GC and manual forms of memory management are still very difficult when resource management is non-trivial. The GC arguably has more tricky behavior here where the program appears to be working just fine but is consuming more and more and more resources. The manual form is less tricky, but is going to crash and burn big time with mistakes like the one shown above.


答:
It sounds to me like you are just choosing to 'integrate' your product with Ghostscript, giving people the choice to use it or not. It's up to them to legally obtain a copy of Ghostscript.

We do that with many products including a PDF printer similar to Ghostscript (the one we use has to be paid for if our customers want to use it). We tell our customers that we integrate with it and it's up to them to buy it. The company who sell it can't really complain, if anything we are promoting their product by encoraging our users to buy theirs as well. It's very similar with Ghostscript, all you are doing is integrating with it and promoting it, it's up to the customer to download it, and it's up to Ghostscript to decide if they are licensed to do that for free or to pay for it.

Many products integrate with many other products all the time and as long as they are not shipping those third-party products to their customers, they don't have to worry about licencing.

As a bigger example... the application I work on uses MSSQL for it's database. It's up to our customers to provide a copy of MSSQL to enable our application to work. We don't have to worry about the licensing of that even though our application is only designed to work with MSSQL and doesn't work without it.

The main thing is probably making sure it's clear to your customers, before they buy your product, which features rely on software you don't provide. Otherwise your customer could have a case against you if they think you supply everything they need.

Title: Licensing Ghostscript in a commercial product

Body:
We are studying a prospect of using Ghostscript in a commercial product (Windows desktop application).

I read about sidestepping licensing GS altogether by simply suggesting to the users that they can download and install GS on their own to improve their experience (the software actually works without it, too, but most users would want to render/load PDF documents).

So, suppose we don't ship Ghostscript ourselves, but instead have our software check its availability and, in case if it is absent, suggest how to obtain it (short explanatory text and link to their download page). In case if it is installed, the program would use the Ghostscript API.

To me it sounds legal, as Artifex says something like "you are not allowed to ship GS if your application doesn't meet so-and-so conditions". Would anybody care to share an opinion on this?


问:
How do I go about setting up my Sinatra REST API on a server?
I'm an iOS developer primarily. In building my current app, I needed a server that would have a REST API with a couple of GET requests. I spent a little time learning Ruby, and landed on using Sinatra, a simple web framework. I can run my server script, and access it from a browser at localhost:4567, with a request then being localhost:4567/hello, as an example.

Here's where I feel out of my depth. I setup an Ubuntu droplet at DigitalOcean, and felt my way around to setting up all necessary tools via command line, until I could again run my server, now on this droplet.

The problem then is that I couldn't then access my server via droplet.ip.address:4567, and a bit of research lead me to discovering I need Passenger and an Apache HTTP Server to be setup, and not with simple instructions.

I'm way in over my head here, and I don't feel comfortable. There must be a better way for me to take my small group of ruby files and run this on a server, than me doing this. But I have no idea what I'm doing.

Any help or advice would be greatly appreciated.

答:
The problem is that Sinatra default binds to "localhost" which is only accessible from the same "ip".If you try to access from outside the droplet, you would need to bind it to 0.0.0.0. Of course, my answer is only valid for development environments. If you configure as a productive environment, the instructions you mentioned shall be followed.

Regarding how to configure to bing to 0.0.0.0, you can find more information here http://www.sinatrarb.com/configuration.html.

:bind - server hostname or IP address
  String specifying the hostname or IP address of the interface to listen on when the :run setting is enabled. The default value in the development environment is 'localhost' which means the server is only available from the local machine. In other environments the default is '0.0.0.0', which causes the server to listen on all available interfaces.

To listen on all interfaces in the development environment (for example if you want to test from other computers in your local network) use:

set :bind, '0.0.0.0'

I learnt this the hard way but with Rails, I wrote about it here (http://pietro.menna.net.br/recurse-center/2015/07/27/vagrant-rails-net-issues/).

Since both rely on Rack, this commit https://github.com/rack/rack/commit/28b014484a8ac0bbb388e7eaeeef159598ec64fc
caused the change in Sinatra & Rails (and any other Web framework which depends on Rack) to have this behavior.


答:
"Are there any good architecture or design principles to handle the rare but possible null entries?"

Simple answer - yes.

ETL

Carry out some up front processing to ensure the data is of sufficient quality to go into the database. Anything in the drop file should be reported back and any clean data can be loaded into the database.

As someone who has been both poacher (dev) and game keeper (DBA), I know from bitter experience that 3rd parties simply will not resolve their data issues unless they're forced to. Constantly bending over backwards and massaging data through sets a dangerous precedent.

Mart/Repository

In this scenario, raw data is pushed into the repository DB and then a sanitised version is pushed to the mart DB which applications then have access to.

Default values

If you can apply sensible default values to columns then you should although this can involve some work if this is an existing database.

Fail early

It is tempting to simply address data issues at the gateway to the application, report suite, interface etc. I'd strongly advise you not to solely rely on this. If you hook in some other widget to the DB you'll potentially be faced with the same problems again. Address the data quality issues.


问:
Is there a design pattern to remove the need to check for flags?
I'm going to save some string payload in the database. I have two global configurations:

encryption

compression

These can be enabled or disabled using the configuration in a way that either only one of them is enabled, both are enabled or both are disabled.

My current implementation is this:

```<code>if (encryptionEnable && !compressEnable) {
    encrypt(data);
} else if (!encryptionEnable && compressEnable) {
    compress(data);
} else if (encryptionEnable && compressEnable) {
    encrypt(compress(data));
} else {
  data;
}
</code>```

I'm thinking about the Decorator pattern. Is it the right choice, or is there perhaps a better alternative?

答:
One way to do this in scala would be:

```<code>val handleCompression: AnyRef => AnyRef = data => if (compressEnable) compress(data) else data
val handleEncryption: AnyRef => AnyRef = data => if (encryptionEnable) encrypt(data) else data
val handleData = handleCompression andThen handleEncryption
handleData(data)
</code>```

Using decorator pattern to achieve the above goals (separation of individual processing logic and how they wire together) would be too verbose.

Wherein you would require a design pattern to achieve these design goals in an OO programming paradigm, functional language offers native support by using functions as first class citizens (line 1 and 2 in the code) and functional composition (line 3)

Body:
One way to do this in scala would be:

val handleCompression: AnyRef => AnyRef = data => if (compressEnable) compress(data) else data
val handleEncryption: AnyRef => AnyRef = data => if (encryptionEnable) encrypt(data) else data
val handleData = handleCompression andThen handleEncryption
handleData(data)

Using decorator pattern to achieve the above goals (separation of individual processing logic and how they wire together) would be too verbose.

Wherein you would require a design pattern to achieve these design goals in an OO programming paradigm, functional language offers native support by using functions as first class citizens (line 1 and 2 in the code) and functional composition (line 3)


问:
Migrate legacy requirements to BDD
Q: What is the best way to move a large company to Cucumber with at least 15 years of legacy software requirements maintained in a requirements database?

Currently considering:

1) Migrate Everything

Downside: we don't have unlimited time/budget, we have to move forward to survive, we can't stop everything and GC 100% of our legacy requirements and legacy test suites.

2) Boy Scout Rule

Leave everything better than you found it. If you touch requirements or change them write/update a Cucumber feature. Downside: We will have two systems of record (Cucumber, legacy req. DB), possibly for ever assuming there are corners of a given application that don't get touched for a very long time.

3) Boy Scout Rule Plus

Same as #2 but put requirements which we are not net moving to Cucumber into Features with a single pending scenario and copy/paste the legacy requirements into the description section. This way we get metrics (via pending scenarios) as to how "covered" we are by Cucumber, and also riding us of the need to maintain the old requirements system. I can't find any downsides to this other than it might be a huge mess within Cucumber.

4) Insert your idea here.

Background:

Some projects moving to Cucumber have automated test suites, some only ever used manual testing. All of them maintain their requirements in a legacy requirements database. We have to do this because our requirements are a mixture of laws/regulation and complex logic for financial instruments (risk, pricing, structure, etc...).

Keep in mind this is a very large company making the move, which complicates solutions further.

We already have some projects using Cucumber for their "new" requirements. So we have piloted the tech and it's work for us so far. We have a mixture of web and purely data projects.

Thanks

Edit: To respond to the questions...
The legacy requirements management DB does not connect requirements to tests. It's is not "testable". Today connecting requirements to tests is done through an arduous and error prone manual process of linking requirements to our test case management system at the end of each project. Cucumber is an obvious better solution for us. There is no question about that. The question is just how to make the move for a large organization with an immense amount of important requirements that cannot be lost for legal and other reasons.

答:
I made the mistake of stripping a room down to the studs when I replaced its windows. It's an old house. The room was in bad shape. At every step along the way, I ran into issues. An old pipe crumbled in my hand. The now-dangling twenty five pound plumbing vent fell and crashed through the kitchen ceiling. (Luckily, no one was hurt but my girlfriend's charging cell phone was crushed. She was not amused.) I shocked the hell out of myself when I simultaneously brushed against a grounded and ungrounded circuit. There was exposed ancient wiring running through blown-in insulation.

With each issue, I had to redirect my energies. I stopped to fix the problem. Then, sometimes days later, I resumed forward progress. By fall, I gave up. (I planned on being done by late summer.) I just stopped and walked away. It was too much. My girlfriend wanted to call a contractor. I refused since I'd done so much work already. I didn't want them getting the "glory". (Also, I'm a bit particular and didn't want someone cutting corners where I knew I wouldn't.) So, the room sat unfinished.

Almost a year ago, after New Year, I had an epiphany: There was no rule that said I had to work exclusively on the room until it was finished. There was no rush. I didn't have to make it such a big deal. Instead, if I had a little free time, I could go upstairs and spend an hour or two in the room... hang a sheet of Sheetrock, mud and tape a wall, trim up a door. Before I knew it, I was done. My girlfriend loved me again. I slept with a grin on my face. All was right in the world.

I think there's something similar available for your predicament. Be the wise tortoise -- slow and steady. The "Migrate Everything" path is too stressful. It'll make you throw up your hands and walk away. The Boy Scout Rule leaves features behind if they never change. The Boy Scout Rule Plus creates sub-par requirements. Take the best of your approaches:

If you touch a requirement, move it to Cucumber.

In the meantime, set a weekly migration goal. Do a little bit each week. Don't make it an all or nothing proposition. You may find that the occasional migration work is a nice reprieve from all the other work you've committed to.

Before you know it, you'll be done. Your boss will love you. Your team will love you. You'll sleep with a smile on your face.

Title: Migrate legacy requirements to BDD