Компилатори и редактори за състезанията по програмиране

Преобладаващите езици за програмиране, използвани на състезанията по програмиране у нас, са C и C++, с обяснимо голям превес на C++. Освен от компилатор, програмиращият има нужда и от подходяща „среда за програмиране“ (или „интегрирана среда“), т.е. програма, обединяваща текстов редактор и евентуално някои помощни средства, която, наред с другото, дава възможност програмата да се компилира, свърже и изпълни по удобен начин. Много често вместо такава среда се използва добър текстов редактор, който разполага с повечето от възможностите на „средите“ и може да бъде настроен така, че да компилира с предпочитан компилатор, да изпълнява програмата и евентуално някои други съпътстващи процеса на програмиране действия.

Имаме ли на разположение поне един добър комплект от тези работни инструменти? За съжаление, понастоящем не разполагаме с наистина добро и общоприето решение на този въпрос. Ето някои факти във връзка с това.

  • Dev-C++ е среда за програмиране за Windows, която се използва нашироко у нас именно на състезанията по програмиране и подготовката за тях. Тя обаче е особено неподходяща за целта по ред причини, за някои от които ще стане дума по-долу.
  • DJGPP е комплекс от програми, сред които основна е компилаторът за C и C++ – висококачествен и редовно осъвременяван – определено най-добрият за DOS и за конзолни програми на Windows. Този комплект обаче не включва среда за програмиране или текстов редактор – това програмиращият си набавя допълнително както намери за добре. (Известно време популярна сред учениците, заради приликата ѝ с по-ранните Turbo/Borland среди за DOS, беше програмата-среда RHIDE, която зле се погаждаше с някои варианти на Windows, а и отдавна вече не се поддържа.)
  • 16-разредните компилатори, като този на Borland, не бива да се използват. Те ограничават не само обема на данните в програмата, но и използвания език за програмиране: и C, и C++ се променят с времето, а 16-разредните компилатори са вече доста стари и не отразяват тези промени.
  • Съществуват някои други компилатори (някои само за C) – вж. напр. в [1] и в [2] разделите Freely available compilers. Сред тях тези, които могат да се използват свободно, вкл. безплатно (а други не можем да си позволим) или нямат интегрирана среда, или са неприемливи по други причини (големи, сложни или др.).

Какво ѝ е лошото на Dev-C++?

Тъй като Dev-C++ се превърна през последните няколко години като че в най-масово използваното у нас средство във връзка със състезанията по програмиране, а и изобщо за обучение по C++ в училищата, отделям на тази програма малко повече внимание.

Накратко, тази среда изпълнява основните функции, които са ни нужни, само че го прави не твърде добре, а което е и по-важно – това положение няма да се поправи.

Лесно може да се забележи, че в Dev-C++ има непълно работещи, неправилно работещи и изобщо неработещи части: т. нар. „автоматично допълване“, динамичното търсене и др.

Един от най-съществените недостатъци на тази среда е отсъствието на адекватни средства за работа с конзолни програми, каквито са всички състезателни програми. Както много добре се знае, когато такава програма завършва работа, тутакси изчезва и съдържащата я конзола (прозорец на DOS), с което изчезва и отпечатаният резултат от програмата. Това е научило безброй учители и техните ученици на „мъдрата“ практика да слагат в програмата system("pause") или друго подобно „заклинание“, само и само да не изчезва веднага екранът на DOS. Освен че е напълно излишно, това е не само вредно като практика в обучението на по-малките ученици (те свикват да приемат това извращаване на програмата за необходимо и значи естествено), но и непосредствено им вреди: като предадат програмата си, забравяйки да махнат въпросното „заклинание“, тя се оказва нетестваема и получава нула в класирането.

Запазването на екрана с резултата е само едно от свойствата, нужни за работа с конзолни програми, но има и други – виж следващия раздел. Те също отсъстват от Dev-C++. Изобщо, какво да мислим за авторите на тази „среда“? Ако са толкова небрежни, че не са обърнали внимание на този груб недостатък, колко ли други неща са свършили през пръсти? Защо тогава да разчитаме на такава програма?!

