Как перестать программировать на С++ в Паскаль стиле?

← →
Игорь Шевченко © (2009-05-12 15:03) [40]

Alkid © (12.05.09 14:56) [38]

Вот о степени "хорошести" программиста как раз и можно судить по высказываниям типа "foo есть безусловное зло и чем скорее сдохнут те, кто его использует, тем скорее мир станет светлее и чище".

> ИМХО, если программист хороший, то "программист" и "на дельфи"
> у него идут раздельно

Не факт. Прежде чем погрузиться в особенности конструкций конкретного языка, а порой и в особенности парадигм, навязываемых этим языком, хороший программиста на одном языке будет посредственным программистом на другом. Собственно и заглавный пост в ветке - об этом.

А просто "хороший" программист, безотносительно языка, это, извини, сильно смахивает на сферического коня.

← →
Alkid © (2009-05-12 15:11) [41]

> Юрий Зотов © (12.05.09 15:01) [39]
>
> > Alkid © (12.05.09 14:56) [38]
>
> Так на какое же "на ..." она должна идти? Можно с этого
> места чуть подробнее?
> :o)

Только без пошлостей :)
Ну, там "..." - это метасинтаксическая переменная, определённая на множестве языков и технологий разработки :)

← →
Fast (2009-05-12 15:12) [42]

Что по мне, так после
> Юрий Зотов © (11.05.09 19:17) [6]
> Есть всего два стиля программирования - плохой и хороший.

все остальное (то есть все "впрыски" в эту ветку) своего рода какие-то испражнения
:)

← →
Alkid © (2009-05-12 15:24) [43]

> Игорь Шевченко © (12.05.09 15:03) [40]
> Вот о степени "хорошести" программиста как раз и можно судить
> по высказываниям типа "foo есть безусловное зло и чем скорее
> сдохнут те, кто его использует, тем скорее мир станет светлее
> и чище".

М.б. Вот у меня щас начальник есть. Очень умный мужик, но имеет склонность свои мнения выражать в крайне категоричной форме, даже тогда, когда речь идёт о вещах неоднозначных или заведомо неверных. Не сказать. что он плохой программист, но работать с ним иногда бывает трудно.

> Не факт. Прежде чем погрузиться в особенности конструкций
> конкретного языка, а порой и в особенности парадигм, навязываемых
> этим языком, хороший программиста на одном языке будет посредственным
> программистом на другом. Собственно и заглавный пост в ветке
> - об этом.

С этим согласен.

> А просто "хороший" программист, безотносительно языка, это,
> извини, сильно смахивает на сферического коня.

С этим тоже, в принципе, согласен, но с оговоркой, всё же.

Разные языки, технологии и парадигмы дают разные взгляды на программирование. Обобщение этих разных подходов даёт фундамент понимания программирования на более высоком уровне, чем просто применение тех или иных инструментов. При достаточной степени прокачанности это даёт возможность видеть принципиальные особенности языков и следующие из них design implications (по-русски знаю, как сказать, что бы передать "аромат" этого термина), даже не зная эти языки в деталях.

← →
oxffff © (2009-05-12 15:33) [44]

> Игорь Шевченко © (12.05.09 15:03) [40]
> Alkid © (12.05.09 14:56) [38]
>
> Вот о степени "хорошести" программиста как раз и можно судить
> по высказываниям типа "foo есть безусловное зло и чем скорее
> сдохнут те, кто его использует, тем скорее мир станет светлее
> и чище".

Вам вопросы в таком случае

1. В чем преимущество ? оператора перед обычным IF
2. Почему templates трансформируют в concepts по вашему

← →
KSergey © (2009-05-12 15:42) [45]

> oxffff © (12.05.09 15:33) [44]
> 1. В чем преимущество ? оператора перед обычным IF

Кратче.

> oxffff © (12.05.09 15:33) [44]
> 2. Почему templates трансформируют в concepts по вашему

