常連

回答者

ベストアンサー

以下のコードを書いてみました

```java
public List<String> returnStringList(String value) {
    List<String> list = new ArrayList<String>();
    if (value != null) {
        list.add(value);
        list.add(null);
        return list;
    } else {
        return null;
    }
}
```

これをKotlinから呼び出してみました
```kotlin
 val test = Test().returnStringList("test")
```

これは以下のようになると予測していました
```kotlin
 val test: List<String?>? = Test().returnStringList("test")
```

しかしIDEAで型を見てみると以下のように見慣れない記述がされていました
```kotlin
 val test: (MutableList<String!>..List<String!>?)
```


なぜこのような形になるのか詳しいかた、詳細に解説をお願いします。
（この..は何なのか？rangeTo?そういったとこまで知りたいです）

上記のJava関数をIDEAの機能でKotlinコードに変換しても`List<String?>?`が戻り値になるので、同義なのだろうなとは思っています。

List型を返すJavaライブラリの関数をKotlinから呼んだ時のKotlin上での型について教えてください

[C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)を読んでいて納得できない部分があります。


[C.139: Use final on classes sparingly](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c139-use-final-on-classes-sparingly)の項目です。

calssに対するfinalを控えめにするという項目で、理由として以下の様に書いてあります。

> Reason Capping a hierarchy with final classes is rarely needed for logical reasons and can be damaging to the extensibility of a hierarchy.


* 継承を禁止する論理的な理由があることはめったにない
* クラスの拡張性を損なう

という内容かと思いますが、個人的には納得できませんでした。
constを推奨するのと同じような理由でfinalは積極的に使っていきたいように感じます。


この理由について掘り下げて議論している書籍、Webの情報などが知りたいです。
独自見解、他言語での状況などでも大丈夫です。

基本的には納得してCore Guidelinesに従いたいと思っているので、こうするべきとされている理由をより深く知りたいです。

よろしくおねがいします。

C++でclassにfinalを控えめに使うべき理由について

## 環境

* C++11
* Visual Studio 2017 15.8.1
* gcc version 5.4.0

## 概要

「two-phase name lookup」に関する自分の理解は以下の通りです。
* 先にテンプレート引数に依存しないものを名前解決する。
* 次にテンプレート引数に依存するものを名前解決する。

しかし、なぜ2段階で名前解決する必要があるのでしょうか。
「two-phase name lookup」をしないで、全部解析してから名前解決を行うのではなにか問題があるのでしょうか。

## 質問の背景