Dev-C++ съдържа кратко ръководство по програмиране на C (забележете, не на C++). Форматът, в който е представено, го прави не твърде удобно за ползване, а и изобщо едва ли именно такъв вид четиво е уместно и очаквано на такова място. По-голям смисъл би имало, ако текстът беше справочник за езика.

Всъщност Dev-C++ е изоставена от авторите си разработка. Разделът Downloads (надолу по страницата) на [3] съобщава, че текущата версия на Dev-C++ е 4.9.9.2 и е „бета“ (т.е. е резултат от незавършена работа). От частта Download на [4] пък научаваме, че тази версия е от февруари 2005 – понастоящем от повече от 4 години. Напълно ясно е, че грешките и недостатъците на тази програма няма никога да бъдат поправени.

Dev-C++ е само интегрирана среда; за компилатор тя разчита на този от MinGW [5] – проект, подобен на DJGPP, но за Windows, а не DOS, и с много по-ограничен обхват от DJGPP. Отново от [3] виждаме, че компилатора, който Dev-C++ използва, е MinGW/gcc, версия 3.4.2. Това е една вече доста стара версия на gcc (справка с [8] показва, че е от септември 2004). Добре е да се има предвид, че и самият проект MinGW е в застой: секцията Download на неговия уебсайт показва, че през 2009 MinGW все още използва gcc 3.4.5, чиято давност е от ноември 2005 (вж. отново [8]).

Този по-стар компилатор има някои проблеми, заради които опитните ученици го избягват. Освен това той не включва някои нововъведения, направени в езика през последните години, и имащи значение за ефективното писане на програми на C++.

Какво ни е нужно?

Какви свойства да търсим у средите и компилаторите, които използваме?

Предвид характера на състезателното програмиране, не е нужно да прибягваме до сложни среди, предназначени за разработване на програми с много компоненти, вкл. състоящи се от множество файлове. Работата с „проекти“ (project management) е по начало ценно свойство, но в нашия случай напълно безполезно. Дори то да е налице, много по-важно за нашите цели е лесно да се създава еднофайлова програма.

Състезателните програми са относително къси, но многократно се променят и особено поправят. Следователно цикълът редактиране-компилиране-поправяне-пускане трябва да може да се извършва лесно, с минимално количество междинни или обслужващи действия. Изобщо, лекотата при употреба е важна, за да може състезателят да посвещава и времето, и вниманието си само на решаваните задачи, а не на борба със среди и компилатори.

Тъй като състезателните програми са и конзолни и с тях се взаимодейства чрез стандартните входен и изходен канали, пускането на програма трябва да е свързано с удобен достъп до конзола (команден интерпретатор на операционната система). Необходимо е и лесно да може да се пуска програма с пренасочване на входа (източник на тестови данни) и изхода ѝ (получавания резултат). Последното, разбира се, винаги може да стане в самостоятелен конзолен прозорец, но тук става дума доколко дадената „среда“ може да взаимодейства с такъв прозорец, да позволява пренасочванията и да „участва“ в тях – т.е. да осигурява непосредствен и удобен достъп до входните данни за програмата и получавания от нея резултат.

Във връзка с горното е удобно, ако средата за работа дава възможност едновременно да се показват няколко файла, напр. текста на програмата и примерни вход и изход, дори няколко такива двойки.

Добре е да има справочна документация по езика за програмиране, интегрирана в средата или поне с някаква степен на взаимодействие с нея. Това позволява да се правят контекстни справки, бързо попълване на фрагменти по шаблон и др. под.

Добре е също ако съответните средства се използват масово по света. Това обикновено е свидетелство за висока надеждност: при много и редовни потребители грешките се забелязват и или биват поправени, или водят до отлив в употребата. В света на свободния софтуер масовата употреба означава и редовно и често осъвременяване.