Ну так и "алгоритмы+структуры данных=программы" уже "устаревшая" парадигма, и что? все меняется, мысля движется.

А вообще мне лично не очень понятно как эти вопросы связаны с приведенной цитатой.

← →
Игорь Шевченко © (2009-05-12 15:43) [46]

Alkid © (12.05.09 15:24) [43]

> design implications (по-русски знаю, как сказать, что бы
> передать "аромат" этого термина)

Я по-английски понимаю, спасибо.

> Разные языки, технологии и парадигмы дают разные взгляды
> на программирование. Обобщение этих разных подходов даёт
> фундамент понимания программирования на более высоком уровне,
> чем просто применение тех или иных инструментов

А что есть "программирование на более высоком уровне" ?
Вот если взять тот же MS - у него технологий, чтобы засорить мозги среднестатистическому программисту было придумано более чем достаточно. Возвращаясь к парадигмам - парадигмы на prolog и парадигмы на ассемблере обобщить как-то, на мой взгляд, не очень легко :) - какой тут может быть фундамент, я не совсем понимаю.

Кроме всего прочего, языков, парадигм и технологий за ~60 лет существования программирования было придумано немало, а придумывается еще больше. Все эти придумывания в основном преследовали и преследуют одну цель - управление сложностью решаемых проблем, но управляли они этой сложностью по-разному. Я несильно вижу смысл забивания головы программиста всяческими особенностями языков парадигм и технологий, на мой взгляд, кроме мешанины в голове это ни к чему не приведет и фундамент вряд ли построится...

← →
Игорь Шевченко © (2009-05-12 15:45) [47]

oxffff © (12.05.09 15:33) [44]

> 1. В чем преимущество ? оператора перед обычным IF

Даже комментировать не хочу.

> 2. Почему templates трансформируют в concepts по вашему

Не понял вопроса

← →
oxffff © (2009-05-12 15:48) [48]

> KSergey © (12.05.09 15:42) [45]
> > oxffff © (12.05.09 15:33) [44]
> > 1. В чем преимущество ? оператора перед обычным IF
>
> Кратче.

Мне как раз этот ответ Ваш и нужен был.
Зачем перегружать язык возможностью сделать что-то идентично двумя разными формами записи. Причем учитывая, что одна из этих форм записи небезопасно с точки зрения читабельности кода.
Зачем?

← →
oxffff © (2009-05-12 15:54) [49]

> Игорь Шевченко © (12.05.09 15:45) [47]
> oxffff © (12.05.09 15:33) [44]
>
>
> > 1. В чем преимущество ? оператора перед обычным IF
>
>
> Даже комментировать не хочу.

Я спрашию потому, что в своей практике не использовал его. Поэтому прошу снизойти и пояснить его преимущество по вашему кроме краткости.
В свою очередь прочитал
C++ Language Reference Conditional Operator: ? :
и других преимуществ не увидел.

← →
Alkid © (2009-05-12 15:55) [50]

> oxffff © (12.05.09 15:33) [44]
>
> Вам вопросы в таком случае
> 1. В чем преимущество ? оператора перед обычным IF

Тернарный оператор представляет собой выражение, в то время как обычный if - statement. В этом смысле они не взаимозаменяемые.

> 2. Почему templates трансформируют в concepts по вашему

Они их не трансформируют шаблоны в concepts, они консепты их добавляют к шаблонам. Мотивация - шаг в сторону design by contract, к декларативности. Шаблоны дают много свободы в compile-time (в частности, реализуют compile-time duck typing), но эта свобода оказалась не всегда полезна.

← →
oxffff © (2009-05-12 16:00) [51]

> > 2. Почему templates трансформируют в concepts по вашему
>
>
> Не понял вопроса

В новом стандарте планируют ввести Concepts - Templates with constraints.
Не кажется ли вам это есть стремление сделать язык более безопасным как с точки зрения type safety, так и с точки зрения readability?
То есть стремления сделать язык в какой степени более user friendly.

← →
AndreyV © (2009-05-12 16:02) [52]

