Keske machine code yazabiliyor olsaydik kolayca, en hizli oyle
calisirdi. :)))
C gucunden suphem yok, kimsenin de yoktur. Gelistirme icin ideal mi
yanitinin pesindeyim. Bazen ideal, bazen de degil diyorum. Yani ihtiyac
ve uygulamaya bagli aslinda.
Simdi gercek ornekle olayi gelistirelim. C ile C turevli
xHarbour(Clipper) % 100 ayni kutuphaneleri kullanirsa, kodlar nasil
gorunuyor bir bakalim. C kodunu derleyici uretti !
Bu iki kod da ayni kutuphaneleri kullanir, birebir ayni performansla
calisir, aslinda aynidir. Gelistirici icin hangisi daha kolay gorunuyor ?
---- test.prg xharbour----
PROCEDURE Main
cFileName:="deneme.txt"
cText:=memoread(cFileName)
cText:=MemoEdit( cText,1, 1 , MaxRow()-1, MaxCol()-1, .T., "USERFUNC" )
if lastkey()#27
MemoWrit( cFileName, cText )
endif
RETURN
---test.prg sonu
---- test.c ---
#include "hbvmpub.h"
#include "hbinit.h"
HB_FUNC( MAIN );
HB_FUNC_EXTERN( MEMOREAD );
HB_FUNC_EXTERN( MEMOEDIT );
HB_FUNC_EXTERN( MAXROW );
HB_FUNC_EXTERN( MAXCOL );
HB_FUNC_EXTERN( LASTKEY );
HB_FUNC_EXTERN( MEMOWRIT );
#undef HB_PRG_PCODE_VER
#define HB_PRG_PCODE_VER 9
#include "hbapi.h"
HB_INIT_SYMBOLS_BEGIN( hb_vm_SymbolInit_TEST )
{ "MAIN", {HB_FS_PUBLIC | HB_FS_LOCAL | HB_FS_FIRST}, {HB_FUNCNAME( MAIN
)}, NULL },
{ "CFILENAME", {HB_FS_PUBLIC | HB_FS_MEMVAR | HB_FS_MESSAGE}, {NULL},
NULL },
{ "MEMOREAD", {HB_FS_PUBLIC}, {HB_FUNCNAME( MEMOREAD )}, NULL },
{ "CTEXT", {HB_FS_PUBLIC | HB_FS_MEMVAR | HB_FS_MESSAGE}, {NULL}, NULL },
{ "MEMOEDIT", {HB_FS_PUBLIC}, {HB_FUNCNAME( MEMOEDIT )}, NULL },
{ "MAXROW", {HB_FS_PUBLIC}, {HB_FUNCNAME( MAXROW )}, NULL },
{ "MAXCOL", {HB_FS_PUBLIC}, {HB_FUNCNAME( MAXCOL )}, NULL },
{ "LASTKEY", {HB_FS_PUBLIC}, {HB_FUNCNAME( LASTKEY )}, NULL },
{ "MEMOWRIT", {HB_FS_PUBLIC}, {HB_FUNCNAME( MEMOWRIT )}, NULL }
HB_INIT_SYMBOLS_END( hb_vm_SymbolInit_TEST )
#if defined(HB_PRAGMA_STARTUP)
#pragma startup hb_vm_SymbolInit_TEST
#elif defined(HB_MSC_STARTUP)
#if _MSC_VER >= 1010
#pragma data_seg( ".CRT$XIY" )
#pragma comment( linker, "/Merge:.CRT=.data" )
#else
#pragma data_seg( "XIY" )
#endif
static HB_$INITSYM hb_vm_auto_SymbolInit_TEST = hb_vm_SymbolInit_TEST;
#pragma data_seg()
#endif
HB_FUNC( MAIN )
{
static const BYTE pcode[] =
{
133, 2, 0, 106, 11, 100, 101, 110, 101, 109, 101, 46, 116, 120,
116, 0, 83, 1, 0, 134, 1, 108, 2, 100, 109, 1, 0, 12,
1, 83, 3, 0, 134, 2, 108, 4, 100, 109, 3, 0, 122, 122,
108, 5, 100, 12, 0, 128, 255, 255, 108, 6, 100, 12, 0, 128,
255, 255, 120, 106, 9, 85, 83, 69, 82, 70, 85, 78, 67, 0,
12, 7, 83, 3, 0, 134, 3, 108, 7, 100, 12, 0, 92, 27,
69, 28, 15, 134, 4, 108, 8, 100, 109, 1, 0, 109, 3, 0,
20, 2, 134, 6, 7
};
hb_vmExecute( pcode, symbols );
}
---- test.c sonu ----
Serdar KÖYLÜ wrote:
> Hayır, hatta, n'ayırr, n'olamazzz...
>
> Mesele, burada "yahu C ile şunu yapmak için ömrünüz biter" gibi
> yapılan çıkışlar. Bakıyorum, onları yapamk için C gayet makul, gayet
> verimli vede süratli.
>
> Hani deseniz ki, bir şekilde uygulamayı jail içinde, yani sistemin
> sadece istenen kısımlarına istenen şekilde erişimini sağlayacak
> şekilde yazmak gerekiyor, o zaman tamam, kabul. Veya daha başka,
> yüksek seviyeli dilleri öne çıkaran faktörüler. O da tamam.
>
> Her şeyi C ile yazmak olacak şey değil. Fakat, yüksek seviyeli bir dil
> kullanmanın anlam ve önemini hazır bir kaç kod kütüphanesi veya
> komponente indirgemek bence abes. Yüksek seviyeli diller elbette
> iyidir, kullanılmalıdır. Ama faydaları bu değildir, bundan daha
> fazladır.
>
> Bir bakalım, yüksek seviylei dilleri savunanlara yukardan aşağı. Olay
> sanki -atıyorum- java ile yazınca çok kolay, çok hızlı, çok çabuk
> olacakmış gibi geliyor, doğru mu? Ama java'nın varlık sebebi bu değil
> ki? Bu da doğru mu?
>
> C her zaman en iyi olmaz. Ama onun gücünü bilmeden, tanımadan, onu öcü
> sanıp kenara atmak, öğrenmekten kaçınmak, bir programcının kendine
> yapacağı en büyük zulüm olacaktır. Pek çok durumda, C/C++ kördüğümü
> açacak iskenderin kılıcı olarak hazır olur. Ve dahası, C ile kod
> yazmayı bilen, C kullanmayı, C ekosistemini bilen, diğer dillerin
> tümünde çok çok etkin kod yazabilir. Çünkü, garip gelebilir, ama tüm
> diller aslında C'ye bir wrapper'den ibaret gibidir. Açın bakın ve
> görün dilerseniz.
>
>
> 2012/4/24 Gurbuz Sanatci<[email protected]>:
>> Ben abes olmaya devam edeyim izninizle :)))
>> Rastgele bir web sayfasi konu ile ilgili
>> http://www.kuro5hin.org/story/2004/2/7/144019/8872
>>
>> "Butun programlama dilleri bosuna uretilmis, hersey C ile yapilmali"
>> teziniz bu mudur ?
>>
>>
>>
>>
>>
>> Serdar KÖYLÜ wrote:
>>> Kusura bakmayın ama, abes olmuş sadece.
>>>
>>> stri_replace, php ile yazıldığından daha hızlı yazılır C ile. Ama
>>> anlamadığım şey şu. Neden PHP'de hazır olan bir kütüphaneyi kullanmak
>>> doğal oluyorda, C için olanı ki sistem kaynıyor onlarla, kullanmak
>>> yanlış olsun?
>>>
>>> PHP'de vs. bu gibi şeyler hazır kıta var diye, neden C'de olmayacağı
>>> farzediliyor ki?
>>>
>>> Sana basitçe, gelen sinyalin faz açılarını eşitleyen bir equalizer
>>> yazalım, kim daha çabuk yazacak desem? PHP ile sen C ile ben. Sence
>>> hangimiz daha çabuk yazarız?
>>>
>>> Ha, it++ gibi bunu küt diye hazır yapan kütüphanelerin varlığını
>>> düşününce ve bunu yapmak dakikalar sürecek olunca, C/C++'da kod yazmak
>>> daha mı kolay olacak?
>>>
>>> PHP veya Python'da ne varsa, hepsi C'de zaten var. Ama daha önemli bir
>>> şey var. Elinizde C varsa, PHP veya Python'da olan herşeyiniz emin
>>> olun ki %100 var. Zira, C'den her dile erişebilirsiniz, doğrudan, C
>>> fonksiyonu imiş gibi.
>>>
>>> Ve evet, C'de o bildiğiniz hazır şeylerin hepside var. Hatta, o hazır
>>> şeylerin çoğu aslen C'de var, atıyorum PHP için onun üzerine
>>> geçirilmiş bir wrapper var.
>>>
>>>
>>>
>>>
>>>
>>> 2012/4/24 Gurbuz Sanatci<[email protected]>:
>>>> Oylece dusunduklerimi yaziyorum, tamamen kisisel...
>>>> Ihtiyaca gore bakmak daha dogru bence.
>>>> Biraz da ters orneklerle gidelim mi ?
>>>> C dili ile herhangi bir web sunucusunda calisan bir iletisim formunu
>>>> hazirlayabilir misiniz ? Ya da ne kadar surede hazirlarsiniz ?
>>>> C ile bir php'deki stri_replace fonksiyonunun gorevini yapan
>>>> fonksiyonu hazirlamaniz ne kadar surer ? Elbette kendi fonksiyon
>>>> kutuphanelerinizde bu tur seyler vardir ama olmadigini varsayarsak...
>>>> Clipper, xHarbour gibi xBase dillerinin neredeyse tumu, C temelli
>>>> kutuphaneler ile hazirlanmistir.
>>>> "Makinadan uzak diller", icinde bir cok hazir kontrolu bulundurdugu icin
>>>> kolay ve hatasiz (az hatali) yazilim gelistirmeyi saglarlar.
>>>> Ben C ile bunlari yaparim derseniz, verimli olmak icin kendi
>>>> kutuphanelerinizi ya da bir takim hazir kutuphaneleri kullanmaniz
>>>> gerekir ki, bu da "Makinadan uzak diller"in yaptiginin bir benzeridir.
>>>> Mesela C ile bir datagrid uygulamasi yapmak isterseniz ve bunu sifirdan
>>>> standart bir C dili ile yapmaya kalkarsaniz, delphi'deki, clipper'daki
>>>> ya da TMS Componentlerindeki (ozel bir kutuphane) gibi bir sonuca
>>>> ulasmaniz aylar belki de yillar alir.
>>>> Ama oyle durumlar vardir ki hazir kutuphanelerde bulamazsiniz ya da
>>>> istediginiz ozellikleri tasimaz. Mesela dogru durust surucusu olmayan
>>>> bir scanner'i kontrol etmeniz gerekir ya da benzeri birsey. O zaman
>>>> dogru arac C ya da C++ olabilir.
>>>> Bir gozlemim de yillar icerisinde bu tur ozel ihtiyaclarin gittikce
>>>> azaldigi seklinde.
>>>> Diyelim ki C cok guzel bir Isvicre cakisi (cok amacli). Ama onunla sihhi
>>>> tesisat yapmak yorucu olabilir, daha uygun baska aletlere ihtiyaciniz
>>>> olacaktir.
>>>> Ozellikle de son yillarda; DLL, XML, json vb. bircok kavram, platformlar
>>>> ya da diller arasi iliskiyi guclendirmek icin ortaya cikti. Yoksa herkes
>>>> herseyi C ile hallederdi...
>>>> Mesela su aralar 96 milyon kaydi olan bir veritabani ile ugrasiyorum.
>>>> Bunun icin, SSD disk uzerinde calisan bir mysql kurdum. Cunku yazilim da
>>>> yetmiyor bazen, donanima da yuklenmek gerekiyor.
>>>> Farkli bir tanimla basarili programcilik, insan faktoru dahil tum faktor
>>>> ve bilesenleri, esgudum icinde birlikte kurgulama, calistirma ve
>>>> optimize edebilme becerisidir.
>>>>
>>>>
>>>>
>>>> Serdar KÖYLÜ wrote:
>>>>> Geçen bir arkadaşla konuşuyoruz. Diyor ki, amanda C çok zor filan.
>>>>> Mesela bir server soket uygulamasını ben java ile iki günde
>>>>> yapabiliyorum hemen.
>>>>>
>>>>> Güldüm. Çünkü bunu sigara molasında saat 11:00 gibi konuşmuştuk. Ve
>>>>> ben çıkarken, sabah bir pty üzerinden aldığı stream'ı bir tcp
>>>>> soketinden aktaran, her iki noktada non-blocking olan multithread bir
>>>>> şey yazmıştım ki, yazmaya tasarım vs. dahil sabah başlamıştım.
>>>>>
>>>>> Belki bu "Yahu ben soket programlama olayını bilmiyorum, öğrenecek
>>>>> kafayı de kendimde göremiyorum. Benim için bunu Java yapıveriyor,
>>>>> yapayım."
>>>>>
>>>>> Peki ya ortaya çıkan kod nasıl oluyor? Bunu görünce asıl o zaman belli
>>>>> oluyor olay.
>>>>>
>>>>>
>>>>> 2012/4/24 Mucibirahman İLBUĞA<[email protected]>:
>>>>>> 24-04-2012 11:31 tarihinde, Serdar KÖYLÜ yazdı:
>>>>>>> Bir türlü anlayamam bunu. C ile yazınca neden geç olması, zor olması,
>>>>>>> vakit alması gereksin ki? Kendi adıma hep bunun tersini görüyorum
>>>>>>> zira.
>>>>>> Selamlar,
>>>>>> Aslında bence de değişik bir yorum bu! Mesela Delphi ile pencereyi
>>>>>> kolayca tasarlayabiliyor ve ve kodu bir anda tuş içerisine veya olaya
>>>>>> yazabiliyorsunuz. Ancak kısa süreli araştırmalarıma dayanarak C veya C++
>>>>>> da neredeyse bu kadar kolay olabiliyor. Qt Creator ile yazdığınızda
>>>>>> Delphi'yi aratmayacak kolaylıklar var.
>>>>>>
>>>>>> Sanırım insanların aklında hala eski yöntemler olduğu için böyle
>>>>>> düşünülüyor. VB veya Delphi gibi kolayca proje hazırlanabilecek
>>>>>> ortamlara yönelme olmuş. Bu yüzden "zaman kazancı" deniyor olabilir.
>>>>>>
>>>>>> Fakat C ile sağlanacak hız ve verimlilik ve en önemlisi platform
>>>>>> bağımsız olması tadından yenmez bir şey bence. C (C++)'ye kasmam da bu
>>>>>> yüzden aslında. Python ve C ile bir kaç döngü denemesi yaptım. Hız farkı
>>>>>> gözden kaçacak gibi değil...
>>>>>>
>>>>>> --
>>>>>> Kolay gelsin,
>>>>>> Mucip:)
>>>>>>
>>>>>> _______________________________________________
>>>>>> Linux-programlama mailing list
>>>>>> [email protected]
>>>>>> https://liste.linux.org.tr/mailman/listinfo/linux-programlama
>>>>>> Liste kurallari: http://liste.linux.org.tr/kurallar.php
>>>>> _______________________________________________
>>>>> Linux-programlama mailing list
>>>>> [email protected]
>>>>> https://liste.linux.org.tr/mailman/listinfo/linux-programlama
>>>>> Liste kurallari: http://liste.linux.org.tr/kurallar.php
>>>>>
>>>> _______________________________________________
>>>> Linux-programlama mailing list
>>>> [email protected]
>>>> https://liste.linux.org.tr/mailman/listinfo/linux-programlama
>>>> Liste kurallari: http://liste.linux.org.tr/kurallar.php
>>> _______________________________________________
>>> Linux-programlama mailing list
>>> [email protected]
>>> https://liste.linux.org.tr/mailman/listinfo/linux-programlama
>>> Liste kurallari: http://liste.linux.org.tr/kurallar.php
>>>
>> _______________________________________________
>> Linux-programlama mailing list
>> [email protected]
>> https://liste.linux.org.tr/mailman/listinfo/linux-programlama
>> Liste kurallari: http://liste.linux.org.tr/kurallar.php
> _______________________________________________
> Linux-programlama mailing list
> [email protected]
> https://liste.linux.org.tr/mailman/listinfo/linux-programlama
> Liste kurallari: http://liste.linux.org.tr/kurallar.php
>
_______________________________________________
Linux-programlama mailing list
[email protected]
https://liste.linux.org.tr/mailman/listinfo/linux-programlama
Liste kurallari: http://liste.linux.org.tr/kurallar.php
