загальне програмування, як часто воно використовується в промисловості


11

Наразі я програмую в академічній обстановці, тому можу використовувати все, що хочу. Я використовую бібліотеку прискорених графіків для кількох речей, і мені цікаво, чи варто вкладати зусилля в розуміння ГП глибше.

Мені цікаво - чи багато загального програмування (GP) використовується в промисловості? Я здогадуюсь, що більшість програмістів набагато комфортніше з OOP або використовують мови, які не підкреслюють і не підтримують GP, так що поза викликом структур / функцій даних STL в C ++, моє враження, що GP використовується не так часто на практиці. Але, перебуваючи поза галуззю, було б приємно почути це від практикуючих.

(коли я це пишу, я бачу, що загальне програмування навіть не є дійсним тегом!)


Розподіл тегів у StackOverflow, ймовірно, набагато корисніший як статистичний доказ, ніж той, що тут. Дивіться stackoverflow.com/questions/tagged/generic-programming , stackoverflow.com/questions/tagged/generics
Péter Török

Відповіді:


7

Мені цікаво - чи багато загального програмування (GP) використовується в промисловості?

Це дійсно широко залежить від контексту команди та проекту.

Наприклад, у відеоіграх часто код є "найпростішим" можливим (і навіть іноді занадто простим), але у великих архітектурах. Це тому, що розробники ігор мають багато проблем з виправленням і не хочуть заважати мета-програмуванню (це окремий дуже абстрактний і важко зрозуміти мову всередині C ++).

У той же час, основні способи використання шаблонів поширені навіть у цих магазинах, і ви можете побачити деякі оптимізації на основі шаблонів у деяких дуже специфічних функціях деяких двигунів.

Але в ігрових розробниках більшість людей просто уникатимуть метапрограмування.

Тепер, з іншого крайнього боку, для деяких дійсно складних або важких додатків для обробки, які не є загальними, потрібні якісь важкі метапрограмування через вимоги до продуктивності та гнучкості (під час компіляції), які не є загальними. Я зараз працюю в одному.

Це не є звичайним явищем, але існує, і деякі сфери (у деяких наукових або вбудованих контекстах, що вводяться в число) потребують того, щоб люди знали багато про метапрограмування або бажають навчитися.

У середині більшість людей просто використовуватиме метапрограмування як "клієнт", а не як "дизайнер". Більшість кодів метапрограмування входить у бібліотеки, оскільки бібліотеки - це інструменти для коду і що краще, ніж бібліотека, яка може адаптуватись до користувацьких типів, з якими ви працювали дотепер?