> [48] oxffff © (12.05.09 15:48)
> Зачем перегружать язык возможностью сделать что-то идентично
> двумя разными формами записи.

Да совсем не идентично.

← →
Alkid © (2009-05-12 16:07) [53]

> Игорь Шевченко © (12.05.09 15:43) [46]
> А что есть "программирование на более высоком уровне" ?

Это понимание тех теоретических основ, выражением которых являются конкретные механизмы или технологии.

> Вот если взять тот же MS - у него технологий, чтобы засорить
> мозги среднестатистическому программисту было придумано
> более чем достаточно.

Ну, на MS зацикливаться не стоит. Хотя, скажем прямо, они сейчас разрабатывают очень интересные штуки. Например, только сегодня увидел, MS Axum - прототип языка, основанного на actor model.

> Возвращаясь к парадигмам - парадигмы на prolog и парадигмы
> на ассемблере обобщить как-то, на мой взгляд, не очень легко
> :) - какой тут может быть фундамент, я не совсем понимаю.

Очень просто - понимание того, что есть императивные языки и есть декларативные языки, какие у них есть свойства, достоинства и недостатки. Если человек понимает, что есть что, то в его картину мира прекрасно впишется и ассемблер и пролог. Если же он всю жизнь кроме ассемблера ничего не знал, ему Пролог покажется каббалистикой какой-то. Это парадокс Блаба.

> Кроме всего прочего, языков, парадигм и технологий за ~60
> лет существования программирования было придумано немало,
> а придумывается еще больше. Все эти придумывания в основном
> преследовали и преследуют одну цель - управление сложностью
> решаемых проблем, но управляли они этой сложностью по-разному.
> Я несильно вижу смысл забивания головы программиста всяческими
> особенностями языков парадигм и технологий, на мой взгляд,
> кроме мешанины в голове это ни к чему не приведет и фундамент
> вряд ли построится...

На самом деле за последние 60 лет ПРИНЦИПИАЛЬНО нового мало придумано и эти вещи прекрасно в голове укладываются. Вся та шелуха, которой сейчас много развелось, представляет собой лишь переупаковку основополагающих вещей в разных конфигурациях и под разными маркетинговыми соусами. Я сейчас навскидку не могу вспомнить чего-нибудь, что преподносилось с большой помпой в Джаве или С#, что было бы чем-то действительно ПРИНЦИПИАЛЬНО новым.

← →
oxffff © (2009-05-12 16:08) [54]

> Alkid © (12.05.09 15:55) [50]
>
> > oxffff © (12.05.09 15:33) [44]
> >
> > Вам вопросы в таком случае
> > 1. В чем преимущество ? оператора перед обычным IF
>
> Тернарный оператор представляет собой выражение, в то время
> как обычный if - statement. В этом смысле они не взаимозаменяемые.
>

Сути это не меняет. С точки зрения потока операций процессора это должен быть идентичный поток.

> > 2. Почему templates трансформируют в concepts по вашему
>
> Они их не трансформируют шаблоны в concepts, они консепты
> их добавляют к шаблонам. Мотивация - шаг в сторону design
> by contract, к декларативности. Шаблоны дают много свободы
> в compile-time (в частности, реализуют compile-time duck
> typing), но эта свобода оказалась не всегда полезна.

И в том и в другом случае ты не сможешь сделать над типом больше чем он тебе позволяет. Поэтому свободу это не ограничет. А вот указания место затыка для параметризованном классе укажет точно. Насколько я понял это основное их назначение.

← →
oxffff © (2009-05-12 16:10) [55]

> AndreyV © (12.05.09 16:02) [52]
> > [48] oxffff © (12.05.09 15:48)
> > Зачем перегружать язык возможностью сделать что-то идентично
>
> > двумя разными формами записи.
>
> Да совсем не идентично.

С точки зрения инструкций процессора?

← →
KSergey © (2009-05-12 16:18) [56]

