language-design

问题 As I know, any class that is designated to have subclasses should be declared with virtual destructor, so class instances can be destroyed properly when accessing them through pointers. But why it's even possible to declare such class with non-virtual destructor? I believe compiler can decide when to use virtual destructors. So, is it a C++ design oversight, or am I missing something? 回答1: Are there any specific reasons to use non-virtual destructors? Yes, there are. Mainly, it boils down to

问题 There are three thread models that are used in thread scheduling implementations usually done by OS Kernels. One of them is the hybrid ( M:N ) model in which some N application threads are mapped to M kernel threads so that they can use up to M processors. There are pros and cons to this model. One of the advantages is that the languages that are based on this model will introduce a language level scheduler implementation that is responsible for management and scheduling the application-level

问题 In C++, the lifetime of a temporary value can be extended by binding it to a reference: Foo make_foo(); { Foo const & r1 = make_foo(); Foo && r2 = make_foo(); // ... } // both objects are destroyed here Why is this allowed? What problem does this solve? I couldn't find an explanation for this in Design and Evolution (e.g. 6.3.2: Lifetime of Temporaries). Nor could I find any previous questions about this (this one came closest). This feature is somewhat unintuitive and has subtle failure

问题 I've read "what-is-turing-complete" and the wikipedia page, but I'm less interested in a formal proof than in the practical implications of being Turing Complete. What I'm actually trying to decide is if the toy language I've just designed could be used as a general-purpose language. I know I can prove it is if I can write a Turing machine with it. But I don't want to go through that exercise until I'm fairly certain of success. Is there a minimum set of features without which Turing

问题 struct A { void f() {} }; void f() {} int main() { auto p1 = &f; // ok auto p2 = f; // ok auto p3 = &A::f; // ok // // error : call to non-static member function // without an object argument // auto p4 = A::f; // Why not ok? } Why must I use address-of operator to get a pointer to a member function? 回答1: auto p1 = &f; // ok auto p2 = f; // ok The first is more or less the right thing. But because non-member functions have implicit conversions to pointers, the & isn't necessary. C++ makes

问题 struct A { void f() {} }; void f() {} int main() { auto p1 = &f; // ok auto p2 = f; // ok auto p3 = &A::f; // ok // // error : call to non-static member function // without an object argument // auto p4 = A::f; // Why not ok? } Why must I use address-of operator to get a pointer to a member function? 回答1: auto p1 = &f; // ok auto p2 = f; // ok The first is more or less the right thing. But because non-member functions have implicit conversions to pointers, the & isn't necessary. C++ makes

问题 I'm designing a language, and I'm wondering if it's reasonable to make reference types non-nullable by default, and use "?" for nullable value and reference types. Are there any problems with this? What would you do about this: class Foo { Bar? b; Bar b2; Foo() { b.DoSomething(); //valid, but will cause exception b2.DoSomething(); //? } } 回答1: My current language design philosophy is that nullability should be something a programmer is forced to ask for, not given by default on reference

问题 Is there a way of forcing a (child) class to have constructors with particular signatures or particular static methods in C# or Java? You can't obviously use interfaces for this, and I know that it will have a limited usage. One instance in which I do find it useful is when you want to enforce some design guideline, for example: Exceptions They should all have the four canonical constructors, but there is no way to enforce it. You have to rely on a tool like FxCop (C# case) to catch these.

问题 In the Reference of HttpRequest.HttpMethod of .NET Framework, request type is declared with System.String type. In RFC 2616 all HTTP request methods are declared (e.g. POST, GET, PUT, DELETE...). There's also similar behavior in HttpWebRequest and WebRequest classes of .NET. Java has the similar approach on HttpURLConnection#setRequestMethod(String) method. Why do these language designers do not consider implementing an enum for those HTTP methods? Do you have an idea? 回答1: The first

问题 It seems like in most mainstream programming languages, returning multiple values from a function is an extremely awkward thing. The typical solutions are to make either a struct or a plain old data class and return that, or to pass at least some of the parameters by reference or pointer instead of returning them. Using references/pointers is pretty awkward because it relies on side effects and means you have yet another parameter to pass. The class/struct solution is also IMHO pretty awkward