OldComp.cz
http://oldcomp.cz/

Programování v C
http://oldcomp.cz/viewtopic.php?f=113&t=3231
Stránka 911

Autor:  faraon [ 12.09.2018, 11:17 ]
Předmět příspěvku:  Re: Programování v C

Pokud by bylo možné ten soubor zpracovávat sekvenčně, třeba i na víc průchodů, tak bych tu optimalizaci zase tak moc do extrému nehnal.
Ale tobě asi nebude stačit nějaké nahrazení úseků textu jinými ;-)

Autor:  microlan [ 06.02.2019, 08:29 ]
Předmět příspěvku:  Re: Programování v C

Co si mám nainstalovat pro jednoduchou práci v C pod Win7, kdysi jsem něco dělal, ale to bylo ještě v DOSu, tuším něco od Borlandu.

Autor:  Kubik [ 06.02.2019, 08:38 ]
Předmět příspěvku:  Re: Programování v C

CodeBlocks, Visual Studio, Dev C++...

Autor:  microlan [ 06.02.2019, 08:56 ]
Předmět příspěvku:  Re: Programování v C

Díky, ale chtěl něco jednoduchýho, při pohledu na visual studio mě berou mrákoty

//Ale ten CodeBlock vypadá celkem sympaticky, ale není to jen editor?

Autor:  Kubik [ 06.02.2019, 09:53 ]
Předmět příspěvku:  Re: Programování v C

Vsechno je to IDE. Moznosti je spousta, ale me zas treba obestiraji mrakoty pri pohledu na Eclipse - kdyz jsem se pred par lety snazil pouzivat Eclipse jako vyvojove prostredi pro ARM, po par dnech nastavovani jsem to vzdal a pouzil Keil :) Na takove to domaci zvykani pouzivam CodeBlocks, funguje celkem pekne.
Tipoval bych, ze pokud chces psat Windows programy, tak VS bude asi nejschudnejsi. Ja to obcas musim pouzit (ne na Windows programovani) a prijde mi to celkem intuitivni - jen to vypada ohavne.

Autor:  tomascz [ 06.02.2019, 10:18 ]
Předmět příspěvku:  Re: Programování v C

CodeBlocks jsem onehdá cca 2014 pro zajímavost zkoušel. Odešel jsem hodně rychle :-D Ale třeba ve vývoji pokročili.

Visual Studio je moloch (a nevypadá ohavně - vypadá stroze), spousta buttonků. Ale věz, že budeš potřebovat jenom hrstku z těch buttonků a v meníčkách jsou duplicity. Pokud máš na disku zbytných pár giga, určitě tomu dej šanci - VS je mainstream, "povinný standard." ;)

Autor:  microlan [ 06.02.2019, 10:33 ]
Předmět příspěvku:  Re: Programování v C

Nainstaloval jsem C::B a poměrně bez problémů to vygenerovalo prázdné windows wokno. Kam mám zařadit svůj jednoduchý program v tom zdrojáku? Řekněme volání funkce, kterou dole nadefinuji.

Kód:
    /* The class is registered, let's create the program*/
    hwnd = CreateWindowEx (
           0,                   /* Extended possibilites for variation */
           szClassName,         /* Classname */
           _T("Code::Blocks Template Windows App"),       /* Title Text */
           WS_OVERLAPPEDWINDOW, /* default window */
           CW_USEDEFAULT,       /* Windows decides the position */
           CW_USEDEFAULT,       /* where the window ends up on the screen */
           544,                 /* The programs width */
           375,                 /* and height in pixels */
           HWND_DESKTOP,        /* The window is a child-window to desktop */
           NULL,                /* No menu */
           hThisInstance,       /* Program Instance handler */
           NULL                 /* No Window Creation data */
           );

    /* Make the window visible on the screen */
    ShowWindow (hwnd, nCmdShow);

    /* Run the message loop. It will run until GetMessage() returns 0 */
    while (GetMessage (&messages, NULL, 0, 0))
    {
        /* Translate virtual-key messages into character messages */
        TranslateMessage(&messages);
        /* Send message to WindowProcedure */
        DispatchMessage(&messages);
    }

    /* The program return-value is 0 - The value that PostQuitMessage() gave */
    return messages.wParam;
}


/*  This function is called by the Windows function DispatchMessage()  */

LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)                  /* handle the messages */
    {
        case WM_DESTROY:
            PostQuitMessage (0);       /* send a WM_QUIT to the message queue */
            break;
        default:                      /* for messages that we don't deal with */
            return DefWindowProc (hwnd, message, wParam, lParam);
    }

    return 0;
}

Autor:  Panda38 [ 06.02.2019, 10:34 ]
Předmět příspěvku:  Re: Programování v C

