Особливості C ++ "цілої команди"?


16

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

Протиінтуїтивно, важкою частиною винятків кодування є не явні кидки та уловлювання. Справді складною частиною використання винятків є написання всього втручається коду таким чином, щоб довільний виняток міг поширюватися зі свого сайту викидання до його обробника, прибуваючи безпечно і не пошкоджуючи інші частини програми по дорозі.

Оскільки навіть newвикиди винятків, кожна функція повинна забезпечувати основну безпеку винятків - якщо тільки вона не викликає функції, які гарантують викидання не виняток - якщо ви не відключаєте винятки взагалі у всьому своєму проекті .

Отже, винятки - це "ціла програма" або "ціла команда", оскільки їх повинні розуміти всі в команді, яка їх використовує. Але не всі функції C ++ є такими, наскільки я знаю.

Можливим прикладом є те, що якщо я не отримаю шаблони, але я не користуюся ними, я все одно зможу написати правильний C ++ - чи не буду ?. Я навіть можу зателефонувати sortна масив цілих чисел і насолоджуватися його дивовижною перевагою швидкості wrt. C qsort(тому, що не викликається функція покажчика), не ризикуючи помилками - чи ні? Здається, шаблони - це не «ціла команда».

Чи є інші функції C ++, які впливають на код, не використовуючи їх безпосередньо, і, отже, є "цілою командою"? Мене особливо цікавлять функції, яких немає у C.

Оновлення : Я особливо шукаю функції, де немає ознак, встановлених мовою, про які вам потрібно знати. Перша відповідь, яку я згадав про коректність, яка також є цілою командою, тому всі повинні дізнатися про це; однак, AFAICS це вплине на вас лише в тому випадку, якщо ви викликаєте функцію, яка позначена const, і компілятор не дозволить вам викликати її по об'єктах, які не мають const, тому ви отримаєте щось для google. За винятком, ви навіть цього не розумієте; крім того, вони завжди використовуються, як тільки ви використовуєте new, отже, винятки є "підступнішими". Оскільки я не можу охарактеризувати це як об'єктивно, я буду вдячний за будь-яку особливість команди.

Оновлення 2 : замість функції C ++ я повинен був написати щось на кшталт "C ++ - специфічна функція", щоб виключити такі речі, як багатопотокова редакція, які застосовуються до великої кількості основних програмних мов.

Додаток: Чому це питання об'єктивне (якщо вам цікаво)

C ++ - це складна мова, тому багато проектів чи посібники з кодування намагаються вибрати "прості" функції C ++, і багато людей намагаються включити або виключити деякі з них, відповідно до переважно суб'єктивних критеріїв. Питання щодо цього регулярно закриваються регулярно тут на SO.

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

Чи варто використовувати функції "всієї команди", чи це відповідна концепція, може бути суб'єктивним - але це означає лише, що важливість цього питання є суб'єктивною, як завжди.

Відповіді:


11

Я б висунув одночасність як "цілу команду".

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


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

@Blaisorblade - C ++ 11 представив свою власну бібліотеку для різьблення, так що зараз вона є частиною C ++.
Майкл Коне

@MichaelKohne: Я не стверджував, що C ++ не підтримує багатопотоковість. Я сказав, що потоки не є C ++, оскільки багато інших мов їх мають. Я щойно зазначив, що описані проблеми стосуються потоків як інтерфейсу для одночасності.
Blaisorblade

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

Це нагадує про непогане спілкування з колегою, що сталося років тому. Співробітник запитав іншого співробітника: чи безпечна ця (деяка функція) нитка? Інший колега відповів "так". Потім співробітник, який запитав, продовжував використовувати його з декількох потоків і отримав несподівані результати (він не вийшов з ладу, але на одному об'єкті було застосовано кілька операцій). Виявилося, що колега, який запитував, не мав розумової моделі того, що означає "безпечний для потоків", і неправильно сприйняв відповідь як "я можу робити все, що хочу".
rwong

10

Очевидна відповідь - constправильність: оскільки const/ volatileкваліфікація заразна, після того, як одна частина коду почала її використовувати, кожен (прямо чи опосередковано) код виклику також повинен бути constправильним або constчітко відкинути його .

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


2
Крім того, const-правильність прозора: мова йде лише про тип, який ви надаєте функції (який завжди видно), і компілятор буде кричати на вас, якщо ви помилитесь. Я думав про більш непрозорі речі, де ти поняття не маєш, поки не пізно (і навіть тоді це буде важко зрозуміти). Але Ваша відповідь у будь-якому випадку є цікавою, тому її схвалюють.
Blaisorblade

10

Покажчики.

  • Чи вказує вказівник на пам'ять на стеці?
  • Чи вказує вказівник на пам'ять на купі?
  • Чи вказує вказівник на один об’єкт?
  • Чи вказує вказівник на масив?
  • Чи вказує вказівник на місцеположення в середині масиву?
  • Чи покажчик дійсний?
  • Чи покажчик заблукав?
  • Який код "володіє" вказівником?
  • Чи повинен посилатися об'єкт вручну розміщуватися? Якщо так, як?

1
+1 спеціально через питання про право власності на покажчик. Без розумних покажчиків право власності дійсно поширюється у всій команді.
JKor

3

Інша можливість - перевантаження оператора. Після того, як одна частини кодового починає возитися з перевантаженими операторами кожен прагне розпочати другий гадати тільки що саме будь-який даний об'єкта вони працюють як на самому ділі роблять. Він не поширює явно через кодову базу як винятки та правильність const, але це, безумовно, щось, що може почати викликати проблеми, якщо вся команда не на одній сторінці про те, коли, як і навіщо її використовувати.


1

Єдина, крім правильності const (видно вище), що спадає на думку, - це поточне (англ.) Стан. Якщо ви пишете код C ++, де ви використовуєте об'єкти та суб'єкти та ієрархії об’єктів, то, зрештою, ви захочете відправити або отримати дані оператору програми / до нього. Ви можете написати прості потокові операції, які будуть компілюватись і будуть семантично правильними ...

std::ostream& operator<< (std::ostream&, MyClass const&) {...}
std::istream& operator>> (std::istream&, MyClass&) {...}

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

Попросити члена в глибині своєї ієрархії класів, що це string? Здивуйте, клієнт краще надсилає жодне слово, або ще. Чи є кілька номерів, які ви хочете серіалізувати? Вам краще перевірити, зберегти та відновити прапорці потоку на кожній глибині виклику функції, адже ви ніколи не знаєте, хто той ідіот, який просто встановив свій потік на восьмеричний вихід, перш ніж викликати вашу функцію. Або ще гірше - хто щойно назвав щось подібне setfillі setwтаким чином порушив форматування вводу / виводу вашого першого - і лише ваших перших - інтегральних членів, оскільки ці стани не поширюються . О, і не давайте запитувати про потоки та інтернаціоналізацію.

Там немає ніякого попередження на мові взагалі , що ви потокові правильний шлях або неправильний шлях, або навіть потоковий взагалі . Запитав код клієнта для передачі потоку для запису резервного копіювання даних? У вас насправді немає способу знати, на який вказує потік /dev/null. ( З іншого боку, ви можете вимагати неймовірних швидкостей резервного копіювання та швидкості стиснення таким чином! )

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