Тук е мястото да направя следната бележка. В езика C++ предстои да се случат цял ред важни добавки, които значително ще повлияят на стила на програмиране. Те са вече почти окончателно уточнени и се очаква да бъдат официално приети през 2009 г. Част от тях са вече на разположение чрез някои компилатори и е ясно, че и останалите добавки ще бъдат реализирани възможно най-бързо. За gcc този процес започна със серията 4 на компилатора. Ползването на тези нови езикови средства е сериозно предимство. За да го имаме трябва да се ориентираме към използване на компилатори, които биват често обновявани. Особено внимание е нужно в случаите, когато компилаторът не е самостоятелен, а част от някаква среда за програмиране, понеже тогава промените не стават бързо, а може и изобщо да не настъпват.

За този, на когото се налага да прави многократно, във времето и като брой компютри, инсталиране на такъв софтуер, е най-добре, ако инсталиране в истинския смисъл няма, а е достатъчно само копиране на програмите. Със сигурност именно по този начин програмите влизат в употреба най-лесно и без спънки. Така отпадат и проблеми като напр. с регистратурата (registry) или други места в Windows, където често остават и пречат следи от уж „деинсталирани“ програми. Точно такъв е случаят с Dev-C++, за което ще стане дума малко по-нататък.

Размерът на компилатор или среда за програмиране в днешно време обикновено не е съществен, но все пак малките програми като правило по-бързо и лесно се разполагат където е нужно, преместват и изтриват. Така че за администратора на състезателни или учебни компютри и това може да бъде от значение.

Накрая, никак не е излишно, ако използваният софтуер не е специфичен за дадена операционна система, а работи еднообразно поне, да речем, в Windows XP и Linux. У нас и двете системи се използват вече достатъчно широко и еднообразието в това отношение, където е възможно, е от полза. Освен това, да не забравяме, че макар на училищните компютри да има обикновено Windows, на международните олимпиади по програмиране се използва само Linux.

Алтернативи

Трябва да се признае, че описаното незадоволително положение с използваните средства за програмиране е резултат повече на инерция от наша страна, отколкото на липса на възможности. (Ако ползвате, да речем, Dev-C++ и се запитате „защо?“, отговорът най-вероятно е „защото го прави някой друг“.) Съществуват добри алтернативи. По-долу предлагам няколко такива.

Предложенията ми са на основата на изследване на наличните в момента възможности: компилатори, евентуално заедно със среди за програмиране, и текстови редактори, които могат да се адаптират така че да играят ролята на такива среди. От наличното съм подбрал такива решения, които във възможно най-голяма степен отговарят на потребностите ни, както ги формулирах по-горе. Веднага трябва да кажа, че не намирам едно единствено решение, което би удовлетворило всекиго, затова и предлагам няколко. Някои от тях не се разпространяват от авторите им в непосредствено удобен за нас вид, затова се наложи да свърша известна работа върху тях и ги предлагам с изменения, както ще стане ясно по-долу.

Съществуват не малко текстови редактори за Windows, които могат да се нагласят да „викат“ компилатор и изобщо друга програма, имат синтактично оцветяване за езици за програмиране, някои предоставят и псевдоконзола – подпрозорец, който играе роля на конзола. Същото – и в по-голяма степен – се отнася и за редактори в Linux. Поради споменатите съображения предпочетох да разгледам само такива от тях, които работят и в двете операционни системи.

И така, ето предложенията.

Code::Blocks

Това е интегрирана среда, която работи с компилатора gcc. Включва дебъгер (както при Dev-C++, това е вградено копие на конзолния gdb от GNU, но снабдено с визуален интерфейс).

Този избор е добър за онези, които са свикнали с начина на работа в Dev-C++ и др. подобни – това е среда от същия тип, но за разлика от Dev-C++ всичко предвидено в нея работи както се очаква, а има и по-богата функционалност. По тази среда се работи интензивно и тя редовно се обновява. С Code::Blocks могат да се пишат прозоречни програми, независещи от операционната система (използвайки библиотеката WxWidgets), но за нас тази възможност е без значение.

