2025年には21年以上稼働する基幹系システムが6割に達し、多くの企業でシステムの維持管理費がIT予算の9割以上を占めるようになる。長寿の基幹系システムは内部がブラックボックス化してデータ活用が進まず、企業がデジタルトランスフォーメーション(DX)できない結果、最大で年12兆円の損失が生じる――。 この「2025年の崖」を経済産業省が2018年9月に「DXレポート」で指摘してから2年以上がたった。だが経産省によれば2020年10月時点で日本企業の9割以上でDXが未着手だったり⼀部実施にとどまっていたりするという。 2025年の崖が迫るなか、企業は基幹系システムなどで使うCOBOL資産を維持すべきか、Javaなどの他の言語やオープン系COBOLで書き換える(マイグレーションする)べきかの岐路に立たされている。COBOL資産を維持する場合、運用コストの削減やDX向け新システムとの連携を模索しな
Matt (whose web site does not mention his last name as far as I can tell) has written an article "How to C in 2016". It's been linked to from Reddit and from Hacker News; the latter is where I saw it. Update: Matt has been kind enough to add a link to this critique to his article. Update: A couple of people have found Matt's last name from other sites, but since he didn't choose to include it in h
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? まず、何も言わずに下記の記事をお読んでください。 How to C (as of 2016) 英語は・・・という方は、下の翻訳をお読みください。 2016年、C言語はどう書くべきか (前編) 2016年、C言語はどう書くべきか (後編) これからのC言語を考える。 さて、上の記事を読みましたか?まだ読んでない?いや、読みましょうよ、ということで読んだことを前提でお話しします。 C言語知っているぜ!と言っている諸兄の方々の中には、何これ?と思ったのもあったかと思います。聖典 K&R は仕方が無いとしても、C言語入門を謳う書籍やサイトの中で
Getting Started Introduction A simple tutorial Language Reference Basic syntax Types Variables Constants Expressions Operators Control Structures Functions Classes and Objects Namespaces Enumerations Errors Exceptions Fibers Generators Attributes References Explained Predefined Variables Predefined Exceptions Predefined Interfaces and Classes Predefined Attributes Context options and parameters Su
Getting Started Introduction A simple tutorial Language Reference Basic syntax Types Variables Constants Expressions Operators Control Structures Functions Classes and Objects Namespaces Enumerations Errors Exceptions Fibers Generators Attributes References Explained Predefined Variables Predefined Exceptions Predefined Interfaces and Classes Predefined Attributes Context options and parameters Su
ここ1年で最短日記録を28回更新!原子時計を用いた地球の自転速度(1日の長さ)の記録は、1960年代から続けられています。 過去50年間の記録では、地球が自転1周を完了するのに、24時間よりわずかに長い時間を要することが度々ありました。 その都度、タイムキーパーたちは、原子時と太陽時の帳尻を合わせるために時間を足す作業をしています。 これが、1972年に導入された「うるう秒」です。 うるう秒の調整では、地球の自転速度が変化して、原子時と天文時に0.9秒をこえる誤差が生じた際に1秒単位で足し引きされます。 しかし、これまでの調整(計27回)では、1秒を足すことはあっても、引くことはありませんでした。 Credit: jp.depositphotos ところが、2020年に突如として長年の傾向が逆転し、地球の自転が24時間より短くなり始めたのです。 実際、2020年7月19日は原子時の24時間
Introduction to libiconv International text is mostly encoded in Unicode. For historical reasons, however, it is sometimes still encoded using a language or country dependent character encoding. With the advent of the internet and the frequent exchange of text across countries - even the viewing of a web page from a foreign country is a "text exchange" in this context -, conversions between these
この記事はan intro to Java source-level annotation processingであり、コンパイル中に追加のソースファイルを生成するためにこの手法を使用する例を提供します。
C+11では正規表現をサポートしているがそれ以前のバージョンだとサポートしていないようなのでC言語の正規表現を利用する C言語で正規表現を利用する場合regex.hをincludeして、regcomp``regexec``regfreeこの3つの関数を利用する。 # include <iostream> # include <regex.h> int main( int argv, char* args[] ) { char checkString[] = "abc, def, ghi"; // チェックをする文字列 const char regex[] = "([a-z]+), ([a-z]+), ([a-z]+)"; // マッチングをする文字列 regex_t regexBuffer; // 正規表現オブジェクト // 正規表現オブジェクトのコンパイル if( regcomp( &r
プリコンパイル ヘッダーを検索中に不明な EOF が見つかりました。 '#include name' をソースに追加するのを忘れていませんか。 解説 /Yu によって指定されたインクルード ファイルがソース ファイルに一覧表示されません。 このオプションは、多くの Visual Studio C++ プロジェクト タイプで既定で有効になっています。 このオプションによって指定された既定のインクルード ファイルは、Visual Studio 2017 以前の pch.h または stdafx.h です。 Visual Studio 環境で、次のいずれかの方法を使用して、このエラーを解決します。 現在のプロジェクトから、pch.h ヘッダー ファイルまたは pch.cpp ソース ファイルを誤って削除、名前変更、または削除していないことを確認します。 (以前のプロジェクトでは、これらのファイル
# include <stdio.h> int main() { printf("%*s\n", 5, "aa"); // ' aa' が出力される(左3文字空白) printf("%*s\n", 5, "aaaabbbb"); // 'aaaabbbb' が出力される printf("%.*s\n", 5, "aaaabbbb"); // 'aaaab' が出力される return 0; } つまり、* は引数で表示する文字数を定義できるということですね。* だけだと、定義文字長を超えた文字列が与えられると全部表示されますが、.と組み合わせることで、定義文字長で切って表示することが可能です。 この書式を使う場面としては、整形もそうですが、どんな長さの文字列が来るかわからない場合にとりあえずバッファのMAXサイズでぶった切る。ってのにも使えそうですね。まぁ、そういう場合はちゃんと長さチェッ
random_r 関数は glibc が提供しているリエントラントな擬似乱数生成APIです。 複数のスレッドで乱数を使いたい場合はこれを使うべきらしい。*1 複数のスレッドが random() を使うような状況では、この関数を使用すべきではない。 その場合には random_r(3) を使うこと。 http://linuxjm.sourceforge.jp/html/LDP_man-pages/man3/random.3.html ただ少なくともこのマニュアルが不十分で、man を読んだだけだと正しく使うことは出来ません。 以下に私の手元で 動いたように見える コードを示します。 /* * $ gcc -o test test.c && ./test */ #include <stdio.h> #include <stdlib.h> int main (int argc, char * a
Section: Linux Programmer's Manual (7) Updated: 2020-11-01 Index JM Home Page roff page 名前 ip - Linux IPv4 プロトコルの実装 書式 #include <sys/socket.h> #include <netinet/in.h> #include <netinet/ip.h> /* 上記のスーパーセット */ tcp_socket = socket(AF_INET, SOCK_STREAM, 0); udp_socket = socket(AF_INET, SOCK_DGRAM, 0); raw_socket = socket(AF_INET, SOCK_RAW, protocol); 説明 Linux は RFC 791 と RFC 1122 で記述されている Internet Pro
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く