To ze "nie C" je cisto moj nazor, podla mna uz ten jazyk ma svoje roky za sebou a C++ je jeho dobry nastupca ktory ho plne nahradza, je stale rovnako low level a navyse prinasa velmi vela uzitocnych veci, pisat dnes novy kod v C je uz hlupost a radsej malo by ist do softwaroveho muzea.
takze pisete vzdycky 2 verze, Jednu pro p2 a druhou pro p3. A az udelaji p4 tak dalsi verzi. To je skutecne senzacni.
Jeste pro vasi informaci. To EXE, ktere bylo napsano v C a prelozeno uz ten c-prekladac na zadnem jinem pocitaci nepotrbuje. Tam uz je to na rozdil od toho vaseho preferovaneho udelatka prelozene :-)
tak ja jsem me programy vytvorene v SCO-Unixu pod linuxem vesele spoustel. (iBCS). Ale jo, to je davna minulost.
Pan Stehule hovoril o systemovych utilitach a proc ma pravdu je videt na 'yumu' , ktery je v RHEL zavisly na urcite verzi pythonu a to je prave ta debilita, Systemovy tool musi byt zavisly jen na sobe a ne na rade jinych komponent , zvlast kdyz takova systemova komponenta je urcena pro pohodlnou vymenu sebe sama :-) Jak na tohle ti pitomci v RedHatu prisli mi fakt hlava nebere.
Zkuste si nainstalovat pomoci yumu nove django na centos 6. :-)
Povedzte Kefalín, čo vy si predstavujete pod takým slovom skript? https://root.cern.ch/cint
Není poznat koho se ptáš, a tím rádoby vtipným oslovením jsi to nevylepšil.
Obecně je skript interpretovaný program. U webových dynamických stránek je tímto interpretem webový prohlížeč. Takže stále setrváváme v pozici, že někteří diskutující ani netuší o čem je řeč, ale rozhodně se proti tomu vymezují :-). Kdo si myslí, že existuje univerzální programovací jazyk na všchno, jednoduše nemá dostatečný rozhled.
eee, co takhle si nejdřív ujasnit rozdíl mezi server-side a client-side dynamickou webovou stránkou, než nás tady začneš obšťastňovat svými moudry? https://en.m.wikipedia.org/wiki/Dynamic_web_page
To si právě představí menšina bez rozhledu, která vidí jen to svoje. Python je považován za programovací jazyk a v jeho kontextu se programuje, vytvářejí ucelené programy. Když se mluví o skriptování webových stránek, většině lidí je zřejmé, že jde o jejich oživení javascriptem. Skriptují se aplikace, případně případně příkazový řádek. A promouly dodávám, že skriptovat aplikaci neznamená ji vytvářet, ale skriptem ovládat. Tak jak to js dělá ve webovém prohlížeči. Normálnímu it vzdělanému člověku by měl být jasný rozdíl mezi programováním a skriptováním aplikace.
To by mě vážně zajímalo, proč myslíte, že C má "svoje roky za sebou" ? V embedded světě se C díky své přehlednosti používá daleko více a naopak od C++ se upustilo už někdy před 10-ti lety.
Podobně když budu chtít napsat nějakou aplikaci, tak použiji nějaký vysokoúrovňový jazyk s GC a nebudu se mastit s nějakými pointery a manuálním uvolňováním paměti.
Pokud jde o výkon, tak prakticky všechny vysokoúrovňové jazyky nabízejí FFI do C - do C++ pak už jen některé, protože ten jazyk je prostě příliš překombinovaný.
Takže za mě má C budoucnost coby univerzální nízkoúrovňový jazyk, naopak v C++ žádnou budoucnost nevidím - to je podle mě takový nový Cobol.
To je právě ono, podobné diskuze o nej jazyku mě vždy dostávají, jazyk se má vybírat podle use case a ne podle toho co má programátor rád. Takže souhlas.
Každý jazyk má něco do sebe a každý vznikl pro nějakou oblast, protože pokud by existoval dokonalý programovací jazyk tak by nevznikaly další a další.
posledne 4 roky v embedded vyuzivam vyhradne C++ a podla moznosti uz nikdy viac ciste C!
preco?
- uz aj pri malych tooloch je to pohodlnejsie
- dokazem mat cistejsi a hlavne citatelnejsi kod
- nepotrebujem prasit kod s nejakymi #define
- nemusim emulovat objekty, ale pouzivam skutocny objektovy pristup
- kod ktory vytvorim v C++pre embedded a po dodrzani urcitych pravidiel je rovnako ak nie lepsie optimalny ako podobny kod ktory mi vypadne z C
- C++ je rovnako nizkourovnovy ako C ale pridava mnoho veci ktore ten jazyk posuva na vyssiu uroven ako obycajne C pri zachovani nizko urovnovnovosti
- pise sa rok 2017 (vlastne uz za nejakych 24hodin 2018) a prave preto by sme mali nasledovat trocha dobu
Myslim si ze zarity C-ckari co nemaju radi C++ su prave riadne lenivy ludia ktorim sa nechce naucit nieco a posunut sa trocha dalej aby napriklad vylepsili kvalitu svojho kodu.
celkem souhlas az na:
- kod ktory vytvorim v C++pre embedded a po dodrzani urcitych pravidiel je rovnako ak nie lepsie optimalny ako podobny kod ktory mi vypadne z C
toto by chtelo dolozit prikladem. Asi mas na mysli, ze vysledny strojak bude rychlejsi nebo zabere min mista (jen se ujistuji co je mysleno tim "lepsie optimalny", protoze "optimalni" je uz samo o sobe absolutni meritko :)
to jdes proti proudu: https://www.tiobe.com/tiobe-index/, cituji jen uvod (protoze se ta stranka do tydne zmeni):
"The programming languages Kotlin and C seem to be the only candidates to become programming language of the year 2017. TIOBE will announce the winner of this award next month. Thanks to the boost of small software devices and the increase of low level software in the automotive industry, the C programming language gained a lot of popularity in 2017."
C++ si udelalo spatnou povest a i kdyz C++11 (14) uslo velmi dlouhou cestu dopredu, tak "klasicke" C++ byl velkej humac (hlavne, kdyz se pouzivalo jen jako C s tridami, coz bylo v embedded nutnost)
Ano, je to bohuzial tak, ale dovod preco C v embedded svete vedie osobne vidim inde.
Pracujem v danom odvetvi uz celkom dlho a mam trosku predstavu ako to je (aspon u nas vo firme). Jednak najst embedded vyvojara je stale celkom narocne, pretoze vela SW vyvojarov netusi takmer nic o elektronike a embedded vyvojar by sa mal v tom orientovat (aspon vediet citat schemu, pochopit periferie z datasheetov a dokazat si pripojit osciloskop alebo logicky analyzer). a za tych co sa k nam dostanu sme niekedy radi ze vedia aspon C. Druhy problem je ze aj ked vo firme je vela vyvojarov ktori C++ ovladaju tak su donuteni (ci uz z projektovo-historickych dovodov, alebo inych napriklad politickych) programovat prave v C-cku.
Nadruhu stranu casy sa menia a vela mladych vyvojarov uz s C++ ma skusenosti a ma aj motivaciu v tom vyvijat a musim povedat ze nove projekty sa coraz castejsie pisu prave v C++. Tak hadam o rok bude C++ niekde inde v embedded svete.
Osobne pracujem na novych projektoch kde sme zacinali prakticky na zelenej luke a nebol problem C++ presadit a som zato rad.
(mam na mysli minimalne C++11)
v podstate souhlas, diky za doplneni. Jen me napada - delate ty nove embedded aplikace s nejakymi vykonnejsimi cipy typu H8SX, H8/300H, ARM, TriCore, nebo i s mensimi cipy (MSP 430 nebo dokonce osmibity)?
U nas se to lamalo nekde u MSP 430: mensi cipy jen C (C++ melo mnohem vetsi runtime, neslo PRAKTICKY pouzit nic slozitejsiho typu vyjimky apod.), vetsi cipy klidne C++. Mozna mozna v budoucnu zkusime i Rust, ale zatim to nema tak dobry tooling.
Starsie projekty: MSP430: +/-32KB/2KB flash/ram (IAR - C++99 - ale chybali mi nejake veci z 11)
Aktualne ARM: od malinkych M0 16KB/2KB az po velke M4 s 1MB/320KB flash/ram (GCC C++11 alebo 14)
Vsade s vypnutymi vynimkami a rtti, new a delete len nad lokalnym pool-om, ziadne std (lebo to vyuziva vynimky) ale mame vlastne zjednodusene/usite implementacie zakladnych funkcii ... u tych najvacsih procakoch mame nejaku newlib, to prida tak cca 80-150KB kodu ale potom mozem pouzivat cokolkvek z C++ vratane std a boost.
Ale vynimky a RTTI, heap, ale aj thready a podobne su v embedded cesta do pekla a navyse to ma obrovsku reziu lebo v mnohych projektoch riesime prakticky kazdu mikrosekundu.