> oxffff © (12.05.09 16:08) [54]
> С точки зрения потока операций процессора это должен быть идентичный поток.

И что? мне глубоко чихать на головную боль процессора. Меня своя гораздо более интересует.

А вообще - я бы попросил отставить менторские тон и снизойти до объяснения мне чего ж вы сказать-то хотите? а то, чую, до сути этих наводящих вопросов я не доживу.

← →
Игорь Шевченко © (2009-05-12 16:19) [57]

oxffff © (12.05.09 16:00) [51]

> В новом стандарте планируют ввести Concepts - Templates
> with constraints.
> Не кажется ли вам это есть стремление сделать язык более
> безопасным как с точки зрения type safety, так и с точки
> зрения readability?
> То есть стремления сделать язык в какой степени более user
> friendly.

В свое время на конференции SEC-R 2005 некий докладчик читал некий доклад. И все бы ничего, но существительные и глаголы в его докладе были транскрипцией с английского (ему приходилось говорить, а не писать) и понять его было довольно сложно. Я до сих пор жалею, что в материалах конференции не было текста этого доклала - как образец того, чего делать не надо.

Поэтому просьба - давай то же самое, только по-русски.

← →
palva © (2009-05-12 16:21) [58]

> Зачем?

Если серьезно, то конструкции ++, ?:, когда они появились, естественно были непривычными и поэтому нечитабельными. Но они позволяли создать более простой компилятор, такие конструкции гораздо легче оптимизировались, чем традиционная запись. В операторе a[<выражение>] = b ? x : y; код для вычисления <выражения> строится только один раз. А если записать это традиционным способом, то оптимизатор должен еще догадаться, что это одно и то же выражение, невзирая на то, что программист мог записать эти выражения немного по-разному. Если же выражение достаточно разветвленное, то и читабельность становится проблемной. Программист, читая традиционную запись и выверяя код в поисках багов, вынужден будет проверять идентичны ли эти записи.

Теперь же эта конструкция прижилась в очень многих языках, и уже не для потребностей оптимизации, а просто потому, что для подавляющего числа программистов мира она стала привычной. Фортран бейсик и паскаль - единственные промышленные языки, где ее нет. Соответственно и неудобства при ее чтении испытывают только та часть программистов, которая дальше этих языков не пошла. А таких очень и очень мало.

То же можно сказать и про конструкцию ++.

← →
Alkid © (2009-05-12 16:22) [59]

> oxffff © (12.05.09 16:08) [54]
> Сути это не меняет. С точки зрения потока операций процессора
> это должен быть идентичный поток.

Дело в том, что языки программирования уже давно делаются не для процессоров, а для людей. По-этому то, что ты говоришь, уже не актуально, актуально то, как это люди воспринимают.

> А вот указания место затыка для параметризованном классе
> укажет точно. Насколько я понял это основное их назначение.

Абсолютно верно.

← →
oxffff © (2009-05-12 16:25) [60]

> Alkid © (12.05.09 15:55) [50]
>
> > oxffff © (12.05.09 15:33) [44]
> >
> > Вам вопросы в таком случае
> > 1. В чем преимущество ? оператора перед обычным IF
>
> Тернарный оператор представляет собой выражение, в то время
> как обычный if - statement. В этом смысле они не взаимозаменяемые.
>
>
>
> > 2. Почему templates трансформируют в concepts по вашему
>
> Они их не трансформируют шаблоны в concepts, они консепты
> их добавляют к шаблонам. Мотивация - шаг в сторону design
> by contract, к декларативности. Шаблоны дают много свободы
> в compile-time (в частности, реализуют compile-time duck
> typing),

Такого понятия нет. Duck typing не имеет отношение к concepts
Duck typing имеет отношение к полиморфизму отличному от наследования.

← →
Игорь Шевченко © (2009-05-12 16:27) [61]

Alkid © (12.05.09 16:07) [53]

> Это понимание тех теоретических основ, выражением которых
> являются конкретные механизмы или технологии.

