Что разрабатывают на Си шарп?

← →
Vga © (2006-11-14 03:46) [80]

> [79] Ketmar © (14.11.06 02:12)

Что за FDM? И FoxMail?

← →
Горгер © (2006-11-14 03:48) [81]

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

← →
Ketmar © (2006-11-14 03:54) [82]

>[80] Vga(c) 14-Nov-2006, 03:46
>Что за FDM? И FoxMail?
Free Download Manager. гугль знает. %-)
FoxMail -- это китайский ответ зебату. %-)

← →
Ketmar © (2006-11-14 03:55) [83]

только не надо брать FoxMail 6. уже не то. 5 -- самое оно.

← →
Vga © (2006-11-14 03:57) [84]

> [82] Ketmar © (14.11.06 03:54)

Запомним... Пока что М2 нравится больше всего... Хотя этот мылер конечно фичами обделен...

← →
Ketmar © (2006-11-14 04:10) [85]

это не мылер. это "примочка". при всей моей любви к Опере. %-)

← →
Vga © (2006-11-14 04:12) [86]

> [85] Ketmar © (14.11.06 04:10)

Мылер-примочка :) Говорю же, фичами обделен... Типа даунлоадера встроенного в Оперу. Однако мне почему-то именно он нравится... Есть практически все, что мне надо, почти ничего лишнего и довольно удобно ИМХО...

← →
Ketmar © (2006-11-14 04:18) [87]

я его не полюбил со времён, когда он не понимал KOI-8. %-(

← →
KSergey © (2006-11-14 06:04) [88]

> Игорь Шевченко © (13.11.06 23:00) [73]
> Да, я в курсе. Страуструп работал в Microsoft и изобрел
> там Visual Studio, ну и MFC до кучи. Так С++ и появился.

Зачем же так на неокрепшие-то мозги, да еще без смайликов? :)

> Галинка © (13.11.06 18:15) [63]

Плиз, разберитесь с матчастью. У вас каша в голове.
Кроме того, MFC - далеко не единственная библиотека к C++, не имеющая к языку какого-либо отношения. Этих дидлиотек - горы, как локальных внутрипроектных, так и общеизвестных ввиду своей популярности. Один boost чего стоит :)

← →
KSergey © (2006-11-14 06:10) [89]

> Игорь Шевченко © (13.11.06 15:12) [43]
> Если не трудно, расскажи пожалуйста, каким образом в этом
> могут помочь схемы и диаграммы, если есть доступ к коду.

И это говорит сам ИШ!... :(

Игорь, может вам давно не приходилось (или не приходилось вообще) приходить в большой проект?
Сейчас вижу перед собой проект в 100Мб плюсовых исходников (вернее, это год назад столько было, сейчас не знаю), и лично я с большим трудом представляю себе как можно без документации, обобщенных диаграмм и, увы, выуживания "тайных знаний" из окружающих разобраться во всем этом по коду за какой-либо разумный срок...
Неужели я на столько безнадежно туп?

← →
KSergey © (2006-11-14 06:11) [90]

> KSergey © (14.11.06 06:10) [89]
> Игорь, может вам давно не приходилось (или не приходилось
> вообще) приходить в большой проект?

имеется в виду приходить не с нуля.

← →
KSergey © (2006-11-14 06:15) [91]

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

← →
Lamer@fools.ua © (2006-11-14 09:12) [92]

>>KSergey © (14.11.06 06:10) [89]

>Сейчас вижу перед собой проект в 100Мб плюсовых исходников (вернее, это год назад столько было, сейчас не знаю), и лично я с большим трудом представляю себе как можно без документации, обобщенных диаграмм и, увы, выуживания "тайных знаний" из окружающих разобраться во всем этом по коду за какой-либо разумный срок...
IMHO, разобраться в стомеговых плюсовых исходниках поможет только поллитры, причём обязательно натощак ;o)

← →
iZEN © (2006-11-14 09:45) [93]