Сериозен недостатък на Code::Blocks за Windows е този, че и тя използва компилатора MinGW/gcc. Версията му (3.4.5) е само малко по-нова от тази в Dev-C++. Докато развитието на MinGW/gcc е в застой – а това е от дълго време и няма признаци да се промени – и Code::Blocks за Windows е обречена на същото (вж. бележката ми по-горе за текущите промени в C++), макар собствено средата да се усъвършенства. За Linux този проблем не стои – там Code::Blocks използва текущата версия на gcc, която като правило е актуална.

Подготвяне за работа и използване

На уебстраницата [6] ще намерите инсталационни файлове, но настоятелно ви съветвам вместо тях да ползвате подготвения от мен архив [19]. Това ще ви спести необходимостта от някои тривиални, но досадни настройки, а ще избегнете и евентуално неправилно конфигуриране в някои случаи.

Инсталаторът на Code::Blocks е устроен така, че се стреми да използва, вместо своята, вече налични версии на MinGW/gcc, ако изглежда, че има такива – което е така напр. ако имате (или дори само сте имали!) Dev-C++. Това се променя лесно, но са нужни допълнителни действия след инсталацията. Затова просто не ползвайте програмата-инсталатор, а архивираната, вече настроена инсталация, още повече, ако ще слагате Code::Blocks на повече от един компютър.

Разархивирайте в предварително създадена директория – напр. c:\codeblocks, но може и друга. Други подготвителни действия не са нужни. Самата програма се стартира от файла codeblocks.exe, който се намира в избраната от вас директория.

Колкото до използването на средата, то лесно се научава и с него лесно се свиква, затова няма да го обсъждам повече. Разгледайте съдържанието на менютата и обърнете внимание кое от него ви трябва. Ако намерите за добре, използвайте настройките за нагаждане на средата според предпочитанията си.

DJGPP/gcc

При избор на компилатор това засега е най-добрата възможност. Може да е парадоксално, но gcc за DOS е по-добър от gcc за Windows. Както вече стана ясно, последният е всъщност част от проекта MinGW, а той не се развива никак интензивно. DJGPP [9], от друга страна, се развива благополучно, и по-специално gcc в него се обновява със същата честота както оригиналът на този компилатор в Linux.

Подготвяне за работа и използване

Съществуват различни начини да се сдобиете с работеща среда DJGPP, но ви препоръчвам да ползвате архива [12], който съдържа подходящо събран от мен, актуален и проверено работоспособен комплект. Наред с другото, така ще ви е малко по-удобно да ползвате и SciTE и Vim, за които става дума по-долу.

Комплектът в [12] е „почти минимален“: освен компилатора (версия 4.3.2), той съдържа само справочна документация във формат info (чете се в конзолен прозорец с програмата info, която също е в архива).

По принцип съдържанието на архива може да се разположи в произволна директория, да речем c:\djgpp. Създайте такава директория и разархивирайте в нея.

След разархивирането е нужно да се установят стойностите на някои системни променливи на DOS/Windows: прочетете подробностите за това в [13]. В [14] пък е описано как с DJGPP/gcc може да се компилира програма на C или C++.

Файлът djgpp-intro.html, който съдържа препратките [13] и [14], се намира и в инсталационния архив [12], така че можете да правите справки и непосредствено там. Този файл съдържа и друга полезна информация.

Понеже DJGPP/gcc е само компилатор, отделно трябва да подберем текстов редактор, с който като минимум удобно да подготвяме текста на програмата, а в по-добрия случай използваме и като интегрирана с компилатора среда. Следват два такива варианта.

DJGPP/gcc + SciTE

SciTE [10] е малък по обем, но богат на възможности текстов редактор, който чрез множество от конфигурационни файлове може да се пригажда като среда за програмиране на различни езици. Поведението на редактора дори може да се програмира – и по този начин адаптира за всякакви нужди – с помощта на езика Lua, интерпретатор за който е вграден в SciTE.

