A hand-written recursive-descent C++ parser has replaced the YACC-derived C++ parser from previous GCC releases. The new parser contains much improved infrastructure needed for better parsing of C++ source codes, handling of extensions, and clean separation (where possible) between proper semantics analysis and parsing. The new parser fixes many bugs that were found in the old parser.
Eclipse2.xが動く？ (スコア:2, 興味深い)
というのがとても気になります。
Re:Eclipse2.xが動く？ (スコア:0)
Re:Eclipse2.xが動く？ (スコア:1, 興味深い)
Re:Eclipse2.xが動く？ (スコア:1)
おろろ、このTOMCATって性能どのくらい違うのでしょう？
ちょっと今TOMCATの性能で問題有りのプロジェクトにいるので
かなーり気になりますなぁ
OSがRedHat9なんですがその上でもコンパイルして動かしたり
できるのかなぁ・・・出来て性能良ければ使ってみたいなぁ
重蔵
Re:Eclipse2.xが動く？ (スコア:1, 参考になる)
Re:Eclipse2.xが動く？ (スコア:0)
http://people.redhat.com/gbenson/naoko/
ここでのパッケージはgcc3.5ssaでコンパイルされていてgcc3.4.0な環境では動きませんけど。
Re:Eclipse2.xが動く？ (スコア:0)
確か雑誌では開発者用のサイトにもバイナリがないとか言ってたような…。
# 個人的には非常にネイティブEclipse欲しいです
# FedoraCoreはUTFだし今後Javaと相性が良くなる？
GCC or gcc (スコア:1)
しかし、意外に反応ないねぇ... 今時コンパイラを使う人は少ないんでしょうか？ま、私自身、Cのソースを書かなくなって久しいですが。最近はすっかりRuby三昧です。
Re:GCC or gcc (スコア:1)
書くとすると自分もRubyですね。
# あとはPHPをちょっぴり
評価したいんだけど… (スコア:1)
本業が忙しくてのう。週末に現実逃避をかねて引っ張ってくるかー。
評価予定の言語はC, C++, Java.
興味のある部分は、SSE2対応度・MMX対応度・AMD64コードの質・プリコンパイルの使い勝手・(gcjの)Sun javacとの生成コード比較。
# 2年前にC++でスタンドアロンでmakeすると30分、分散コンパイル作って投入したら5分に縮まったがプリコンパイルやっぱり欲しかったという現場にいたのでID
Re:評価したいんだけど… (スコア:0, 余計なもの)
あのときはありがとー
という私信レス。
まいなすもで覚悟のID
-- JuNya
Re:GCC or gcc (スコア:1, 参考になる)
日常的にgcc使ってますが、最近は「cygwinのアップデートで入れる」「FreeBSDのアップグレードでデフォルトのgccのバージョンが上がる」って感じの使い方なので、「gccがリリース」って言われても「ふーん」っていう反応しかできないんですよね。
ま、Javaな人とか(もしかするとC++な人とかも？)バージョン上げると良いことあるのかもしれないけど、gcc上でベタなCだけで生きてる人間からすると、現時点で何も困ってないので、わざわざ試す気にならないっつーのが本音ですね。
Re:GCC or gcc (スコア:1)
他にもレス付いてますが、新しいバージョンのGCCをすぐ使ってみるということは、ほとんどないですねぇ。
普段使っているディストリでは2.96だし、仕事で使っているクロスコンパイラは2.95だし。
テンプレートの扱いがバグバグだから、早く3.3以降にしたいのだけど、なかなか周りと合わせて移行するとなると難しいです。
↑今だに2.x (スコア:1)
日記なら日記に書け。
Re:GCC or gcc (スコア:1)
AMDとかMSとかSCOとか。
#他にはタバk(ｻｸｯ
Re:GCC or gcc (スコア:1, 興味深い)
C99,libg,pthread,gcなどは使えない。よって彼らと一緒にやるプロジェクトでは使わせてもらえない。
20世紀でプログラミング学習を止めた世代はそろそろ現場に口出すのやめてほしいです。
自分は今でも一線のつもりだろうけれど、かつてのCOBOL,Fortran使いと同じ立場になっちゃってますよ。
Re:GCC or gcc (スコア:0)
Re:GCC or gcc (スコア:0)
gcc の大盛りパッケージには UNIX でメジャーな GC ライブラリが同梱されてるんですが。
Re:GCC or gcc (スコア:0)
無いからソフトのする仕事の名前を書いたわけで。
gc = garbage collection は知られてる略だし。
Re:GCC or gcc (スコア:1)
GCC3とかw3mが使ってます。
Re:GCC or gcc (スコア:1)
正確に言えばgcjのlibjavaが
Re:GCC or gcc (スコア:0)
gc は一般概念だから「自分で実装する」という選択肢もありますし。
今どき素の C で書くということは、どうしても高い実行性能が
欲しい (とくに、最悪の場合の処理速度を保証し
Re:GCC or gcc (スコア:0)
その手間がかかるから、流通してるの利用したいんだってば。
まさに「libcだけ」の発想ですね。
>GC を使って開発効率が上がるなら、
>最初から GC ありの言語で書いたほう
Re:GCC or gcc (スコア:1)
いまどきK&Rだけ、ってのもすごいつーか、つらい、つーか。
でも、C99もどうかと言う気もしますね。GCC3.3でも完全にはサポートされてません [gnu.org]からねぇ... C++との互換性も問題になりそうですし。
でもまぁ、機会があったらC99も勉強して使ってみたいと思います。が、その機会が来るかどうか...
Re:GCC or gcc (スコア:0)
だとしたら強烈にobsoteteな罠。
Re:GCC or gcc (スコア:0)
ちなみにC99ってどのコンパイラ使うつもりなの？
どの程度の規模のプロジェクトを想定してるか解からないけど、趣味のプログラミングじゃないんだから枯れた技術を選択するのは悪くないと思うけど。
確かにSTLとか使うと便利すぎて、自分で同じようなクラスや関数用意するのバカらしくなるけどね。
Re:GCC or gcc (スコア:1)
標準ライブラリのが有難いと思うんですが。
# stdint.h の uint32_t 等。
uxi
Re:GCC or gcc (スコア:1)
みんな使っているようでいて、
GCC、というかコンパイラって実は意外とバージョンアップがピンとこないもの、なのかもしれません。
まぁ、私の場合は、違いがわかるぐらいまで熟達しているわけではないというのもあるのですが(^^;;;
業務ではバージョン指定されているので変更出来ませんし、
そもそもメイン言語が ANSI C なので、あまり変更に対してのメリット／デメリットが無いという……。
自宅で少し試してみたいと思います。
個人的にはC99にどのくらい対応できたかが気になるところ。
# まだ正式には対応出来ていないようですが……
C++のparserが (スコア:3, 興味深い)
Re:C++のparserが (スコア:1, 参考になる)
Re:C++のparserが (スコア:1, 参考になる)
int (x);
ある意味で、言語設計のミスです。
Cのキャスト廻りの文法が厳格になったらしい (スコア:1)
過去のコードの継承性がライブラリレベルで失われる(例えばxmultiとか)だけでも面倒臭いどころかプロジェクト次第では致命傷になるのに、コンパイラレベルで継承性を失うと滅茶苦茶な事になるので不安があるのでおしえてえらいひと。って事です。
# そりゃ、基本に忠実でない事をやるのはいけないのでしょうけど、
# 組込み系でアセンブラで書くと移植性がどーこーって場合なんかは
# キャスト廻りでトリッキーな事をするのが解になることも往々にして
# あるので…
--暮らしの中に修行あり。
blogはじめました。 [hatena.ne.jp]
type-punning (スコア:2, 参考になる)
有効になるため、かなり多くのプログラムで思わぬ結果をもたらします。
例えば、
long *v = malloc(sizeof(long));
*v = 0;
*(short *)v = -1;
printf("%ld\n", *v);
printf("%ld\n", *v);
を -O2 を付けてコンパイルすると、最初の出力は 0、次のは
65535 になります。
gcc の info にあるように、union を使って避けることも
できますが、大抵は面倒なので -fno-strict-aliasing を
おまじないのように付ける事が多いですね。
Re:Cのキャスト廻りの文法が厳格になったらしい (スコア:0)
そもそも規格外なので、正しい記述に修正するべきだと思いますが。
Re:Cのキャスト廻りの文法が厳格になったらしい (スコア:0)
gcc言語のコンパイラだと思ってたのですが、
なにか方針の変化があったんでしょうか？
Re:Cのキャスト廻りの文法が厳格になったらしい (スコア:0)
Re:Cのキャスト廻りの文法が厳格になったらしい (スコア:0)
Re:Cのキャスト廻りの文法が厳格になったらしい (スコア:0)
># キャスト廻りでトリッキーな事をするのが解になることも往々にして
># あるので…
単純に好奇心ですが、具体的にどんな問題と解決方法があるんでしょ？
arm/xscaleサポート (スコア:2, 参考になる)
-浮動小数点サポートの変更
-Wireless MMX(PXA270)をサポート
なんていうのがあるみたいですね。
実際にテストした結果 [xrea.com]でも、結構なパフォーマンスの改善が見受けられるようです。
#WirelessMMXは、普通にコード書けば勝手に適用してくれるんでしょうか。
#だとしたらすごいなあと思いますが。
Tuning for K8 (スコア:1, 興味深い)
Tuning for K8 (AMD Opteron/Athlon64) core is available via -march=k8 and -mcpu=k8.
が気になってます。いままでなかったので。さぁemerge -e world(gentoo)だ。
superblock scheduling (スコア:0)
profile といっしょに使っても全然速くならん……。