Pro jednočipy (AVR, STM) s C/C++/ASM používám nejraději jen textový editor (ve FAR) a překlad s GCC přes příkazový řádek. Občas jsem používal i Keil, Eclipse, EmBitz, ale přece jen, není nad jednoduchost rozhraní jednoduchého editoru. :-) Na programy pod Windows je MS VC++ nejlepší volba. Oproti jiným prostředím je tam největší luxus, je to s ním nejpohodlnější. Ale je nutné počítat s tím, že samotné C/C++ neobsahuje rozumné knihovny např. na dialogová okna (MFC nepočítám, to jsou knihovny leda tak na ostudu). Na to vypadal být dobrý směr C++ Builder, který zahrnuje i rozsáhlé knihovny. Ale jeho výhoda je i nevýhodou - pokud chcete nějaký nestandardní úkon, tak je skoro až nemožné standardní knihovny obejít a doplnit nějakou svou vecpávku. Pro jednodušší programy dobrý, ale u složitějších dají ty obcházky tolik práce, že je pak už jednodušší vyjít z holého C++ přes Windows API a napsat si knihovny vlastní.

Autor:  Panda38 [ 06.02.2019, 10:36 ]
Předmět příspěvku:  Re: Programování v C

microlan píše:
Nainstaloval jsem C::B a poměrně bez problémů to vygenerovalo prázdné windows wokno. Kam mám zařadit svůj jednoduchý program v tom zdrojáku?...
Raději začni s konzolovým programem. Tam je funkce main(), kam snadno zařadíš svůj program. Pokud chceš oknový program, tam je to už složitější, protože se používají zprávy Windows, není to na program kde běží jedna dlouhá smyčka. V oknovém programu doplníš do hlavní funkce (před smyčku zpráv) nějaké své inicializace (např. vytvoření okenních prvků) a pak do obsluhy zpráv reakce na události, např. reakci na stisk tlačítka.

Autor:  microlan [ 06.02.2019, 10:56 ]
Předmět příspěvku:  Re: Programování v C

Díky, zkusím to cmd okno.

Autor:  Lanex [ 06.02.2019, 11:12 ]
Předmět příspěvku:  Re: Programování v C

Já osobně se v rámci Windows rozhodně přikláním k VS. Jak pro konzovolky (cmd), tak pro Forms. Spoustu věcí to udělá za vás, dokáže to při psaní kódu doplňovat některé věci, takže nemusíte hledat co tam pro správný syntax patří. A hlavně, lepší debugger pro vyhledávání chyb nenajdete.

Autor:  tomascz [ 06.02.2019, 12:13 ]
Předmět příspěvku:  Re: Programování v C

Panda38 píše:
MFC nepočítám, to jsou knihovny leda tak na ostudu

No ale nic lepšího (a free) nemáme, nebo aspoň já o tom nevím :-)

- WinAPI :like: ale upovídaný
- MFC - ok, používá makra a tolik neoblíbený pointer-to-member záležitosti, ale to je slabej argument; šetrné k paměti, rychlé; jinak wrapper okolo WinAPI
- WinForms - wrapper okolo wrapperu okolo wrapperu okolo WinAPI; pomalý GDI+; několik opravdu užitečných kontrolek, např. PropertyGrid nebo DataGrid
- WPF - vizuálně pěkný, ale syntakticky překombinovaný a nerad to používám, už proto, že do toho tolik nevidím a vždycky s tím bojuju (což je ode mě podobně slabej argument)
- Qt - placený
- pak jsou tu custom wrappery okolo WinAPI (např. Win32++), který se víc nebo míň snaží imitovat MFC.

Zapomněl jsem na něco? :shrug:

Autor:  Panda38 [ 06.02.2019, 12:45 ]
Předmět příspěvku:  Re: Programování v C

MFC má výhodu, že je tak jednoduchý, že se dá snadno obcházet (když je třeba). Až tak jednoduchý, že je nakonec skoro stejné používat přímo API. Nějak jsem tam nikdy nepochopil důvod rozdělení na Document a View. Přetypovává handlery na MFC objekty hledáním v tabulce, což je sice tak trochu zpomalující operace, ale nakonec i zbytečná. I obsluha hromadného načtení a zápisu obsahu okenních prvků je dost zpomalující operace, pro některé operace se nehodící. Když se okenní prvky obalí jednoduchými C++ třídami, tak nakonec je s tím práce stejně jednoduchá, resp. ještě jednodušší. Nikdy mi nepřišlo, že by mi MFC práci usnadnilo, spíš to byl zbytečný mezičlen který obsluhu spíše komplikoval.

Autor:  tomascz [ 06.02.2019, 14:01 ]
Předmět příspěvku:  Re: Programování v C

