【日本最速３階級制覇】井上尚弥 120【Monster】
■ このスレッドは過去ログ倉庫に格納されています
まーた逆張りガイジの玄人（笑）が湧いてるのか
ど素人でも見抜けた未来のスーパーチャンピオンを雑魚の一点張りしてたメクラが何を言ってるんだか
八百長は格下選手がやること、そもそも現代で作られたチャンピオンを作る意味がないこと
普通の頭してればわかるはずなんだがね >>90
ドネアって階級下のチビに勝っただけじゃねーの バンタム級の２大会連続金メダリストがプロに転向する噂だが
井上より遥かに強そうなのが現実ですな。 >>104
井上はレベル低い日本で五輪代表にすらなれず、世界大会も3回戦負け 俺は井上vsドネアがみたい
このトーナメントで初めてかな本物と試合するのは
名誉挽回できるかなw >>93
それでプロの試合もしたのに何が違うのか教えてみろよ
適当言ってんなドアホ ドネアより井上の方が強いけど、他のメンバーとやればなかなか面白そう
多分ドネア普通にやれると思うよ グローブの結び方を知っていることだけが他人にマウントを取れるたった一つ心の拠り所な人生 >>111
誰がグローブ無しで試合したって？
何だおまえキチガイだったのか >>108
井上が五輪代表にすらなれてないのはあまりにも有名 ドネアはウォータースをグラつかせて
ゴングに救われたけど、
あと数十秒あったらKOしてたかもしれない。
マグダレノ戦もフランプトン戦も負けはしたけど一方的では無かったしまだまだ強いと思う >>117
それなら正解を書いてみろよカスw
俺も何度も縛ったが>>57で合ってるよ >>109
ちなみに一番弱いとされるバーネットですら、井上が世界大会で二度惨敗した選手に勝っている。
井上の実力は他より段違いに低い ボクシング世界王者を育てた家族の軌跡（高校、大学、アマ、プロ、日本チャンピオン、世界チャンピオン）総集編２５分
http://kisu.me/Cvx
8分台の手紙（作文）が泣ける >>120
横からだけどそれってスパー用の
風船グローブの縛り方だよね？ >>124
俺が縛ったのはスパー用
風船グローブって何？ >>124
おまえスパー用グローブで試合すんの？
もっと知ったかぶりして
俺を笑かしてくれ >>124
焦って自分にアンカーうつし
わかりやすいアホ >>125
グローブの縛り方じゃねえの？
馬鹿だから>>33で自分が書いたことも忘れたか >>124
キチガイ
クソ笑える
ID:IOQ/ppU8
0111 名無しさん名無しさん＠腹打て腹。 2018/07/07 10:16:17
>>93
それでプロの試合もしたのに何が違うのか教えてみろよ
適当言ってんなドアホ >>121
だからアマ時代を比べても無意味だって
アマは3Rプロの世界戦は12Rだし井上はアマ時代プロのライトフライからと比べて格段に強くなってる
現段階でのレベルで比べないと意味がない >>127
ブーメラン刺さってるアホ
ID:IOQ/ppU8
0111 名無しさん名無しさん＠腹打て腹。 2018/07/07 10:16:17
>>93
それでプロの試合もしたのに何が違うのか教えてみろよ
適当言ってんなドアホ >>130
何がブーメランなのか意味わからん
ID:IOQ/ppU8と俺は別人なんだか？ >>129
アマ実績は正直
ちなみに内山も五輪代表にすらなれてないし、山中にいたっては国内選手にすら勝ったり負けたりする平凡な選手
井岡はも大学アマで勝てないから
中退してプロに逃亡してる >>131
君さぁ
初心者スレいって質問すれば？
ここは井上スレ
邪魔だよ お前ら優しいな相変わらず。
だまってNGでいーじゃんよw >>129
何言っても無駄だからスルーしろよ
つーかボク板はスルースキルないよな グローブの縛り方も知らない人って
ここにいるんだ 驚き >>75
ロマチェンコが落ちたんじゃなく、リナレスが予想以上に強かったんだと思う
ロマチェンコ戦のリナレスはマイキーより強かった
PFPで井上を上回ってもおかしくないくらい >>137
じゃあ縛り方書いてみ
>>57のどこが間違ってるのかも >>104
アマで勝てなくて挫折した井上と
くらべたら相手に失礼 >>140
スパーの話とか興味ないし
金でもくれるの？ >>142
逃げてんじゃねえよカスw
笑い者はそっちだろ 井上はアマで挫折を味わったからこそ平常心で試合をしようと意識するようになったと言ってる
https://sports.yahoo.co.jp/m/column/detail/201712270004-spnavi
負けないことより、負けて強くなることの方が重要だと思う
リナレスとか負けて引退寸前になってから強くなったタイプだし、
ロマチェンコだってサリドに負けたからプロとしての戦い方を覚えた感じだし >>132
アマ実績が正直ならフロイドメイウェザーは銅メダルだしタイソンに至ってはメダルすら取れてない
けどプロになってから金メダリストもKOしてるしアマで負けた相手にプロでKOしとるがなw
おかしなこと言うてたらあかんで ロマチェンコは階級の壁にぶち当たった感じだろ
リナレスがダウン奪った時はここ数年で一番興奮したけど惜しかったな
リナレスは好きなボクサーだがマイキーとやればやや分が悪いと思う STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
---- テンプレ ここまで ---- >>36
常に最新を使えとまでは思わんが、さすがに C++11 は人権だと思うぞ。
C++14 や C++17 はユーザ視点では重要なものも含まれるとは思うが、
C++11 に間に合わなかったりミスがあったりしたのを補った、
マイナーアップデーという印象は有るな。 >>39
えっ、それって重要な機能のひとつじゃね？
ライブラリは標準になくてもなんとかなるけど、
基礎的な機能で大事なトピックがてんこ盛りなのが C++11 でしょ。
最低でも
auto
decltype
constexpr
可変長引数テンプレ
あたりは無いとつらすぎるんですけど！ >>44
> ちなみに他言語を使わない理由は何だ？
Scheme スレが私の巣だと思ってるくらいには Scheme 派なんだけど、
話題が少なくて暇だからこっちに出てきてる感じ。
> おそらく君はインラインアセンブラとか全く使わない人だろ？
使わないに越したことは無いというのが基本姿勢ではあるけど、使う必要があるので使うよ。
どういう意図で言ってんのかよくわかんないんだけど、
C++11 以降に加わった機能がスゲー大事という気持ちとこれらが何か関係あるの？ >>47
俺はC++を使う利点は
・高位から低位まで同一言語でカバー出来る点
だと思っていて、逆に言えば、
高位でしか組まないのなら他高位言語を使った方がいいと思ってるんだよ。
だからC++の利点を生かす為には、
・高位の機能と低位の機能を混ぜて使う
＝スマポもラムダもナマポもインラインアセンブラも 『同時に』 使う
事が必要で、逆に、このスレに巣くっているナマポ禁止な連中には若干懐疑的なんだよ。
それなら他言語の方が生産性が高いから。
必要ならその部分だけCのDLLにすれば済む話だし。
そして最近の新機能は高位向けの物が多いから、聞いてみたわけだ。
Schemeは知らんが、他高位言語を使っているのなら済まんかった。 >>52
矛盾してない。
高水準の部分はC++は他言語に対して後れているから、
C++がそれを追加するのは妥当ではある。
ただ、俺なら他言語で組んで、CのDLLを呼ぶようにする。
それだと、他言語の進んでいる高水準機能を使えるから。
わざわざ遅れているC++に対して文句を言いながら使う意味がない。
例えば、C#がその作りになってるでしょ。
マーシャルがウザイか、C++の機能的周回遅れがウザイかってだけ。
勿論、インラインアセンブラを使いたいならC++しか解がない。
で、ナマポ禁止派はいったい何がしたいんだ？ってのが疑問で、
それだったら俺と同じでC#＋CのDLLで良いじゃん、と思うわけ。 話をぶった切ってすんません。
複数のスレッドで
thread_local int* p;
p=new int [1000];
で確保したヒープ領域はやっぱりスレッドセーフ、じゃない、データ競合が
おきるんですか？ >>61
明確です。
newで確保される領域はダイナミックストレージに属します。
これは他のスレッドと同時に読み書きを行えば競合します。
thread_localで確保されたint* pはスレッドストレージに属します。
これは複数のスレッドで別のページに属します。
従って、pに対して読み書きしている分には競合しません。 >>70
それで何が嬉しいんだ？
ついでに質問しておこう。
君はCのような自前でリソース管理をしなければならない言語でリソース管理をしたことがあるか？
あと、これはC++er全般に対してだが、
shared_ptrが絶対に必要なケースってのは何だ？
unique_ptrで後述A,B以外の使い方Dがあるか？(なおCは予約語) >>68,79
そもそもpimpl自体が要らんだろ。
あれはC++のコンパイラが単純に仕様変更
・ヘッダにはprivate関数は書く必要がありません
すればいいだけの話で、そもそも「名前空間は開いていますが、クラスは閉じています(ｷﾘｯ」を、
「ヘッダのクラスは開いていますが、実装のクラスは閉じています(ｷﾘｯ」にすればいいだけ。
編集上の都合でソースが汚れるとか、全く馬鹿な話だろ。
気づけよ。 Javascriptを使って感じるC++の有利な点は仕様の明確さだろう。
Javaは重いと言われユーザーに嫌われる言語のひとつだが、開発者はベンチマークを提示しC++の20倍速いと言う。
しかしユーザーは実際に重くて困っているだろう。
ブラウザも同じ問題を抱えていて、当然Javascriptも重いとユーザーは感じている。 >>84
たいしたこといってないです。
~dtor() {
. if (...) {
. return;
. }
. delete ptr;
}
>>86
pmplがバッドノウハウに属するものであることは同意だけどprivateメンバ変数はどうするつもり？ キャッシュは不意のアクセスに備える目的のやつだから
今誰もアクセスすなくなったからといって即開放（例： キャッシュラインをinvalidate）したら意味半減くね…？
というわけで、参照カウントの使用例としては不適切くね…？？
それはそうとして、
資源の開放タイミングをスマポに頼るのは負けというC言語スキー氏には概ね同意だが
プログラマーが後始末タイミングをどうしても決められないｼﾁｭは存在するからスマポは要る
GCのように、開放タイミングを決めるのが未来のプログラマーなケースがそれ >>80
ワイはオッサンやで。 C++98 が出来る前から C も C++ も使ってるというか、
マイコンで BASIC とアセンブラが主流だった時代の人だで。
そのときは何にも疑問に思わなかったけど、
今どきのモダンな仕組みを知ってしまったら、
昔の牧歌的なリソース管理なんて本当にしたくねぇという気持ちなんだよ。
(かといって使い慣れたパラダイムから離れるのも面倒くさい。 オッサンなので。)
>>81-82
そこで unique_ptr を使うことに疑問を持つことが意味わからんのだが。
まさにそういう風に使うためのもんだし、
その例で unique_ptr への懐疑を説明されてももう俺には何にも言えねぇ。 >>104
キャッシュは、存在すればアクセスのレイテンシーが短縮されるというラッキーをクライアントに提供するだけのしくみ
よって、キャッシュ上のデータというのは基本いつ消してもシステムにとって致命傷にはならず、
かつ可能な限りキャッシュ上に残存するように普通は設計する
参照カウンタが0より大きいからキャッシュ上のデータを消してはいけないという法は無い
一方、仮に>>104で言いたいのがアクセスしている最中に消したらアカン、という話なのであれば、
それは排他制御の話題であってそれも参照カウントとは関係無く言える話やし… Cより開発効率が高く、Javaよりユーザーにベネフィットを提供できる。
そういった観点から、広く使われるソフトウェアの開発にC++を採用するのは理にかなっている。
JavaにしろC#にしろ、GUIライブラリがころころ変わるのは、エンドユーザーが受け入れないからだろう。
そう、馬鹿なユーザーはJavaやC＃の利点を気にかけないのだ、自分のことしか考えない利己主義め！
なぜ重いソフトウェアを使うべきなのか、ユーザーをキチンと教育する必要がある。
あるいはC++を選ぶ。 >>113
△： 当然インミュータブルでないと話にならないわけだが、
○： 当然インミュータブルなインターフェースでないと話にならないわけだが、
実装は別にミュータブルでもクラスで覆うならやりようはいくらでもあるんじゃ…
画像の書き換えを専用メソッドでやるか、あるいは速度優先でcheckout/checkin式にcheckout中だけ直接アクセスを許すとか、
（もちろんcheckout時にコピーを行う
で、内部ではshared_ptr（的な、「オブジェクト自身に開放タイミングを決めさせる」）ロジックが大活躍！！１１１！！！！１！ 一応簡単に俺の主張を纏めておくと、
・unique_ptrは従来C方式を文法的に強制させるだけで、コードの改善には繋がらない。
・shared_ptrの使いどころはWebサーバーしか思いつかない。
GC言語は基本的にshared_ptrなわけだが、あれって基本的に手抜き専用で、
GCがないと本質的に辛いって構造はあんまりない。
Rustも今更GC無しですかー、とも思うが、実際、無しなら無しでもいいか、程度ではある。 >>146
だから違うっての
>>147
多分俺が欲しいのはそれだ。
https://en.cppreference.com/w/cpp/experimental/observer_ptr
要するに、「ナマポだがdelete出来ない物」が欲しい。
unique_ptrは値渡しすると所有権が移動してしまう。
関数にはポインタの場合値渡しが最速だし、自明だから、グダグダ書いて最適化を待つ、とかやりたくない。
生成は常にunique_ptrからの値コピー（所有権は移動しない）でいい。
寿命管理は他に任せるが、ナマポと完全に同パフォーマンスの物、これが欲しい。
まあ、検討中ならよかった。 なるべく (ポインタでなく) 値でやりとりすること、それを低コストで出来るようにムーブ対応にしておくというのは
上位レイヤを作るときに楽できる良い設計だとは思うけど、
実質的にはスマーポインタの機能をクラスに付け加えてるみたいなもんで、
それがクソ面倒くせえときに標準のスマーポインタを使うみたいな方針でやってた。
総称性を活用するときという観点は無かったけど、確かに必要な考え方だな。 >>147
そらプロってのはタレント商売だからな
おまえ強さ競ってるって勘違いしてない？ 個々のクラスの実装を工夫して値渡しとムーブで解決できないかをまず考えて、
複数の型について類似のコードが出てくるようなら unique_ptr や shared_ptr (や自作ポインターテンプレクラス) の利用を検討する、
というようなことでは。 >>188
禿4はSTLコンテナの類もリソースハンドルと呼んでるけどな。
std::shared_ptrに通知メカニズムをプラスしたようなものが実際に必要になるのではないだろうか。
オジサンはATL風の通知メカニズムを備えたコンテナを作りましたぞ。 >194
> 正しくCを使っている連中は、そのナマポがunique/shared/weak/observerのどれなのかは明確に意識してる。
> ただそれを書いてないだけだ。だから馬鹿には使っていないようにしか見えない。
ああ、馬鹿にはわかんないよ。
だから書いてくれっての。
人間は度し難いほど馬鹿なので、クソみたいな間違いをする。
意識していたとしても間違う。
知っていても何度でも間違う。
そんなの当たり前だろ？ >>195
まあ俺は書くこと自体には反対ではないんだが、
1. 足りないんだから書きようがない(observerが)
2. そもそも書くほどバリエーションがない
Cで使われているのはunique/observerで、shared/weakはほぼあり得ない。
制御が煩雑すぎてバグる。
だからこそsharedが生きる構造があればC++が勝ちきる可能性があったが、
shared撲滅みたいな今の風潮じゃあねぇ。
そして既に書いたが、大概は方式Ａだから、
ローカルのナマポはuniqueで、それ以外は全部observerでしかない。
わざわざ分けて書くほどバリエーションがないんだよ。
Cの連中は書くのが嫌なわけではなく、書く意味を見いださないのだと思うよ。
書いたところでコード構造が改善されるわけでもなく、速度が上がるわけでもない。
書かずともどうせＡ方式だし。 と思って今作ったがあんま使い勝手の良いものにはならんかったorz
使い方としては
class Foo {
sumapo<Foo> m_pCar;
sumapo<Foo> m_pCdr;
/*...*/
};
sumapo<Foo> ptr(new Foo());
と書いた後、ptrが開放されたとき、ptrが指すFooが握っているsumapoが残らず（循環があろうとなかろうと）参照カウントを減じて欲しいわけだが
これにはptrが握っているFooを開放する前に、ptrがFoo::m_pCdrやFoo::m_pCarを辿れる必要があるので
m_pCarやm_pCdrとptrが裏で手を握る必要がある ごめｗｗｗｗｗｗｗまた言い方をちょっとまつがえたorz
誤： Fooが握っているsumapoが残らず（循環があろうとなかろうと）参照カウントを減じて欲しい
正： Fooが握っているsumapoが（循環があろうとなかろうと二重破棄を招かない形で）参照カウントを減じて欲しい
リフレクションがあればsumapoからFoo（やBar）のメンバが丸見えなのでsumapoのリンクを辿って破棄予定オブジェクトを事前にマークすることで2重破棄の防止を自然に実現できる
リフレクションが無い現行のC++なら、sumapoのデストラクタで破棄される予定なFoo（やBar）をマークだけして破棄を遅延する、みたいな細工をするしかないが
デストラクタの中から全てのFoo（やBar）のマークが完了したか知る術が無いから、sweepする呼び出しが別途要る、、
やっぱC++にもリフレクション欲しい… 高額なPython屋募集のAI案件は、99%非現実的。
AIを何も分かってな奴が企画したプロジェクト。散々利用されてきた統計学以上の成果など出やしない。
昨今のAIブームは過去のAIブームと同じく破綻プロジェクトばかりなのは言わずもがな。
なぜPythonか。失敗したときにPythonだからと言い訳するため。
そもそも簡単な言語なのに高額で募集する時点で辻褄が合わない。
嘘ついて投資募ってるのは明らか。読売新聞のAI記事読んでると騙す気満々だと分かる。
openCVスレでもpythonから入る奴は何もできやしない。最初から分かりきったこと。フフフ、笑えますね。 >>227
一番足りないのは謙虚さなんだけどな。
JavaScripterは本当に馬鹿しかいないから、コードがマジでゴミしかない。
だから糞コードしか書けない馬鹿がつけあがる。
そしてそれを諫める年長者もいない。幼稚園で先生がいない状態だ。
C++は30年の歴史があって、仕様も改訂し続けているのだから、
今の仕様はその中で今一番マシな方法ということになっている。
JavaScripterみたいなぽっと出のゴミがぱっと考えて思いつくような手法を、
今まで30年間誰も思いつかなかったと思うこと自体がキチガイでしかない。 プロはタレントで強さを競うところではないってかwww
もうめちゃくちゃやなwww無視しとこ というわけで先に進める。
沸きまくっている馬鹿を振り落とす為に速度を上げるからよろしく。
>>213
> そもそも再帰的なデータ構造じゃないものなら
> 循環参照のしようがないので普通に shared_ptr で良いし
> そういう処理もごく普通によくある
「再帰的なデータ構造ではないとき、循環参照は発生しない」については同意だが、
「循環参照がない場合は、shared_ptrでいい」には反対だ。
これだとC++の速度優位性が無くなるので、俺ならGC言語を検討する。
ただしこれは宗教だからもういい。
本題は、
・shared_ptr（静的共有)必須な構造が、果たしてあるか
だ。木構造で一番身近なファイルシステムを例に取ると、
静的共有(ハードリンク/shared_ptr)と動的共有(シンボリックリンク/getter)のうち、
前者はほぼ使われてないだろ。
これは、ユーザーによる手動管理の場合、シンボリックリンクの方が明示的で使いやすいからだ。
シンボリックリンクは常に最新版を、ハードリンクは常に生成時の対象を参照するところが異なる。
速度的には静的共有の方が優位だとして、動的共有では無理な事例ってあるか？
俺が知っているハードリンクの活用事例は、WindowsUpdateくらいだ。
「動けばいい」なら動的共有の方が適切に思える。
(C++で動的共有はなかなかにきついが、動的言語なら自然に実現出来る） class FILE_Ptr : public ns_shared_ptr::shared_ptr<FILE> {
struct FILEDeleter {
void operator() (FILE* fp) const {
if (fp != NULL) {
fclose(fp);
}
}
};
public:
FILE_Ptr(FILE* fp = NULL) : ns_shared_ptr::shared_ptr<FILE>(fp, FILEDeleter()) {}
operator FILE* () { return get(); }
template<typename T> bool operator == (const T& obj) const { return get() == reinterpret_cast<FILE*>((void*)((intptr_t)obj)); }
template<typename T> bool operator != (const T& obj) const { return get() != reinterpret_cast<FILE*>((void*)((intptr_t)obj)); }
};
void fclose(ns_shared_ptr::shared_ptr<FILE>)
{ なんだこりゃw
なんjにいた長文荒らしか？
また面倒な奴がきたなあw C++でよく使われる各オブジェクトのスタックサイズは以下の通り。
stringstreamとfstreamのサイズは無視できない大きさであることがわかるだろう。
・GCC - ubuntu Linux x64
(sizeof(std::stringstream), sizeof(std::fstream), sizeof(std::ostream), sizeof(std::string), sizeof(std::vector<std::string>), sizeof(FILE))=(392, 528, 272, 32, 24, 216)
・Visual Studio 2017 - Windows10 x64
(sizeof(std::stringstream), sizeof(std::fstream), sizeof(std::ostream), sizeof(std::string), sizeof(std::vector<std::string>), sizeof(FILE))=(248, 280, 112, 32, 24, 8) iostream の替わりになるようなデファクトスタンダードが登場していない以上、
ほどほどに付き合っていくしか仕方がないよ。
C スタイルは普段から使うには抽象度が低くて面倒くさい。
printf は std::string を表示するのにさえいちいち c_str を通さなきゃならんのだからな。
書式指定との整合が型システムで保証されないのも古い設計だし。
処理系の方である程度は特別扱いすることで折り合いがついてるけど、
あらためて考えるとだいぶん不格好だと思う。
コンセプトやら何やらが導入されたらもうちょっとマシな入出力ライブラリが出来たりしないもんかね？
提案くらいは出てたりしない？ って思ったけど、こないだ江添っちがTwitterで「無い」って言ってた気がする。 >>274
iostreamは肝心な時に使えない橙武者です。
ログ出力するクラスは歌舞伎の黒衣のような慎ましい存在でなければならないのですが、
iostreamはあたかも歌舞伎の花形役者のようなオレ様的存在感を出すので好ましくありません。
実例をあげるならば障害発生した時に、ログ用途でiostream系を使うことがあり得えます。
cout やその他インスタンスが生成されてスタックを多く使うことになります。
つまり、実運用環境とログ埋込環境でメモリ構成が大きく異なる環境になってしまうことが避けられません。
iostreamはマルチスレッド環境など対話デバッグでは追跡しにくい現象をログ出力するのに適さない、と断言できます。
橙武者、黒衣など語の意味が分からない方は、ご自身でおググり下さい。 そういえばこないだ相模大野の焼肉屋で見掛けたけど
もう一人兄ちゃんは武尊だったのか(気付かんかった) ペイ・パー・ビュー売り上げ：ボクシング2006年から12年連続で総合格闘技に連敗中
・総合格闘技UFC PPV
2006年 535万件
2007年 498万件
2008年 631万件
2009年 775万件
2010年 915万件
2011年 679万件
2012年 590万件
2013年 610万件
2014年 358万件
2015年 756万件
2016年 853万件
2017年 388万件
・ボクシング PPV (*2007年までの最高記録、1999年400万件)
2006年 370万件
2007年 480万件
2008年 375万件
2009年 360万件
2010年 400万件
2011年 460万件
2012年 400万件
2013年 392万件
2014年 340万件
2015年 585万件
2016年 173万件 ←大爆笑
2017年 260万件
＊なおボクシングはメイウェザーが引退、パッキャオの人気が落ちて2016年からペイ・パー・ビューが売れなくなっている アメリカボクシン視聴者数の凋落ぶり
・2003年HBO視聴者数
2003年06月21日 703万人 レノックス・ルイスvsビタリ・クリチコ
2003年11月15日 316万人 マニー・パッキャオvsマルコ・アントニオ・バレラ
↓↓↓
・2006年HBO視聴者数
2006年06月17日 350万人 ウィンキー・ライトvsジャーメイン・テイラー
↓↓↓
・2007年HBO視聴者数
2007年01月20日 150万人 リッキー・ハットンvsファン・ウランゴ
2007年09月29日 210万人 ケリー・パブリクvsジャーメイン・テイラー
2007年11月17日 140万人 ホアン・グスマンvsウンベルト・ソト
↓↓↓
・2008年HBO視聴者数
2008年03月08日 124万人 オレグ・マスカエフvsサミュエル・ピーター
2008年04月19日 180万人 バナード・ホプキンスvsジョー・カルザギ
2008年05月03日 210万人 オスカー・デラホーヤvsスティーブ・フォーブス
↓↓↓
・2010年HBO『最高』視聴者数
2010年06月05日 160万人 ミゲール・コットvsユーリ・フォアマン
↓↓↓
・2014年HBO『最高』視聴者数
2014年03月01日 139万人 フリオ・セサール・チャベス・ジュニアvsブライアン・ベラ
↓↓↓
・2017年HBO『最高』視聴者数
2017年5月20日 96万人 テレンス・クロフォードvsフェリックス・ディアス
＊14年あまりで視聴者数が7分の1に激減 総合格闘技・ボクシング視聴率比較
・総合格闘技UFC（地上波FOX）
2015年1月24日 305万人（メインイベント：グスタフソンｘジョンソン）
2015年7月25日 275万人（メインイベント：ディラショーｘバラオン）
2015年12月19日 278万人（メインイベント：ドスアンジョスｘセラーニ）
・ボクシング（地上波NBC）
2015年3月7日 337万人（メインイベント：サーマンｘゲレロ）
2015年4月11日 282万人（メインイベント：ガルシアｘピーターソン）
2015年6月20日 232万人（メインイベント：ポーターｘブローナー）
2015年9月26日 217万人（メインイベント：ワイルダーｘデュナパス）
2016年4月16日 124万人 （メインイベント：スペンスｘアルギエリ）←爆笑
2016年6月18日 120万人 （メインイベント：フォンファラｘスミス）←爆笑
・ボクシング（地上波FOX）
2017年7月15日 88万人（メインイベント：フィゲロアｘゲレーロ）←大爆笑
＊ボクシングは低視聴率で打ち切られてから20年ぶりの地上波復活を果たすが放送開始1年で視聴率が半減以下の大惨事
ボクシングは総合格闘技より低視聴率のためテレビ局から支払われる放映権料もだいぶ安い
・テレビ局放映権料比較
UFCのテレビ放映権料は年間1億ドルでFOXと契約
(2019年からは現契約の約3倍増となる年間3億ドルでESPNと契約)
一方、ボクシングは、HBO+SHOWTIMEの予算(放映権料＋制作費や宣伝費等)が3500万ドル＋2800万ドルの合計年間6300万ドル(放映権料のみだとこれよりだいぶ下がる)とUFCの半額ほど
しかもボクシングは視聴率が低下し続けているため毎年のようにテレビ局がボクシングの予算削減中
付け加えると
2017年のUFCの利益（EBITDA）は3億2千万ドル（360億円）の黒字で2019年からはさらなる利益増が予想される ツイッターフォロワー数比較
UFC 672万人
ゴールデンボーイプロモーション 42万人
トップランク社 35万人
デイナ・ホワイト 510万人
オスカー・デラホーヤ 180万人
ボブ・アラム 4万人
・総合格闘技サイト
MMA Junkie 31万9千人
MMA Fighting 31万4千人
・ボクシングサイト
BoxingScene（世界最大のボクシングサイト） 12万3千人
・総合格闘技名物記者
アリエル・ヘルワニ 65万3千人
・ボクシング名物記者
ダン・ラフィール 22万6千人
総合格闘技の圧勝 おそらくこれで決まりだろう。
まあ井上がまだ何のアクションもおこしてないのが微妙なところだが。
Zolani Tete (WBO World)
Ryan Burnett (WBA Super)
Emmanuel Rodriguez (IBF World)
Naoya Inoue (WBA Regular)
Jason Moloney (WBA Oceania)
Juan Carlos Payano (WBO Intecontinental)
Mikhail Aloyan (WBA International)
Nonito Donaire (former WBC/WBO Super BW) >>194
これで決まった場合、井上の言ってた残念な情報って何だったのかｗ
WBC勢が不参加という程度の話だったのか？
ただの中間情報で、最終的に変わったって可能性もあるか >>195
バーネット辞退の誤報じゃね？
結果的には杞憂だったと。 >>197
少なくとも、ここまでこぎつけるのに紆余曲折はあったんだろうな
とはいえ、最終的にこれだけのメンバー集めたなら素晴らしい
リゴンドーに声かけた一点見ても、主催者はファンの見たいトーナメントってものを分かってる
逆に言うと、そういう主催者だから、政治的配慮とかで井上を外すってこともないな 多賀井の崇拝する教祖が死刑に…
これはもうケンさんがヨギとして皆を導くしかありませんな。
あとは宜しくお願いします。 >>194
ありえん話だけど
ここまでそろうと総当たりでガチで一番強い奴を決めてもらいたいくらいだな 「標準出力への書き込みは遅いから」との理由で、メモリ上にログをため込むことは多いかと思います。
iostream系だと stringstreamを使うことになりますがスタックサイズが割と大きくインスタンス生成のたびに時間もかかります。
さらにいえば、MSVCの場合、snprintf()に比べてstringstreamは書き込みに3倍弱時間がかかります。
本来ならば << 演算子はコンパイル時に型が決まるので書き込みが高速なはずなのですが、
MSVCだとstringstreamがsnprintf()に負ける有様ということです。
なお、Linux GCCの場合、snprintf()とstringstreamは書き込み速度の差は少ないようです。 ■ このスレッドは過去ログ倉庫に格納されています
