şöyle bir projeye rastladım.
http://www.flipcode.com/archives/CC_Console.shtml
Bence güzel bir fikir üretmiş projenin sahibi. Böylece program release modda çalışırken bile debug outputlarını alabiliyoruz. Tabii ki "ne gerek var?", "performans?" gibi konulara katılıyorum. Ama yine de hoşuma gitti. Özellikle birden fazla monitörle çalışırken bu uygulama çok faydalı olabilir.

Evet, vindovz altinda inceleme ve takip icin guzel olmus. "performans?" demeye gerek yok cunku her zaman #ifdef parantezien alip son surumde atabilirsin mesaj gonderim satirlarini.

elemanın yapmaya çalıştığı bu değil gibi geldi bana. sanki console.exe çalışmıyorsa FindWindow APIsi sonuç vermeyecek ve release versiyon yine düzgün çalışacak. eğer console.exe'yi çalıştırırsan console outputlarını bu exe'ye gönderecek gibi bir yapı kurmuş. yani #ifdef kullanılmasına gerek kalmadan kendisinin bunu çözdüğünü düşünüyor bence. ama bu performans kaybına yol açacaktır.

Orijinal bir fikir gibi geldi bana. En azından benim aklıma gelmezdi 🙂

Belli bir ebadin ustundeki her program bir yerlere bir dosyaya log output alir zaten. Cok orjinal gelmedi bana. bir adet
std :: ofstream gConsole("log.txt"😉;
sonra heryerde:
gConsole<<"her sey yolunda"<< mySuperString << myClassObjectWithOverloadedOperator<<std::endl;
seklinde yapmayi tercih ederim. hem bilimum STL tipleri ile calisacak hem daha kisa.

bu programın tavsiye edildiği forum birden fazla monitörle çalışma konusunda bir tartışmanın döndüğü bir forumdu. forumdaki elemanlardan biri "ikinci monitörde rahatça debug outputlarını görmek istiyorsanız bu proje ilginizi çekebilir" diye göndermişti linki. log.txt'yi ikinci monitörde sürekli refresh etmek yerine realtime monitoring için bu system tray uygulaması daha pratik olabilir diye düşünüyorum. program crash etsin, sonra txt'i açıp nerde crash ettiğini görelim diyorsanız ok ancak program crash etmiyor ve çalışmaya devam ediyorsa tam olarak ne yaptığınızda hata aldığınızı anında yakalamak için güzel bir alternatif.

Ben sahsen mesajlarimi dogrudan stdout veya stderr'e yazarak bakiyorum ciktiya. Eger programi bir komut satirindan baslatirsaniz ciktiyi guzel guzel okursunuz. Windows ile bu is cok rahat degil sanirim. O acidan ben gayet begendim bu c++ konsolu.

(Win32'den bahsediyorum) Konsola sahip bir program yazıyorsanız zaten böyle bir şeye ihtiyacınız kalmıyor, fakat her zaman da konsola sahip bir program yazmıyorsunuz veya komut satırından başlatmıyorsunuz. Dosyaya log eylemek de skate'in anlattığı sebeplerden bu elemanın yazdığı şeyle kıyaslanmamalı. Bu sebeplerden kullanışlı geldi bana.

Fakat benim dikkat cekmek istedigim nokta logun dosyaya gitmesi veya live incelenmesi degil.
Bir gelistiricinin "dur ben bi debug datayi live incelemek uzere consoledan calistirayim " demesi ile "dur ben bi debug datayi live incelemek uzere trayde filanca programi acayim" demesi arasinda pratiklik acisindan fark gormuyorum. Consolun ikinci monitore tasinmasi acisindan da pratiklik farki yok. Ustelik std:: ostream cok daha guclu bir interface. Butun bu sebeplerden oturu benim tercihim boyle standart olmayan bir tool kullanmaktansa STL kullanmak olur.
Eger eleman adam gibi std:: ostream interface'ini implement eden birsey yaparsa o zaman bu elestirimi geri alabilirim. STL / boost evangelisti oldugum biraz fazla belli oldu herhalde 🙂

@Nightlord: boost'u bana ilk tanıtan adam olarak evet senin bu konudaki aşkını biliyor ve hak veriyorum da. ben bu console'un avantajını yanlış anlamış olabilirim. benim anladığım şey şu idi.
örnek senaryo: programı tüm console çıktılarıyla herhangi bir conditional compiler komutu olmadan yazıyorsun ve final exeyi elde ediyorsun. sonra icabında dağıtıyorsun bu exeyi alfa/beta olarak. birileri sana bug report yapıyor. sen bu bugı kendi test ortamında yaşamıyorsun. bu durumda c/c++ console'u kurup o makine üzerinde release edilmiş olan exe ile problemi yakalayabiliyorsun o bilgisayar üzerinde hiçbir compiler kurulu olmasa bile.
aslında benim aklımdaki senaryo bu değildi ancak standart debugging yöntemlerinin bir çoğu ya derleyici gerektirir ya da text outputlar üzerinden değerlendirme yapmak gerekir. burada benim "hmm, iyi fikirmiş" deme sebebim özellikle yukardaki gibi senaryoları da kapsamasıydı.