> Lamer@fools.ua © (14.11.06 09:12) [92]
>
> >>KSergey © (14.11.06 06:10) [89]
>
> >Сейчас вижу перед собой проект в 100Мб плюсовых исходников
> (вернее, это год назад столько было, сейчас не знаю), и
> лично я с большим трудом представляю себе как можно без
> документации, обобщенных диаграмм и, увы, выуживания "тайных
> знаний" из окружающих разобраться во всем этом по коду за
> какой-либо разумный срок...
> IMHO, разобраться в стомеговых плюсовых исходниках поможет
> только поллитры, причём обязательно натощак ;o)

Не поможет. Здесь камаза с цисцерной мало будет.

(напомните, сколько там исходники Windows занимают?)

← →
clickmaker © (2006-11-14 09:52) [94]

> сколько там исходники Windows занимают?)

а что, они уже где-то выложены?

← →
Игорь Шевченко © (2006-11-14 10:10) [95]

Eraser © (14.11.06 01:47) [77]

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

Если сотня как-то промеж собой существуют, то наверняка найдется место и сто первому. Я вот честно себе не могу представить, к какого рода продуктам могут относиться те, которых уже сотня (ну пусть десяток), и где сто первому (ну пусть одиннадцатому) чтобы найти себе рыночную нишу непременно следует пользоваться драйверами или другой внутрисистемной технологией.
Подскажешь ?

← →
Игорь Шевченко © (2006-11-14 10:27) [96]

KSergey © (14.11.06 06:04) [88]

> Зачем же так на неокрепшие-то мозги, да еще без смайликов?
>

Видишь ли, на форуме подразумевается примерно постоянный уровень окреплости мозгов, на него и рассчитываешь. Ярлыка-то нет для личностей с пониженным уровнем окреплости. Придумаем, введем или как ?

> Игорь, может вам давно не приходилось (или не приходилось
> вообще) приходить в большой проект?

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

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

> Сейчас вижу перед собой проект в 100Мб плюсовых исходников
> (вернее, это год назад столько было, сейчас не знаю), и
> лично я с большим трудом представляю себе как можно без
> документации, обобщенных диаграмм и, увы, выуживания "тайных
> знаний" из окружающих разобраться во всем этом по коду за
> какой-либо разумный срок...

Про документацию ты сам сказал - оно рулез, ее читать надо и воздастся тебе по чтению твоему.

> Неужели я на столько безнадежно туп?

Скорее, проект плохой. Такое тоже бывает, хотя для большого проекта это странно.

Может, я излишне нападаю на все эти диаграммы, но сколько не видел больших проектов (в сети обычно), почему-то ни к одному не было приложено диаграмм, а все диаграммы встречались исключительно в книжках яйцеголовых авторов или в журнальных статьях авторов, стремящися стать яйцеголовыми. Они с придыханием произносят слово: "МЕТОДОЛОГИЯ" ну и там диаграммы разные, да еще с десяток разного вида на один и тот же сабж.

iZEN © (14.11.06 09:45) [93]

> (напомните, сколько там исходники Windows занимают?)

29 миллионов строк кода - уже достаточно для того, чтобы отбросить всякую попытку держать их целиком в голове. Но Windows достаточно неплохо структурирована, поэтому в голове приходится держать небольшу., вполне себе обозримую часть. Кроме того, Help"а по нему немеряно, наверняка больше, чем по любому другому выпускавшемуся продукту.

← →
ANB © (2006-11-14 10:49) [97]

>
> Уточни. Я правильно тебя понял, что БД ты проектируешь,
> не составляя ER-диаграмы? 8-()

Упаси меня боже. Лучше SQL для этого ничего нет :)

Кстати, а ты знаешь хоть один толковый ER-редактор, который поддерживает все оракловые фичи и при этом сама схема у него более менее красиво и понятно отображается ?

← →
Курдль © (2006-11-14 11:05) [98]

> ANB © (14.11.06 10:49) [97]
> > Уточни. Я правильно тебя понял, что БД ты проектируешь,
> > не составляя ER-диаграмы? 8-()
>
> Упаси меня боже. Лучше SQL для этого ничего нет :)