Основы со времени Кнута вообще-то несильно изменились. А он их довольно популярно изложил.

> Очень просто - понимание того, что есть императивные языки
> и есть декларативные языки, какие у них есть свойства, достоинства
> и недостатки

И дальше что ? :) На свете есть много всего интересного, даже если программист будет знать, что есть языки таких классов, чем это ему может помочь ?

> На самом деле за последние 60 лет ПРИНЦИПИАЛЬНО нового мало
> придумано

Вообще-то придумано. И в основном для того, чтобы программирование из жреческого искусства сделать массовым ремеслом. Впрочем, возможно я не в курсе, что ты понимаешь под "принципиально" новым, если пояснишь, возможно дискуссия станет более плодотворной :)

← →
Alkid © (2009-05-12 16:30) [62]

> oxffff © (12.05.09 16:25) [60]
> Такого понятия нет. Duck typing не имеет отношение к concepts
> Duck typing имеет отношение к полиморфизму отличному от
> наследования.

Да ну? Скажи, чем отличаются дженерики в C# от шаблонов в C++ с точки зрения "потребительских свойств", т.е. не вдаваясь в детали реализации?

← →
oxffff © (2009-05-12 16:31) [63]

> palva © (12.05.09 16:21) [58]

Вот наконец реальный довод. Спасибо!

← →
Игорь Шевченко © (2009-05-12 16:32) [64]

palva © (12.05.09 16:21) [58]

> Если серьезно, то конструкции ++, ?:, когда они появились,
> естественно были непривычными и поэтому нечитабельными

"предложенные в С сокращения синтаксиса соответствуют наиболее часто встречающимся на практике стереотипным ситуациям. Если считать сокращения идиомами для выразительного и компактного представления таких ситуаций, то польза от них становится безусловной и очевидной."

(с)

← →
AndreyV © (2009-05-12 16:38) [65]

> [55] oxffff © (12.05.09 16:10)
> > Да совсем не идентично.
>
> С точки зрения инструкций процессора?

Может и инструкций для того первоначально и задуман, но теперь эта его сторона не актуальна. Но уже ответили.

← →
oxffff © (2009-05-12 16:41) [66]

> Alkid © (12.05.09 16:30) [62]

Различия отношения к duck typing не имеют.
А вот общее имеет отношение к duck typing,
И в том и другом случае нельзя вызвать неизвестный (несвязанный с типом)метод) и в том и другом случае.

Templates or generic types
Template functions or methods apply the duck test in a static typing context; this brings all the advantages and disadvantages of static versus dynamic type checking in general. Duck typing can also be more flexible in that only the methods actually called at run time need to be implemented, while templates require implementation of all methods that cannot be proven unreachable at
compile time.

Я понял что ты хотел сказать. Но придумать название этому я не знаю как. :))))

← →
palva © (2009-05-12 16:43) [67]

> Дело в том, что языки программирования уже давно делаются
> не для процессоров, а для людей

Ну я не для того, чтобы оспорить, - по большому счету я с вами согласен - но приведу такой пример. Когда 86 процессор изменился, в нем по-другому стала работать операция сдвига, типа стали учитываться только 5 младших битов в константе сдвига, то ведь изменился и C++. А что, взяли да внесли соответствующие изменения в стандарт языка. А вы говорите, для людей... Совсем недавно это было.

← →
Alkid © (2009-05-12 16:45) [68]

> Игорь Шевченко © (12.05.09 16:27) [61]
> Основы со времени Кнута вообще-то несильно изменились. А
> он их довольно популярно изложил.

Ну, вообщем-то да.

> И дальше что ? :) На свете есть много всего интересного,
> даже если программист будет знать, что есть языки таких
> классов, чем это ему может помочь ?

