na ezt majd végigolvasom

most hogy már van egy solid core, és nagyjából működik a szakdogám, illetve inkább csak látom az alagút végét,

elkezdtem abban is gondolkozni, hogy lassan dokumentációt is kell írni + nem akkor kéne kitalálni mindent
eredmény -> xD
("//TODO xyz"-t kigyűjti vagy VS vagy ReSharper, nem tudom)

Face detection algoritmust kell irni image processing targy beadandonak
Cppben irom, majd blogolok vele ide
Kiveve ha a cegnel fel akarjak hasznalni, de erre holnap rakerdezek

This post was edited by xGurke on Nov 4 2014 04:22am

na, a tanár már teljesen oda van értem, hogy mennyire belelkesültem a témától
már csak arra vagyok kíváncsi, hogy bent mit szólnak hozzá
meg hogy felhasználhatom e az ottani irodalmat, kutatási anyagokat

700 forintért vagdossák a domaineket + úgyis van céges privát Azureom

http://anarkin.info/

Azure stack: Website, Azure SQL, Domain -- később Table Storage (NoSql)
.NET stack: .NET, ASP.NET, ASP.NET MVC, C#, Entity, F#
Web stack: Ajax, Bootstrap, jQuery, Prettify

stb-vel készül, egész csini lett

Nincs #define macro a c#-ban.

A c# bánt.

miért nem segítesz c#

Lehetséges ennyire rövid formát írni c#-ban?



Kombinációs logikák gyors leírásához kellene, de a legrövidebb forma, ami megoldást találtam nem ennyire kifejező
az ilyen b(Rb,3) és társai nem annyira kifejezőek és gyorsan leírhatóak, mint ez.

De lehet csak én vagyok béna, c#-ban még nincs nagy tapasztalatom.

A google szerint a kód olvashatósága miatt nincsenek benne ilyenek, de ez elég buziság, mert ebben az esetben pont hogy jobb lenne.

This post was edited by CyberPunk666 on Nov 7 2014 04:54pm

maintainable code over all
lehet nézegetni hogy milyen gyönyörűséget alkottál, de még akkor sem éri meg ha a fejlesztője überhatékony és 8 másodperc alatt megold bármit,
mert a következő embernek aki látja a kódot - esetleg belenyúl - már úgy kell megértenie mindezt, hogy nem ő találta ki
és ha ő is mondjuk zseni, akkor is 15x annyi idő lesz, mert amit nem te találsz ki az ilyen

macro = evil

amúgy a method call kb 4 nanosec (Writing Faster Managed Code: Know What Things Cost -> http://msdn.microsoft.com/en-us/library/ms973852.aspx)


--
ezért is van az hogy nem fieldeket publikálsz osztályban hanem ezt írod le


ezzel is van egy kis különbség

főleg hogy úgysem a method vagy property call tart X ideig, hanem ami benne van az teszi ki az idő 99.99999999999999%-át



This post was edited by Anarkin on Nov 7 2014 05:23pm

Alapvetően egyet értek veled és én is így tanultam. #define macrot nem is használok túl gyakran, sőt még eddig nem is volt rá szükségem.

De vannak olyan esetek, amikor szerintem más is megérti hamar.

Jelen esetben például a fent írt jelölés a digitális technika szokásos jelölése erre. Más -ezt rendesen támogató- nyelvekben ráadásul eleve használható forma.<jó, a vhdl azért elég speciális példa>
A feladat egy drága eszköz számítógépes szimulációja az iskola számára. A jelölésmód a szimulálandó eszköz leírásában használttal egyezik (ami megint csak azért van így, mert ennek ez a bevett szabványos jelölése). <szóval ha valaki megnézi, hogy mi is ez az eszköz, akkor ott ugyanezzel fog találkozni>
Nem a hívás sebessége miatt aggódom (gondolom c#-ban is van inline fv), hanem azért mert kb 150 művelet, műveletenként átlagosan 4-5 register értékét kell kiszámolni kombinációs logikával. Belehalok, mire megírom.

(amúgy nem áll szándékomban nyílttá tenni a kódot)

Szóval egyetértek veled az alapelvet tekintve, és én is találkoztam már idióta macrokkal, és ahol csak lehet elkerülöm őket.
Lehet a dolgokat ésszel használni.

//Valószínűleg az lesz a megoldás, hogy írok egy programot, ami a hagyományos jelölést az itt használható formává konvertálja.
Akkor én is megírom még idén őket, és a c# is boldog lesz.

This post was edited by CyberPunk666 on Nov 8 2014 02:43am