И как на SQL-е, например, выглядит наследование, или ассоциация? %)
Как ты с другими разработчиками общаешься? Типа: "Эй, Вася, а не 1001010001010001010 тебе на 1000101001010010010 и твою 10110101000101001 в 1010010110101001010?"

>
> Кстати, а ты знаешь хоть один толковый ER-редактор, который
> поддерживает все оракловые фичи и при этом сама схема у
> него более менее красиво и понятно отображается ?

Какие именно фитчи тебе надо поддерживать? (Может я чего-то не понимаю).
Sybase Power Designer ни разу не показался мне недостаточным для какой угодно задачи. Дело даже хуже - я не использовал его и на 10% его мощности - знаний не хватает :(

← →
Игорь Шевченко © (2006-11-14 11:11) [99]

Курдль © (14.11.06 11:05) [98]

> И как на SQL-е, например, выглядит наследование, или ассоциация?
>

А как в базе данных вообще выглядит наследование ?

← →
ANB © (2006-11-14 11:11) [100]

> И как на SQL-е, например, выглядит наследование, или ассоциация?

Для этого есть комментарии, в которые я запихаю намного больше инфы, чем позволит мне ЕР редактор.

> Какие именно фитчи тебе надо поддерживать?

В частности Ер-вин не дает мне прописывать комментарии в таблицы и поля.

← →
ANB © (2006-11-14 11:16) [101]

> наследование, или ассоциация

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

← →
Курдль © (2006-11-14 11:34) [102]

> Игорь Шевченко © (14.11.06 11:11) [99]
> А как в базе данных вообще выглядит наследование ?

Никак - это свойство концептуальной модели.
А как выглядит мощность на микросхеме?
Вроде - никак, если только не приглядываться к размерам и теплоотводам.
Однако, мы ее всегда учитываем при проектировании.

> В частности Ер-вин не дает мне прописывать комментарии в
> таблицы и поля.

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

← →
Игорь Шевченко © (2006-11-14 11:37) [103]

Курдль © (14.11.06 11:34) [102]

> Никак - это свойство концептуальной модели.

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

← →
Курдль © (2006-11-14 11:54) [104]

> База данных - она реляционная, а не объектно-ориентированная,
> вот нехай в реляционных терминах она и описывается.

Реляционная она - от бедности. Ну нет пока надежных ООСУБД.
Я не отступлюсь от убеждения, что чем ближе объекты предметной области к объектам программы и к сущностям БД, тем проще проектировать и поддерживать проекты.

Вот пример из жизни.
1. Предметная область: простые гражданские отношения. Есть человек, проживающий по адресу, имеющий паспорт (или два) имеющий прописку (еще один адрес) и несколько телефонных номеров. 2. Объектная модель. Есть физическое лицо, являющееся субъектом гражданских отношений. Имеет коллекцию из адресов, коллекцию из паспортов, коллекцию из телефонных номеров. 3. Реляционная модель. Есть сущность "физическое лицо", унаследовавшая атрибуты от сущности "субъект". К ней относятся как много-к-одному сущности "адрес", "паспорт" и "телефон".

← →
ANB © (2006-11-14 12:03) [105]

> К ней относятся как много-к-одному сущности "адрес", "паспорт"
> и "телефон".

Хм. Хм. Позвольте усомниться. В приведенном примере объектный подход беднее по возможностям, чеи реляционный.

Например, возьмем адреса. Если у нас БД, например, налогового учета, то один и тот же адрес может быть у : нескольких человек, имущества. Т.е. связка многие к многим. Интересно, как объектная модель вообще определяет такие связки ?
Может потому и ООСУБД так неразвиты по сравнению с реляционными БД, что менее гибки ?
Кстати, оракл потихоньку развивает объектные возможности, но я практически не видел проектов, где они используются.

← →
boriskb © (2006-11-14 12:06) [106]

Курдль © (14.11.06 11:54) [104]
Реляционная она - от бедности. Ну нет пока надежных ООСУБД.

Когда я на персоналках впервые увидел реляционные БД, я долго не хотел их принимать вообще за БД (так - удобные таблички - не более).
После ADABAS-a и т.п.
А потом ничего - привык :)

