Múlt héten se volt sok időm, úgyhogy itt van egy régebbi.
Legjobb trailer:
Action, On set with: NANAKITTY:
Guess the song :), Best Friends
The Professionals
Múlt héten se volt sok időm, úgyhogy itt van egy régebbi.
Legjobb trailer:
Action, On set with: NANAKITTY:
Guess the song :), Best Friends
The Professionals
A hétvégén leszedtünk és kimagoztunk 15 kg meggyet 🙂
2013-at Ãrunk, de a MÃVnál még mindig nem sikerült elérni hogy 35 fokos hÅ‘ségben menjen a klÃma az IC elsÅ‘ osztályán…
A héten nem nagyon volt idÅ‘m videókat nézni, de azért itt van egy 🙂
Ez a hét egy újabb sikeres C# tanfolyam tartással zárult 🙂
felicia day
Co-Optitude (a little long, but fun if you are not in a hurry)
meekakitty (from last week)
life advice
me and my guitar
Music Video: (Rotoscoping)
packing:
akward: (Rotoscoping)
“get out of here you tone deaf failure”
Ok, there are characteristics where c++ has the advantage, but I’m not talking about that now.
Delphi has properties! They are great if you are in the process of creating a new library. Why? Because when you start you can just set a bunch of variables public, you do not need to implement setter and getter functions. Later you can decide to make some of those variables private, and create properties and setter functions for them (checking, limiting range, do stuff on change). Usually you do not need to write getter functions at all.
private
FPosStart,FPosEnd:integer; /// ...
protected
procedure SetPosStart(value:integer); /// ...
published
property PosStart:integer read FPosStart write SetPosStart;
The main advantage here is not that we do not have to write getter function.
Imagine that the library is used extensively (by you, or others). AFAIK in C++ a change like this would break compatibility. Code would have to be changed to PosStart() / getPosStart() and setPosStart(…) form ‘… PosStart’ and ‘PosStart = …’
In Delphi constructors are inherited. It’s not a big deal, I did not even realize it until now. I’m reading Large Scale C++ Software Design about cyclic dependencies, levelization, mutually dependant components. It suggests not to write constructors that convert between classes, but rather write separate converter class with static methodes. But that does not seem very objectum oriented to me. It reminds me of itoa() and stuff like that. It works but still… So, I was wondering why not create descendant classes (or ancestor classes) and implement an additional constructor in the descendant class, that converts form the ancestor classes. It’s a little more typing but not much… or so I thought, then I realized that I needed to reimplement all the ancestors constructors… which is not the case in delphi. It’s a rather common practice to use your own descendant classes of standard controls from the start, just in case you will ever need to add some functionality. It’s easy, and cheap.
TMyCollection = class(TCollection) end;
Youtube meekakitty felhasználó összes szerzeménye.
Pl. “Let’s go outside” music video.
“Outside is nice cause it goes worldwide”
“We like things and so should you”
“We’ll climb a chair and we’ll never die”
I was just watching Pointless podcast with Kevin Pereira episode 16 with Alison Haislip. .. oh good old Attack of the Show…
I miss these guys. Kevin always has the “best” stuff. (some old some new)
So here are some things you do NOT want to Google/Bing…
lemonparty(.org)
2 girls 1 cup
one guy one jar
meatspin
—
Other things that you do NOT want to see:
blue waffle
2 guys 1 horse
Pár érdekes videó biztonsági konferenciáról.
DEFCON 20: Hacker + Airplanes = No Good Can Come Of This
ADS-B
https://www.cgran.org/wiki/gr-air-modes
github.com/bistromath
DEFCON 20: Bypassing Endpoint Security for $20 or Less