Подготвяне за работа и използване

За да се възползвате най-удобно от редактора и особено от съчетанието между него и компилатора DJGPP/gcc, ползвайте не архив от уебсайта на SciTE, а [15], който съм подготвил специално за целта. Разархивирайте го в c:\scite. Никакви допълнителни настройки не са нужни.

Ако освен редактора е налице и DJGPP/gcc, двете образуват среда за програмиране за C и C++. Използването на редактора е много просто, но за удобство го описвам, заедно с особеностите му като „среда“, в [16].

Ако DJGPP/gcc и SciTE са разположени както го описвам тук, SciTE може да бъде стартиран от коя да е текуща за конзолен (DOS) прозорец директория така, че тя да остава текуща и за редактора. Това става с повикване от вида
        scite.lnk  име-на-файл
или само
        scite.lnk
(Файлът SciTE.lnk се намира в основната директория на DJGPP, която при правилно инсталиране е сред активните, т.е. програмите в нея могат да бъдат стартирани. Той е настроен така, че да „сочи“ c:\scite\SciTE.exe и има зададена работна директория .\, т.е. текущата, която и да е тя.)

Ако инсталирате SciTE другаде, за да използвате горната възможност ще трябва съответно да промените съдържанието на SciTE.lnk посредством „Properties“ на този файл.

Разбира се, редакторът може да бъде стартиран и другояче, напр. непосредствено по име – стига да се намира в активна директория, или чрез щракане с мишката върху него или върху препратка (shortcut) към него.

DJGPP/gcc + Vim

Vim [11] е много развит и широко използван текстов редактор. Особено разпространен и харесван е сред програмисти.

Подготвяне за работа и използване

За целите, за които го представям тук, настоятелно препоръчвам да ползвате не стандартен инсталатор или архив от уебсайта на Vim, а архива [17], който съм подготвил специално за целта. Разархивирайте в директория c:\vim. Никакви допълнителни настройки не са нужни.

Този архив съдържа не само необходимото настройване, за да може да използвате компилатора DJGPP/gcc непосредствено от редактора, но и някои други полезни настройки, добавки (сред тях – изчерпателна документация за C и STL) и дори програма (скрипт), която именно осигурява поведение на Vim като интегрирана среда за програмиране на C и C++. Всъщност написах този скрипт специално с цел да пригодя Vim възможно най-удобно за използване на състезания и тренировки за тях.

Vim е редактор „от тежка категория“ – много богат функционално и сложен инструмент. Работата с него съществено се отличава от тази с другите редактори. На начинаещите препоръчвам да го стартират в т.нар. „лесен режим“ (вж. по-долу), в който особеностите, но и повечето от достойнствата му отсъстват, той се използва подобно на другите редактори и е не по-сложен за употреба от Notepad. В този случай действията с редактора се задават изцяло с помощта на командните му менюта.

Използването на Vim като среда за програмиране описвам в [18]. Там давам и друга информация за редактора, вкл. начални сведения, които биха позволили на интересуващите се да започнат да го ползват по-пълноценно.

Ако DJGPP/gcc и Vim са разположени както го описвам тук, Vim може да бъде стартиран от коя да е текуща за конзолен (DOS) прозорец директория така, че тя да остава текуща и за редактора. Това става с повикване от вида
        gvim-easy.lnk  име-на-файл
или само
        gvim-easy.lnk
за „лесния режим“ или
        gvim.lnk  име-на-файл
или само
        gvim.lnk
за основния. (Файловете gvim-easy.lnk и gvim.lnk се намират в основната директория на DJGPP, която при правилно инсталиране е сред активните, т.е. програмите в нея могат да бъдат стартирани. И двата файла са настроени така, че да „сочат“ c:\vim\vim73\gvim.exe и имат зададена работна директория .\, т.е. текущата, която и да е тя. gvim-easy.lnk се отличава от gvim.lnk единствено по това, че стартира c:\vim\vim73\gvim.exe -y, т.е. при стартиране на редактора задава ключа -y.)