← →
Игорь Шевченко © (2006-11-14 12:08) [107]

Курдль © (14.11.06 11:54) [104]

> Реляционная она - от бедности. Ну нет пока надежных ООСУБД.

Зато есть надежные реляционные СУБД, а нам, как известно, ехать куда важнее, чем шашечки.

> Вот пример из жизни.
> 1. Предметная область: простые гражданские отношения.
> Есть человек, проживающий по адресу, имеющий паспорт (или
> два) имеющий прописку (еще один адрес) и несколько телефонных
> номеров.
>
> 2. Объектная модель.
> Есть физическое лицо, являющееся субъектом гражданских отношений.
>
> Имеет коллекцию из адресов, коллекцию из паспортов, коллекцию
> из телефонных номеров.
>
> 3. Реляционная модель.
> Есть сущность "физическое лицо", унаследовавшая атрибуты
> от сущности "субъект". К ней относятся как много-к-одному
> сущности "адрес", "паспорт" и "телефон".

Ты меня конечно извини, но чем простые отношения Primary Key|Foreign key не устраивают ?
И что, у субъектов телефонов и адресов нету ?

← →
Игорь Шевченко © (2006-11-14 12:09) [108]

boriskb © (14.11.06 12:06) [106]

> После ADABAS-a и т.п.

Не буди ностальгию, не заставляй вспоминать Natural, AdaScript, MPM и прочее :)

> ANB © (14.11.06 12:03) [105]
> Хм. Хм. Позвольте усомниться. В приведенном примере объектный
> подход беднее по возможностям, чеи реляционный.

Не позволю. Реляционные СУБД не поддерживают данные о поведении объектов (методы).

> Например, возьмем адреса. Если у нас БД, например, налогового
> учета, то один и тот же адрес может быть у : нескольких
> человек, имущества. Т.е. связка многие к многим. Интересно,
> как объектная модель вообще определяет такие связки ?

Связка такая же, как и в РСУБД - через ассоциацию.

> Может потому и ООСУБД так неразвиты по сравнению с реляционными
> БД, что менее гибки ?

Может быть. А может потому. что они появились лет на 30 позже?

> Кстати, оракл потихоньку развивает объектные возможности,
> но я практически не видел проектов, где они используются.

Это сильно усеченный вариант объектной модели.

> iZEN (14.11.2006 09:45:33) [93]

Какой версии?
Если 2000 то 30 миллионов строк, это стопка, примерно в 55 метров бумаги

> Не позволю. Реляционные СУБД не поддерживают данные о поведении
> объектов (методы).

ИМХО - намного удобнее запихать логику в пакеты и обрезать юзеру прямой доступ. А в случае с ООП придется практически все писать в клиенте или в сервере приложений. Сам же гришь - нету толковых ООСУБД. Имхо - они таки плохо развивабтся из-за отсутствия спроса. Тому же адабасу уже тоже под 30 лет (вроде, но не менее 20). Однако он в 80-х уже был мощной СУБД. А про ООСУБД я слышу с начала 90-х, но их никто не пользует промышленно.

> Игорь Шевченко © (14.11.06 12:08) [107]
> Зато есть надежные реляционные СУБД, а нам, как известно,
> ехать куда важнее, чем шашечки.

Поэтому пока и не произошло революции в базостроении (во всяком случае, типа ООСУБД против РСУБД).

> Ты меня конечно извини, но чем простые отношения Primary
> Key|Foreign key не устраивают ?

Отношения Primary Key|Foreign устраивают полностью - это ведь неотъемлемые атрибуты физической модели БД.
Но для проектирования БД хотелось бы чего-то более человечного (ведь движется человечество от программирования в цифрах к мнемокодам - ассемблерам - компиляторам ЯВУ - ООП и т.д.).

> И что, у субъектов телефонов и адресов нету ?

Субъектом гражданских отношений может являться государство, либо субъект государства (район, область) - какой у них адрес/телефон?
Но это досужий спор. Я привел пример, где атрибуты объектов (сущностей) очерчены рамками автоматизируемой программной области. Если бы я "автоматизировал весь мир", применил бы другие классифицирующие правила.