以下のコードが Visual C++ ではコンパイルが通り、gcc では通らない原因について「[C++ - gcc でコンパイルすると、親クラスのメンバー変数を子クラスから参照できない問題について](https://teratail.com/questions/179231)」で質問させていただきました。
そうしたところ、「two-phase name lookup」という仕様によるものであるということをご教示いただきました。

```cpp
#include <iostream>

// 親クラス
template <class Child, class SomeType>
struct Base
{
    void interface()
    {
        static_cast<Child *>(this)->implementation();
    }

    void set_value(SomeType value)
    {
        member_ = value;
    }

  public:
    SomeType member_;
};

// 子クラス
template <class SomeType>
struct Derived : Base<Derived<SomeType>, SomeType>
{
    void implementation()
    {
        std::cout << member_ << std::endl;
    }
};

int main(int argc, char *argv[])
{
    Derived<int> obj;
    obj.set_value(1);
    obj.interface();
}
```

なぜ Visual C++ ではビルドが通ったのか調べたところ、Visual C++ 15.3 以前では「two-phase name lookup」が実装されておらず、15.3 以降でもデフォルトでは無効になっており、`/permissive-` コンパイラオプションを有効にすると、機能するとのことでした。

[C++ Team Blog | Two-phase name lookup support comes to MSVC](https://devblogs.microsoft.com/cppblog/two-phase-name-lookup-support-comes-to-msvc/)

なので、試しに `/permissive-` オプションを有効にしてビルドしたところ、gcc と同様、名前解決に失敗することが確認できました。

```
エラー: C3861: 'member_': 識別子が見つかりませんでした
```

ここで思ったのは、VC++ でデフォルトでは「two-phase name lookup」をしないで、名前解決できているのだから、なぜこの仕様が必要なのかというのが質問に至った背景です。

すみませんが、よろしくおねがいします。

## 回答いただいた内容に関する理解

alphya さんにご回答いただいた内容を自分の勉強用に整理しました。
もし誤った解釈があれば、ご指摘いただければ幸いです。

----

* テンプレートの元々の意図は、型が異なり内容が同じクラスや関数を複数作る必要がないようにするため。(例: sqrt, sqrtf, sqrtl)
* 昔はテンプレート引数に非依存の識別子を先に名前解決することは、許可及び推奨されていたが、必須ではなかった。
* そのため、識別子の名前解決はテンプレートの定義の解析時には行わないで、テンプレートを実体化するまで名前解決を遅らせることができた。

### 「two-phase name lookup」が必要になった理由

テンプレートの実体化時に名前解決を行う方法だと、テンプレートが前後の文脈に依存する状況がおき、バグを引き起こしやすくなる。

例:
```cpp
#include <cstdio>

void func(void*) { std::puts("The call resolves to void*") ;}

template<typename T> void g(T x)
{
    func(0);
}

void func(int) { std::puts("The call resolves to int"); }

int main()
{
    g(3.14);
}
```

* two-phase name lookup を行う場合

テンプレートが定義された段階で `template<typename T> void g(T x)` の中身の解析が行われる。
この時点で `func(0)` にマッチするものは、`void func(void*)` だけなので、`void func(void*)` に名前解決される。

* two-phase name lookup を行わない場合

`g(3.14)` でテンプレートが実体化された時点で `template<typename T> void g(T x)` の中身の解析が行われる。
この時点で `func(0)` にマッチするものは、`void func(int)` と `void func(void*)` の2つがあるので、`void func(int)` に名前解決される。
もし、`void func(int)` がなかったならば、`void func(void*)` に名前解決される。
このように、テンプレートの後に `void func(int)` があるかどうかでテンプレートの意味が変わってしまう。 (前後の文脈に依存してしまう)

### MSVC のバージョン 15.3 以前の実装

* テンプレートは宣言だけチェックして、定義の部分は記録だけしておき、実体化されるまで中身のチェックはしない。
* テンプレートの実体化が必要になった段階で、記録してあるリストからテンプレートの実装を探してきて、中身をチェックする。

#### 例1: テンプレートの中身は、実体化されるまでチェックされない。

```
#include <cstdio>

template <typename T>
void hoge(T t) {
    1  // ; がない
}

int main()
{
}
```

gcc: `source_file.cpp:5:6: error: expected ';' after expression`
vc++: コンパイルが通る。

#### 例2: テンプレートが定義された段階では曖昧さがあっても、実体化された段階で曖昧さがないケース

```cpp
#include <cstdio>
#include <vector>

template<class C>
void f(const C &container) {
  C::const_iterator *x;
}

int main()
{
    std::vector<int> v;
    f(v);
}
```

テンプレートが実体化されていない段階では、`C::const_iterator` は型なのかクラス `C` で定義された static 定数なのかわからない。

* `C::const_iterator` が型と解釈した場合: `C::const_iterator *x;` は型 `C::const_iterator` のポインタ `*x`
* `C::const_iterator` が定数と解釈した場合: `C::const_iterator *x;` は定数 `C::const_iterator` と変数 `x` の乗算
`C::const_iterator` を型と認識させるには `typename C::const_iterator` と指定する必要がある。

```cpp
#include <cstdio>
#include <vector>

template<class C>
void f(const C &container) {
  C::const_iterator *x;
}

int main()
{
    std::vector<int> v;
    f(v);
}
```

gcc:
```
source_file.cpp: In function ‘void f(const C&)’:
source_file.cpp:6:22: error: ‘x’ was not declared in this scope
   C::const_iterator *x;
                      ^
source_file.cpp: In instantiation of ‘void f(const C&) [with C = std::vector<int>]’:
source_file.cpp:12:8:   required from here
source_file.cpp:6:21: error: dependent-name ‘C:: const_iterator’ is parsed as a non-type, but instantiation yields a type
   C::const_iterator *x;
                     ^
source_file.cpp:6:21: note: say ‘typename C:: const_iterator’ if a type is meant
```
vc++: コンパイルが通る。

two-phase name lookup を行う gcc は実体化前に解析するのでエラーとなるが、MSVC は実体化された段階で解析するので、この時点では `C::const_iterator` は型と判明しているのでエラーにならない。 

### 参考文献

- [Two phase name lookup for C++ templates - Why? - Stack Overflow](https://stackoverflow.com/questions/12561544/two-phase-name-lookup-for-c-templates-why)
- [What exactly is "broken" with Microsoft Visual C++'s two-phase template instantiation? - Stack Overflow](https://stackoverflow.com/questions/6273176/what-exactly-is-broken-with-microsoft-visual-cs-two-phase-template-instanti)
- [C++ Team Blog | Two-phase name lookup support comes to MSVC](https://devblogs.microsoft.com/cppblog/two-phase-name-lookup-support-comes-to-msvc/)
- [A Proposed New Template Compilation Model](http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1996/N0906.pdf)

C++ - Two phase name lookup という言語仕様はなぜ必要なのでしょうか

scalaで型を変換した直後にmap関数を使うとエラーになるのですが原因が分かりません。
```scala
// エラー
val list = List(1,2,3,4,2).toSet.map(n => n + 1) 
println(list)

// OK
val list = List(1,2,3,4,2)
val set = list.toSet
println(set.map(n => n + 1)
```
どういう理屈でこのような違いが出るのでしょうか？

#### Seqだとうまくいく
```scala
// OK
val seq = List(1,2,3,4,2).toSeq.map(n => n + 1)
println(seq)
```

scala メソッドチェーンができない理由

### 実現したいこと

東京海上日動プログラミングコンテスト2020の[E問題O(rand)](https://atcoder.jp/contests/tokiomarine2020/tasks/tokiomarine2020_e)で包除原理を用いて解いたのですが、サンプルケースは全てACになるもののテストケースのほとんどでWAになってしまいました。
解説や他の方の解答などを読んでも方針は間違っていないと思いオーバフローなどもないように思われるので、原因の究明をお願いしたいです。
また、デバッグしていただきやすいようにコメントアウトでやりたいことを書いてあります。よろしくお願いします。

### ソースコード

```c++
#include <bits/stdc++.h>
using namespace std;
typedef long long ll;

//マクロ
//forループ関係
//引数は、(ループ内変数,動く範囲)か(ループ内変数,始めの数,終わりの数)、のどちらか
#define REP(i,n) for(ll i=0;i<(ll)(n);i++)
#define FOR(i,a,b) for(ll i=a;i<=(ll)(b);i++)
//xにはvectorなどのコンテナ
#define ALL(x) (x).begin(),(x).end() //sortなどの引数を省略したい
#define SIZE(x) ((ll)(x).size()) //sizeをsize_tからllに直しておく
//定数
#define INF 1000000000000 //10^12:極めて大きい値,∞
#define MOD 1000000007 //10^9+7:合同式の法
#define MAXR 100 //10^5:配列の最大のrange(素数列挙などで使用)
//略記
#define PB push_back //vectorヘの挿入
#define MP make_pair //pairのコンストラクタ
#define F first //pairの一つ目の要素
#define S second //pairの二つ目の要素


signed main(){
    //入力の高速化用のコード
    ios::sync_with_stdio(false);
    cin.tie(nullptr);
    ll n,k,s,t;cin >> n >> k >> s >> t;
    vector<ll> b(n);REP(i,n)cin >> b[i];
    vector<ll> a;
    //i bit目を見て、s_i=1.t_i=1の時は全ての数のi bit目が1→当てはまらないのは除く
    //i bit目を見て、s_i=0.t_i=0の時は全ての数のi bit目が0→当てはまらないのは除く
    //i bit目を見て、s_i=1,t_i=0の時は0を出力
    //i bit目を見て、s_i=0,t_i=1の時は候補に入れる
    REP(i,n){
        bool f=true;
        REP(j,18){
            bool s_,t_,b_;s_=(s>>j)&1;t_=(t>>j)&1;b_=(b[i]>>j)&1;
            if(s_ and t_){
                if(!(b_)){
                    f=false;break;
                }
            }else if(!(s_) and !(t_)){
                if(b_){
                    f=false;break;
                }
            }else if(s_ and !(t_)){
                cout<<0<<endl;return 0;
            }
        }
        if(f)a.PB(b[i]);
    }
    n=SIZE(a);
    k=min(n,k);
    //以下ではそれぞれのbitは0と1が少なくとも一つなければならない
    //余事象は、全ての数で1だけまたは0だけのbitが少なくとも一つある場合
    //少なくとも一つ→包除原理
    //それぞれのbitで"0だけになる集合"と"1だけになる集合"を用意すると、3^L(L=18)になる→O(N×3^L)
    //0だけor1だけなので分割してく
    //チェックするのは結局N個くらいで済む→O(N×2^L×L)
    
    //以下、集合はbitで表現

    //まずは、それぞれのbitで集合を分割(そのbitが1か0かで二つに分割→pairで保存)
    vector<pair<ll,ll>> bits;
    REP(i,18){
        ll f1=0;ll f2=0;
        REP(j,n){
            if((a[j]>>i)&1){
                f1+=(1<<j);
            }else{
                f2+=(1<<j);
            }
        }
        if(f1 and f2)bits.PB(MP(f1,f2));
    }
    ll bits_len=SIZE(bits);

    //集合分割したのでさらに分割を行う(部分集合全列挙したいのでbit全探索)
    //余事象が何通りあるかをans_subに格納
    ll ans_sub=0;

    //ここで答えでの組み合わせの前計算しておく
    //prior_calc[i][j]：iC1+iC2+…+iCjの答え(i:1~n,j:1~k)
    //0-indexed
    vector<vector<ll>> pcalc(n+1,vector<ll>(k+1,0));
    pcalc[0][0]=1;
    FOR(i,1,n){
        pcalc[i][0]=1;
        FOR(j,1,k){
            pcalc[i][j]=pcalc[i-1][j-1]+pcalc[i-1][j];
        }
    }
    REP(i,n+1){
        pcalc[i][0]=0;
        REP(j,k){
            pcalc[i][j+1]+=pcalc[i][j];
        }
    }

    //bit全探索でありうる積集合のパターンを全て考える
    //2^L
    //all_setsにはそこまでで分けられた集合を集合ごとに保存(bitでどの要素が含まれるか表す)
    deque<ll> all_sets;
    FOR(i,1,(1<<bits_len)-1){
        //まず全ての要素が同じ集合に含まれているものとする
        all_sets.PB((1<<n)-1);
        //L
        //包除原理において、積集合で考える集合の個数の偶奇が知りたいので
        ll odd_even=0;
        REP(j,bits_len){
            //そのbitを積集合を考えるbitとして考慮に入れる時
            if((i>>j)&1){
                odd_even+=1;
                ll s=SIZE(all_sets);
                //n
                //今分けられている集合それぞれをさらに(そのbitが0か1かで)分割する
                REP(_,s){
                    //積集合をとりたい集合を書き出す
                    ll ins=*(all_sets.begin());
                    all_sets.pop_front();
                    //insはf1とf2へと分割される
                    ll f1=ins&(bits[j].F);ll f2=ins&(bits[j].S);
                    //f1,f2が0の時は空集合なので0通りより無視
                    if(f1){all_sets.PB(f1);}
                    if(f2){all_sets.PB(f2);}
                }
            }
        }
        //積集合のパターンを決めた下で完全に集合を分割できた
        //それぞれの集合に対して1以上K以下の数を選ぶ(pcalcを使う)
        ll s=SIZE(all_sets);
        //n
        REP(_,s){
            ll now=*(all_sets.begin());
            all_sets.pop_front();
            //立ってるbit数を数える(注目する集合の要素数を数える)
            ll s_sub=__builtin_popcount(now);
            //前計算で求めたpcalcから求める
            //ここで、包除原理より+-が決まる
            if(odd_even%2){
                ans_sub+=pcalc[s_sub][min(k,s_sub)];
            }else{
                ans_sub-=pcalc[s_sub][min(k,s_sub)];
            }
        }
    }
    //ans_subは余事象のパターン数で、全体のパターン数からその余事象のパターン数を引く
    cout<< pcalc[n][k]-ans_sub <<endl;
}
```

東京海上日動プログラミングコンテスト2020のE問題O(rand)の包除原理を用いた解法のWAの原因を教えていただきたいです。

契約プログラミングについてですが、事前条件についてはわかりましたが、残りの二つについてあまり理解ができません。
例えば以下の簡単なFunctionにて事前条件の違反となれば、二つの引数を想定しているのに対して一つだけやまたはタイプの違うstringを渡してもErrorで帰ってきます。これを事前条件の違反というのはsimpleで分かりやすいですが、事後条件と不変条件はwikipediaで見ても難しい言葉で説明してあってあんまりイメージがわきません。
大変初歩的な質問ではあると思いますが残り二つの違反とはどういうものなのか書きの簡単なFunctionを例に説明していただければと思います。
> 事後条件 (postcondition)
サブルーチンが、終了時に保証すべき性質。
不変条件 (invariant) 
クラスなどのオブジェクトがその外部に公開しているすべての操作の開始時と終了時に保証されるべき、オブジェクト毎に共通した性質。
コードを呼ぶ側が事前条件と不変条件を満たす義務を負うことで、呼ばれたコードはその条件が恒真であるとの前提を利益として得る。引き換えに、呼ばれたコードは事後条件と不変条件を義務として負い、呼ぶ側の利益としてこれを保証する。...wikipediaより
```Python
def add_cal(a,b):
    sum = a + b
    print(sum)

add_cal(3)
```

契約プログラミングについて事後条件と不変条件がよくわかりません。

KotlinでのAndroidアプリ開発の学習をしている最中です。
仕事で開発するアプリの仕様に、一番下にリサイクラービューがスクロールされるたびにデータを読み込むというものがあります。
現在練習で作ったアプリで、下記のように書いてJSONデータを取得しています。

```Kotlin


    private inner class DownloadJsonData(): AsyncTask<String, String, String>() {
        override fun doInBackground(vararg params: String?): String {
            val urlStr = "https://api.myjson.com/bins/vxnji"
            val url = URL(urlStr)
            val con =  url.openConnection() as HttpURLConnection
            con.requestMethod = "GET"
            con.connect()
            val stream = con.inputStream
            val sb = StringBuilder()
            val reader = BufferedReader(InputStreamReader(stream, "UTF-8"))
            var line = reader.readLine()
            while(line != null) {
                sb.append(line)
                line = reader.readLine()
            }
            reader.close()
            val result = sb.toString()
            con.disconnect()
            stream.close()
            //JSON文字列
            return result
        }
.
.
.



```


この **val stream = con.inputStream** でレスポンスデータを取得し格納されるとのことですが、このレスポンスデータを上10件ずつ、のように切り分けて少しずつ取得することというのは可能なのでしょうか。（通信の負荷を軽くするためにそのような仕様にするようにと指示されました。）
可能だとしたら、どのようにして行われるのでしょうか。
参考になるようなウェブページや、調べ方などを知っていたら、ご教示頂けると幸いです。