Panda38 píše:
Nějak jsem tam nikdy nepochopil důvod rozdělení na Document a View.
Aha... :-) Protože tak trochu jako pattern Model-View-Controller :-) Když máš víc typů dokumentů a víc pohledů na ně, tak jsi celkem rád, že to máš logicky oddělené místo jednoho velkého balastu. O zbytek se postará framework (např. vykonávání příkazů nad objekty, které o ten příkaz stojí). Dovolím si udělat osvětu touhle knížkou :poke: ;-)
Panda38 píše:
Přetypovává handlery na MFC objekty hledáním v tabulce, což je sice tak trochu zpomalující operace, ale nakonec i zbytečná.
Tady s vámi tak trochu jakoby úplně nesouhlasím - odkaz si nemůžeš uložit do custom dat okna (GWL_USERDATA), to musí zůstat volné pro koncového programátora. Hledání v tabulce je tak bohužel jedinou schůdnou možností. Při 1000 najednou existujících oknech je to deset dotazů do tabulky - to mi nepřipadá jako tak těžkej overhead.
Panda38 píše:
I obsluha hromadného načtení a zápisu obsahu okenních prvků je dost zpomalující operace, pro některé operace se nehodící.
To jako fakt? Pokaždý jsem byl rád, že to MFC udělá za mě a před zavřením dialogu validuje obsahy kontrolek. Snad se tedy bavíme o tomtéž :-)

Jak jsi napsal, není to ideální, ale je to dostatečně jednoduchý a dostatečně rychlý na jakýkoliv projekt. Napsání si veškeré logiky z gruntu ve vlastních třídách je sice fajn, nicméně při předávání projektu musí nový programátor projít veškerý kód, aby pochopil jak věci fungují. U MFC, WinForms, WPF (a určitě i Qt) je to standardizované frameworkem, což usnadní orientaci.

Nevím no, když si z programátorského pohledu vezmu kritéria jako rychlost, jednoduchost a úspornost, tak mě vychází právě MFC. V závěsu následované WinForms. Na opačném konci stojí WPF. Když to naopak vezmu z hlediska moderního uživatele, tak se pořadí frameworků obrátí - WPF, WinForms, MFC :shrug:

Snad jsem to dostatečně zanalyzoval :lol:

Autor:  Panda38 [ 06.02.2019, 14:28 ]
Předmět příspěvku:  Re: Programování v C

Jo určitě je MFC dobrá volba, když se někdo nechce zabývat přímo nižším rozhraním.

Když jsem kdysi (1995) přešel z DOS assembleru do Windows, nejdříve jsem samozřejmě zkoušel opět assembler. Rozsáhlejší Win program v assembleru bylo o život, to fakt nešlo. Další pokus byl v Delphi. Vizuálně rychle sestavit program s využitím bohatých tříd, jo to bylo prima. Ale nedal se ohnout - nedal se jen tak např. předefinovat vzhled tlačítka a program byl velmi pomalý. Vznikl tak Baltík 3 (napsaný v Delphi, na zakázku), ale vnitřně tak těžkopádný a neefektivní, že už s ním dnes rád nemám nic společného. :oops: Pak jsem přešel na MFC, program Gemtree Petr (programovací nástroj). To už bylo jiné kafe, program mohl být docela rychlý a efektivní. Ale přece jen, stále jsem se potýkal s ohnutím MFC pro mé potřeby, obcházení implicitního chování. Např. předefinování vlastních ikon s vlastními paletami v TreeView bylo skoro nemožné. Pak jsem si jednou řekl, že vlastně nadstavbu nepotřebuju. Začal jsem znovu od začátku, bez veškerých knihoven. To byla úleva! Najednou všechno šlo snadno a program byl výsledně i jednodušší než s MFC. Považuji to za jeden z nejlepších počinů který jsem na tom udělal, hodně to pomohlo. Rychlost interpreteru mohla konkurovat i kompilátorům. Dnes už bych se nechtěl vracet k nějaké knihovně. Mám nějaké své nadstavby a v těch mám konečně volnost k práci jakou potřebuju. Když jsem někdy používal cizí knihovny, tak jsem byl tak omezený jejich chybami, že mi vzalo více času chyby obcházet, než kdybych si ty knihovny napsal sám.

Validace kontrolů v MFC - jo sice dobrý, ale jen do té doby, kdy se používá standardní postupy a standardní prvky. Jak se začne chtít něco nestandardně změnit, tak začínají problémy. Vlastní validace a přenos hodnot je nakonec snadné a rychlé, na to tyhle nadstavby nejsou ani potřeba. Ale samozřejmě, může to být někomu příjemnější, když mu stačí standardní vybavení a nemá vyšší či nestandardní nároky. Výhodou MFC je, že se dá poměrně dobře kombinovat s ne-MFC přístupem, tak pak není až tak velký problém se sdílením projektů.

Stránka 911 Všechny časy jsou v UTC + 1 hodina [ Letní čas ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/