Это даст ему широту охвата, дополнительные перспективы при взгляде на решаемую задачу. Ведь языки программирования - это не только инструменты, но и наборы понятий, в которых программисты осмысливают проблемы и их решения. Даже если программист несвободен в выборе инструмента, это может пойти ему на пользу, поскольку он сможет смоделировать себе решение в более подходящих абстракциях, чем те, которые ему предлагает навязанный инструмент. А уж если программист может выбирать, при помощи чего решать задачу, то он сможет выбрать наиболее подходящий язык.

> Вообще-то придумано. И в основном для того, чтобы программирование
> из жреческого искусства сделать массовым ремеслом. Впрочем,
> возможно я не в курсе, что ты понимаешь под "принципиально"
> новым, если пояснишь, возможно дискуссия станет более плодотворной
> :)

Ну, например, какие свойства языка были сильно распиарены в C#? Это управляемый код, сборка мусора, "всё-есть-объект", интроспекция, динамичность (не типизации, а самого языка). Потом добавили лексические замыкания, linq, вывод типов. Все эти "новшества" - это хорошо забытое старое, поданное в красивой обёртке (про linq можно поспорить). Спору нет, .NET и C# получились очень удобной платформой и хорошим языком, но это всё не фундаментальные нововведения.

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

> oxffff © (12.05.09 16:41) [66]

Ну, вообщем, мы друг друга поняли.

Предлагаю ввести для этого дела термин "compile-time duck typing" или "static duck typing". Покрайней мере, пока не придумаем что-нибудь лучше :)

Alkid © (12.05.09 16:45) [68]

> Это управляемый код, сборка мусора

Это не принципиально новое ? :) (Я имею в виду не относительно С#, а за 60 лет) ?

То, что развитие идет не в языке, а в средствах - так это вполне закономерная тендеция и цель ее все та же - управление сложностью. Раньше были громоздкие программы на ассемблере (я не беру программирование в машинных кодах, это вообще до Адама было) - появились языки высокого уровня, где сложностью стало управлять на порядок легче (соответственно и задачи усложнились). Появились громоздкие программы на языках высокого уровня - соответственно, поднялся уровень языка, появилась та же сборка мусора, объекты, и т.п.
Некуда стало уровень языка повышать - появлись различные верификаторы, средства для рефакторинга и т.п. - все с одной целью - поместить как можно больше информации в ментальную модель задачи.

Я к чему - Hello, world, калькулятор, медиаплейер можно написать без замыканий, сборки мусора, объектов и т.п. А вот приличную корпоративную систему - уже труднее, хотя можно. Но невыгодно.

> palva © (12.05.09 16:43) [67]

Ну так а Вы чего хотите? :) С++ по нынешним меркам - это язык среднего уровня, а С - так вообще низкого :)

> Игорь Шевченко © (12.05.09 16:52) [70]
> Это не принципиально новое ? :) (Я имею в виду не относительно
> С#, а за 60 лет) ?

Когда его делали в LISP(1958-й год), это было новое. А когда в Java (1995-й год) - нет. Я это к чему - понимание этого дела а позволяет гораздо проще относиться к великому множеству технологий, которыми нас сейчас шумно бомбардируют крупные корпорации.

> Раньше были громоздкие программы на ассемблере (я не беру
> программирование в машинных кодах, это вообще до Адама было)
> - появились языки высокого уровня, где сложностью стало
> управлять на порядок легче (соответственно и задачи усложнились).
> Появились громоздкие программы на языках высокого уровня
> - соответственно, поднялся уровень языка, появилась та же
> сборка мусора, объекты, и т.п.

Раньше были не только громоздкие программы на ассемблере, но и медленные программы на Lisp-е, в которых уже были сбора мусора, замыкания, метапрограммирование... :)

> Некуда стало уровень языка повышать - появлись различные
> верификаторы, средства для рефакторинга и т.п. - все с одной
> целью - поместить как можно больше информации в ментальную
> модель задачи.

Вот тут крайне занимательная тема для осмысления - есть ли некий фундаментально-обусловленный "потолок" для повышения уровня абстракции и, если есть, насколько близко мы к нему подошли.

Alkid © (12.05.09 17:04) [72]

