global de static

[Arda]

Başka .cpp kaynak dosyaları tarafından çağırılabilen bir interface (arabirim) fonksiyonum var. Bu fonksyonun içinde static değişken yaratmanın manası nedir? Zaten fonksyon çağırıldığında sonuna gelene kadar işlenecek ve bu işlem bittiğinde içindeki değişkenlerinde ömrü sona erecek. Acaba static yapınca sona ermiyor mu? Eğer öyleyse bunu fonksiyon dışında declare etmek daha mantıklı olmaz mı?

(bugün soru sorasım var, bezdim şu kodu 2-3 gündür çözmeye çalışıyorum )

[cemuzunlar]

ilk once bahsettigin islemlerin, c++ ve class'lar yardimiyla daha hos sekilde cozulebilecegini soyleyeyim.

fonksiyonun icinde static olarak tanimlama yapilmis bir degisken, fonksiyondan cikildiktan sonra da yasamaya devam eder. Bu degiskeni global olarak tanimlamak da mumkundur, ama tasarim acisindan hos degildir. Cunku, sadece bu fonksiyonun erismesi gereken bir degiskene, kodun her yerinden erisimi acmis olursun.

[Arda]

hm anladım sağolasın

Bu arada okuduğum ve kullanmaya çalıştığım kod mimarisi GameDev'deki Code on the Cob serisine ait. Chris Hargrove C++/Class kullanımı ve klasik C stili kod kullanışının nedenlerini kısaca(!) şu şekilde anlatmış:

Class Exposure

C++ has a few language problems that make abusing top-down design and inheritance an unwise idea simply from a practicality standpoint. One is the fact that it's too easy to inherit from concrete classes that were never intended to be inherited from. But the biggest one in my eyes is class exposure, an inherent problem in the way C++ classes are created. When you write a class, both public and private data members and method functions are declared, and the class is usually placed in a header file so it can be used by others. The public stuff is not a problem, as that needs to be there (it's the interface to the class after all). But so does the private stuff, and that's bad.

What you've got is a situation where everything using a class knows the private organization of that class, and any time you want to change that organization, the change is exposed to everything uses that class, requiring recompilation. Such compile-time dependencies are insignificant early in a project, but can become a major productivity hit when the codebase gets big enough. This is different than interface/implementation separation in C, where static "private" variables and functions of a subsystem are only listed in a .c/.cpp source file and not in a header, so changing them only requires that one file to be recompiled. Putting an equivalent subsystem in a C++ class would add significantly more compile-time dependencies. It would also expose the internal structure of that subsystem to everything outside it.

This is one of the big reasons I stick with mostly C-like interfaces when possible, even in C++ code. When anything dealing with implementation is exposed, black-box separation is broken, and I don't want that. I'll use C++ classes when they make sense and the benefits outweigh the costs, but I'm not about to incur those costs and invite entropy for no good reason.

Even when my code isn't object-oriented at the physical level in C++, it's object-oriented at the logical level, to such an extreme degree that C++ itself automatically damages encapsulation. So if people look at my C-like interfaces and start wondering whether I know anything about object-oriented programming, my egotistical response is "damn right I do". C++ is a language that likes to tempt you, and it has many temptations that are worth taking from time to time. But don't blindly abuse it just so you can pretend you're being object-oriented. Object-orientation and good design go far beyond the keyword "class".

Dokümanın devamı için: tıkla!