> ANB © (14.11.06 12:25) [111]

Да не пропагандирую я тут ООСУБД!
Я просто отстаиваю свое заявление об эффективности проектирования на уровне моделей (графических представлений).

> Субъектом гражданских отношений может являться государство,
> либо субъект государства

Не может. Субъектами ГО могут быть только лица - юридические и физические. При заключении договора с "государством", ты заключаешь его с конкретным лицом, выступающим от имени государства. А у него уже есть все атрибуты.

> Я просто отстаиваю свое заявление об эффективности проектирования
> на уровне моделей (графических представлений).

Не. Я на SQL все намного быстрее нарисую. Все эти ер-редакторы жутко тормозят и глючат. И все равно всех возможностей не раскрывают. Даже родной оракл-дизайнер. Меня все подмывает сесть и нарисовать свой дизайнер, но в чисто в табличном виде. Без всяких диаграмм. Намного удобнее будет.

Курдль © (14.11.06 12:27) [112]

> Отношения Primary Key|Foreign устраивают полностью - это
> ведь неотъемлемые атрибуты физической модели БД.
> Но для проектирования БД хотелось бы чего-то более человечного
> (ведь движется человечество от программирования в цифрах
> к мнемокодам - ассемблерам - компиляторам ЯВУ - ООП и т.
> д.).

Да хрен с ним, с движением человечества, давай с движением программиста разберемся. Если есть реляционный слой данных, то и стоит, очевидно, пользоваться его терминологией, а не пытаться навесить на него несвойственные ему способы репрезентативности предметной области. Другими словами, не надо умножать сущности сверх необходимости - база данных не оперирует отношениями наследования или ассоциации, у нее есть primary/Foreign keys.

> Субъектом гражданских отношений может являться государство,
> либо субъект государства (район, область) - какой у них
> адрес/телефон?
> Но это досужий спор. Я привел пример, где атрибуты объектов
> (сущностей) очерчены рамками автоматизируемой программной
> области. Если бы я "автоматизировал весь мир", применил
> бы другие классифицирующие правила.

Я конечно извиняюсь, но введение субъектов и физических лиц, наследующих их атрибуты сильно смахивает на попытку "автоматизировать весь мир". Кроме того, адрес у государства есть. При желании и телефон можно найти :)

> ANB © (14.11.06 12:33) [115]
> Не. Я на SQL все намного быстрее нарисую.

Могу наспор победить тебя по скорописи БД в PD.
Сколько текста скрипта ты напишешь, чтобы полностью описать мое действие "провел линию от одной сущности к другой"?

Скоро SUN откроет сырцы Java и opensource сообщество дружно начнет копать могилу FrameWork"у!

> Курдль © (14.11.06 11:54) [104]

Несколько не так.

Например город.

1. Название.
2. Координаты.
3. Число жителей.
4. Тип столица/нет.
5. Количество заправок
6. Количество кафэ.
Реалиционная модель - заводим таблицу свойств черех связь многие-к одному и смотрим там столица он или нет, и через связь один уо .

Объектная :
Объект город.

1. название
2. координаты
3. число жителей.

объект город столица.
прибавляем
4. Столица.

Теперь если бывбрать данные из "город" мы получим и города и столицы. А если "город столица", то только столицы.

допустим некоторые города имеют у нас данные по кафэ:

Объект город +
4 кафэ

теперь можно выбрать только города "не столицы" с кафэ.

И тд.

> Курдль © (14.11.06 12:38) [117]

А вот сколько ты телодвижений совершишь, чтобы исправить имя поля ссылки в своей диаграмме ? :)
И давай на скорость - в БД 1500 таблиц. Есно, на одну схему они не влезут.
Надо связать таблицы, находящиеся на разных схемах, причем у обоих длинные имена. И полю ссылке надо сделать имя с суффиксом.
Мне на добавление и корректуру оператора понадобится секунд 5-10 (буфер обмена рулит !), и еще минуту или 2 на написание комментария (который в ервине лепить некуда).

Что разрабатывают на Си шарп? Найти похожие ветки