> но и медленные программы на Lisp-е, в которых уже были сбора
> мусора, замыкания, метапрограммирование... :)

А вот поместить сборку мусора в императивный язык - это принципиально ? :)

Речь же не идет о том, что вот какая классная фича по обработке строк была в языке Снобол (он кстати жив?) и какие классные фичи по работе с матрицами есть в APL - я, насколько понимаю, смысл не в первоизобретателях, а в том, насколько развиваются массовые языки, (надеюсь, мне будет позволен этот термин ?), даже Delphi сейчас от классического Виртовского паскаля отличается, причем неслабо.
А массовые языки - они все алголоподобные, как ни странно - то ли усваиваются лучше, то ли еще по каким причинам...

> Игорь Шевченко © (12.05.09 17:11) [73]
> А вот поместить сборку мусора в императивный язык - это
> принципиально ? :)

А Lisp, кстати, позволяет писать вполне себе императивные программы :)

> А массовые языки - они все алголоподобные, как ни странно
> - то ли усваиваются лучше, то ли еще по каким причинам...

Всё просто - мэйнстрим программирования идейно рос от железа, которое было воплощением идей машины Тьюринга. Именно по-этому сейчас весь мэйнстрим императивный. При этом языки "от математики", тоже были со всеми их фитчами, но слабость железа не позволяла им быть реально универсальными языками. Сейчас наблюдает конвергенция, причём конвергениция "снизу" - алголоподобные языки начинают активно заимствовать у "академических" собратьев. Почему схождение идёт именно так - в принципе понятно, инерционность существующей инфраструктуры и мышления. Со всех сторон проще взять C# и постепенно довести его до Lisp, чем просто переключиться на Lisp.

P.S. Snobol мёртв, но его наследие живо :)
Я проследил следующую ветку: Snobol1..4 -> Icon -> Unicorn.

← →
Fast (2009-05-12 17:34) [76]

Естественно, понимая, что это не реально, но есть предложение:
Alkid ©
и
Игорь Шевченко ©
предложить продолжить это (даже не могу подобрать слово, прекрасно понимая, что Игорь Шевченко © затрет этот пост) в чате
:)

> Отсюда вопрос, как перестать писать в Паскаль стиле?

Для начала надо найти отличия Паскаль стиля от стиля C++. На первый взгляд это:

1. Поскольку объекты в C++ создаются в стеке, то они достаточно дешевые. Поэтому в C++ буквально на каждый чих объявляется свой собственный класс, и все методы, которые относятся к этому классу, перемещаются туда.

2. Стиль паскаля обычно исповедует try..finally конструкции. В C++ обычно такие ситуации стараются разруливать автоматическими деструкторами. Ну и использование всяких трюков на основе этого.

3. Для программиста на Pascal обычно возникают некоторые сложности при знакомстве с библиотеками а-ля STL или BOOST. Зачастую многие стандартные контейнеры программисты на паскале реализуют ручками. Больше в стиле C++ использовать итераторы, слабые указатели и т. п.

4. Шаблоны, множественное наследование. Программисты на паскале стараются этого избегать, и мало в курсе некоторых трюков с этим.

← →
Иа (2009-05-16 22:33) [78]

> Вам вопросы в таком случае
>
> 1. В чем преимущество ? оператора перед обычным IF

то что это оператор и может использоваться как оператор.

пример:

dbContext.Users.Select(u => new { u.Name, CompanyName = (u.Company != null) ? u.Company.Name : string.Empty)} );

> Иа (16.05.09 22:33) [78]

Iif в данном конкретном случае, был бы более читабелен, имхо. Или IsNull.

> Но мы в затруднении, т.к. сейчас ты будешь программировать
> на С++ в паскаль стиле,
> а для нас это не приемлемо

А ты уверен, что ты хочешь у них работать?
Я б задумался.

А что, с вакансиями по Delphi, совсем туго стало?

Как перестать программировать на С++ в Паскаль стиле? Найти похожие ветки