Boost (http://boost.org) - це набір бібліотек, деякі з яких виготовляються з важкої метапрограмування чорної магії, і використовуються в багатьох магазинах C ++ як "STL ++", розширення STL (і це є). Не кожен магазин використовує його з декількох причин, як сумісність компілятора (деякі бібліотеки прискорення можуть змусити ваш компілятор вибачити за кожен раз, коли він зашкодив вашим почуттям ...) і частіше, тому що деякі розробники не люблять не в змозі зрозуміти як інструмент працює всередині (спробуйте зрозуміти Boost.Spirit ...)

Якими б компаніями ви не працювали, деякі використовуватимуть цю парадигму, а інші менше чи зовсім не заборонятимуть її.

Не існує єдиної думки, оскільки ніхто не має однакових потреб, контексту чи команди.

Але все одно, очевидно, воно використовується. Можливо, запитайте, хто використовує поштовх у своєму списку розсилки, щоб мати більше прикладів у реальному світі?


1
+1 для клієнта проти дизайнера. З мого досвіду, досить небагато розробників розуміють їх реалізації , що не має сенсу створювати новий загальний код в додатку , якщо він не робить велику поліпшення ремонтопридатності. Бібліотеки, призначені для широкого використання, підпадають під цю умову набагато частіше, ніж окремі програми.
Карл Білефельдт

Дякую за детальну відповідь. Я сам шанувальник Boost і розглядаю, чи потрібно копатись у BGL, що вимагає значно більшої кількості знань загальної практики, ніж інші бібліотеки Boost. Ваш коментар про світ розробки ігор досить інтригуючий. Мене дивує подвиг розвитку сучасних ігор і цікаво почути, що вони, мабуть, ізольовані від новіших методологій програмування, а не на передньому плані.
bd1

Ну, розробники ігор керують високим рівнем складності лише завдяки архітектурним концепціям ігор. Додавання мета-інструкцій просто ускладнює все, тому це повинно бути справді виправданим. Інша справа, що багато ігрових розробників працює на консолях, які є дуже специфічним обладнанням з дуже специфічними компіляторами, які не дозволяють зробити все, що намагається зробити прискорене (наприклад, не виняток чи багаторазове успадкування або неправильна робота від документа до укладач (правдива історія)). Отже, є вагомі причини.
Клайм

5

Мені цікаво - чи багато загального програмування (GP) використовується в промисловості?

У полях дуже часто використовується загальне програмування, яке академічно називають параметричним поліморфізмом . У моїй компанії ми використовуємо його здебільшого для створення незалежних редакторів даних, незалежно від їх виду. Вам просто не потрібен так часто, як інші функції, але це, безумовно, особливість, яку я не хотів би пропустити. Ви використовуєте його, коли поведінка відповідає великій кількості типів. Це чітка ознака того, що вам потрібні дженерики, коли ви опинитесь, що ви пишете один і той же код кілька разів для різних типів.

Я здогадуюсь, що більшість програмістів набагато комфортніше з OOP або використовують мови, які не підкреслюють і не підтримують GP, так що поза викликом структур / функцій даних STL в C ++, моє враження, що GP використовується не так часто на практиці.

Принаймні, з мого досвіду, ваша точка зору помилкова. OOP та загальне програмування не є взаємовиключними. Насправді, ви повинні використовувати синергетичні ефекти їх поєднання. Як я вже говорив раніше, причина, по якій ви не бачите, з’являється так часто, як інші методи, тому що вам це не потрібно так часто. Але це сильна особливість мати та значно допомагає зберігати свій код DRY . Які мови насправді не підкреслюють підтримку GP в програмуванні на високому рівні? 3 з 5 мов Top 5 підтримують генеричні файли / шаблони. І PHP динамічно набирається, тому він їм насправді не потрібен. І що?


З точки зору, я не мав на увазі, що OOP і GP - це або /, або вибір. Однак багато проектів, які я бачив, здаються, суто OOP на Java. Я думаю, що новіші версії Java підтримують GP, але яка частка програмістів Java справді використовує цю функціональність? Як я вже говорив, я не працюю в промисловості, і моя перспектива цілком може бути перекошена, і саме тому я задав питання.
bd1

@ bd1: Старіші програми, написані перед підтримкою дженерики, що підтримує Java, або перед тим, як певний набір інструментів підтримував, що версія Java не матиме дженерики, і розробники можуть продовжувати уникати генеричних даних у цьому конкретному проекті, щоб зберегти код узгодженим. Я бачив це, і це залежить від проекту та розробників. Будь-які проекти, які я бачив, розпочаті після того, як підтримка Java generics була широко поширена, як правило, використовує їх часто, коли це доречно.
FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner: Генеріки на Java повністю відрізняються від шаблонів C ++. Java generics - це 100% чистий синтаксичний цукор і не підтримує метапрограмування.
кевін клайн

"OOP та загальне програмування не є взаємовиключними.": Дійсно, обидва є формами поліморфізму, відповідно спеціального та параметричного поліморфізму. Отже, це два різних інструменти для різних видів поліморфізму.
Джорджіо

4

Шаблони C ++ широко використовуються для речей, відмінних від контейнерів - принаймні в моїй проблемній області (кількісне фінансування). Я б навіть зважився сказати, що його іноді використовують занадто часто для цілей, де достатньо простих старих віртуальних функцій (і не збільшить час компіляції настільки сильно).

Люди використовують його, щоб уникнути дублювання коду та для досягнення поліморфізму в компільований час (без віртуального відправлення).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.