Oracle APEX makes it easy to build beautiful apps that are responsive, accessible, and can be effortlessly customized to fit your company's brand and personality. The apps you build are responsive out-of-the-box and are designed to work well regardless of screen size or form factor. Our comprehensive set of modern UI components are all built to...
エンジンとアドバイザーは、コミュニケーションの流れで動いています。表中の各セルはシモバル数です。その上、その値や状態などを渡す他の要素もたくさんあります。行をすばやく交換し、OnChartEvent()イベントキューをオーバーロードしないようにする必要があります。
SQLを使い、頭を使わないでください :-)
リソースと組合でどうするか、全く考えていないってこと？
お先にどうぞ、ニコライさん。
ユニオンとの選択肢を提示したが、例を示していない。その後、CharArrayToStringとStringToCharArrayに 切り替わったんですね。今、あなたは再び組合について話しています。
では、StringからCharに戻り、その後Stringを分割するのが最適解なのでしょうか（Stringにはパラメータ番号とその値の集合が含まれています）。
お先にどうぞ、ニコライさん。
Peterさん、doubleやlong、intを渡すのにも文字列を使うのですか？
パラメータの核となるのは1つの配列である。そして、それは文字列型 である。理由はひとつ、ユニバーサルタイプであること。とても便利です。任意の値を書き込んで、必要な型に変換することができます。
そうでなければ、パラメーターのコアをたくさん作る必要があります。それぞれの価値観に合ったものを。その結果、パラメータの属性、そのインデックス、書き込み位置など、いろいろなことがごちゃごちゃになってしまうのです。
荒らすのはやめましょう。メンターが適切でない。この仕事について、より深く理解することができました。
ニコライ、君のバージョンを試してみるって言っただろ)だから、そうします。
SQLを使用し、心配することはありません :-)
頭でっかちになるな」ということをフォローするかのように :-)
今日は優しいし、全然邪険にしないし...。
ピーターさん、開発用の「ビジュアルプログラミング」（GUIだけでなく）についてですが、アレイオンアレイを作らなくていいんですね。
は、例えばオラクルを見てみましょう。明確なリーダーの一人
ビジュアルエディタの無料配布（バーチャルマシンと セットで）こちら ;https://apex.oracle.com/en/
必要なのは、『ダミーのためのSQLの始まり』の本と、2、3日の空き時間だけです。
荒らすのはやめましょう。指導口調が不適切である。この仕事について、より深く理解することができました。
それを否定するつもりはないんです。
なぜ、ありがた迷惑な仕事をしなければならないのか。そんな口調ではありませんでした。ただ、今まで何度か、あなたよりずっと速いコードを投稿して、あなたがそれを学んで、より速い方法を適用することを期待したのですが、あなたはそれを利用したことがないのです。
パラメータの核となるのは1つの配列である。そして、それは文字列型 である。理由はひとつ、ユニバーサルタイプであること。とても便利です。任意の値を書き込んで、必要な型に変換することができます。
そうでなければ、パラメーターのコアをたくさん作る必要があります。それぞれの価値観に合ったものを。その結果、パラメータの所有権やインデックス、書き込み位置など、いろいろと混乱が生じることになる。
汎用性は遅さと同義語になりがちですが、弦楽器ではなおさらです。
その一例をご紹介します。
以前、WebRequestを使って暗号化取引所から取得した文字列を解析したことがあります。そして、Sergeyev 氏が「高速C++ライブラリ」から移植したJSONライブラリを使って パースしています。そして、速度が非常に不満足であることに気づかされました。そこでは、すべてが「ユニバーサル」な文字列で行われていたのです。
低速の原因は文字列だと理解し、文字列関数の使用を避けたいと思い、uchar配列から直接パースする関数を書きました。その結果、かなり驚きました。私の解析速度は...。(ドラムロール）800倍の速さです。JSONで文字列全体をパースするのに0.3秒かかるとしたら、私の関数は半分の1ミリ秒以下でパースしています。
以下は、uchar配列でパースした例です。
汎用性は遅さと同義語になりがちですが、弦楽器ではなおさらです。
その一例をご紹介します。
以前、暗号取引所から受け取った文字列をWebRequestでパースしたことがあります。そして、「高速C++ライブラリ」から移植したSergeev氏のJSONライブラリを使って パースしています。そして、速度が非常に不満足であることに気づかされました。そこでは、すべてが「ユニバーサル」な文字列で実装されていたのです。
文字列から離れたいと思い、uchar配列から直接パースする関数を書きました。その結果は意外なものでした。私の解析速度は...。(ドラムロール）800倍の速さです。
以下は、私がuchar配列をパースする例です。
jsonのパース（とパース全般）はまた別の話です ;-)
暗号を扱う非常に大規模なシングルスレッド・スクリプト・アプリケーションでトラブルが発生しました。
どこで、どのように最適化されているのか、疑心暗鬼に陥ってしまうのです。サードパーティーのjsonパーサーに問題があるようでした :-)
なぜなら、"ユニバーサル "ライブラリは、汎用性があり、最もトリッキーなjsonを扱うために設計されていますが、私たちの分野では、単にそれがないのです。
と、どの区画も非常に短いです。
そうそう、MQLでのテキスト解析は本当に楽しいですよ :-)。まあ、テキストパース用に設計されたものではありませんからね。できるけど、めんどくさいから
配列、命令、それはMQLの領域です。