Ако инсталирате Vim другаде, за да използвате горната възможност ще трябва съответно да промените съдържанието на двата файла .lnk посредством техните „Properties“.

Разбира се, Vim може да бъде стартиран и другояче, напр. непосредствено по име – стига да се намира в активна директория, или чрез щракане с мишката върху него или върху препратка (shortcut) към него. Ако е нужно, направете си такива за gvim и gvim -y на работния плот (desktop).

Нека отбележа, че сред изброените тук, а и много други, Vim е единственият текстов редактор, чрез който няколко файла (напр. програма, входни данни за нея и резултат) могат да се виждат едновременно на екрана, в един работен сеанс на редактора и без единия да закрива всички останали.

Кое да изберем?

Не е трудно да имаме на разположение всички предложени варианти и всъщност смятам, че е добре да бъде именно така, защото заедно те дават достатъчно разнообразен избор, а във всяка група ще се намерят хора с различни предпочитания. Струва ми се, че сред посоченото ще се намери по нещо приемливо за всекиго.

Все пак, кое за кого е най-подходящо? Ето в резюме как изглежда отговорът за мен.

Code::Blocks
Тази среда е за онзи, който намира Dev-C++ удобна за работа и би искал да ползва нещо подобно, но по-добро, или за онзи, който държи да има дебъгер (другите „среди“ нямат).
DJGPP/gcc + SciTE
Подходящо е за всекиго, стига да не държи да има дебъгер. Поради простотата на използване би трябвало да е особено подходящо за малките. Лично аз нямам наблюдения за малки ученици, но на големите, на които водя занятия, SciTE изглежда допада повече от Code::Blocks.
DJGPP/gcc + Vim
За „лесния режим“ важи същото като за горното. Пълният режим е за хора с някаква опитност (със сигурност не за много малки ученици), но такава се добива бързо. И колкото по-скоро започне човек да овладява Vim, толкова по-добре. На международните олимпиади той е сред основните средства давани на разположение, и при това без каквито и да е допълнения.
И като редактор, и като интегрирана среда Vim в този комплект превъзхожда всички други решения. gcc + Vim е и моят личен избор на работна среда, и в Linux, и в DOS/Windows.
други варианти
Възможно е да се ползват горните варианти комбинирано. Да речем, за дебъгване, ако се наложи – Code::Blocks, а някой от другите за основната работа. Не мога да преценя доколко това е сполучливо, но знам, че някои го практикуват. В този случай обаче трябва да се има предвид фактическата разлика между „разбираните“ от различните версии на компилатора езици.

Препратки

  1. Препратки в Интернет към свободнодостъпни ресурси, свързани със C
  2. Препратки в Интернет към свободнодостъпни ресурси, свързани със C++
  3. Главна уебстраница на Dev-C++
  4. Dev-C++: уебстраница за разпространение на програмата
  5. Уебстраница на MinGW
  6. Code::Blocks: интегрирана среда за програмиране на C, C++, D и Python
  7. Главна уебстраница на gcc
  8. Уебстраница на серията gcc 3.4
  9. Главна уебстраница на DJGPP
  10. Главна страница на редактора SciTE
  11. Главна страница на редактора Vim
  12. Архивирана, готова за използване „инсталация“ на DJGPP
  13. Настройване за работа на DJGPP
  14. Указания за компилиране от конзолата с DJGPP/gcc
  15. Архивирана „инсталация“ на SciTE за Windows, подходящо конфигурирана за програмиране на C и C++
  16. Сведения за използване на SciTE
  17. Архивирана „инсталация“ на Vim за Windows, „опакована“ с приставки и подходящо конфигурирана за програмиране на C и C++
  18. Сведения за използване на Vim
  19. Архивирана „инсталация“ на Code::Blocks за Windows, подходящо конфигурирана

—Б.Б.