Linuxway

Tiphon · 28-07-10 18:27:39

whoknows пишет:

Это расширение ему надо явно "скормить" перед началом компиляции, иначе он байт-код не сгенерит.

Ты делаешь using, но ты делаешь его не для конкретно экстеншена, а для целой части функционала библиотеки. Понимаешь, юзинги не привязаны к отдельным файлам или классам, как #includes. Они привязываются к логическому разбиению библиотек на разный функционал.
Я поэтому и говорю, что ты - глянь.
Поэтому никакого отдельного действия для экстеншена тебе применять не надо.

Редактировался Tiphon (28-07-10 18:28:56)

whoknows · 28-07-10 18:33:18

DonDublon3 пишет:

Вот понимаешь, сегодня это считается базовыми примитивами, а 40 лет назад не считалось.

Перефразирую: это то, о чём обязан знать компилятор, для того, чтобы генерировать предсказуемый и эффективный код.

DonDublon3 пишет:

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

Это уж 40 лет как примитив. Даже на уровне процессоров wink

DonDublon3 пишет:

QThread из Qt, потоки в Питоне, TThread в delphi..)

Ты мешаешь всё в кучу. Qt - это библиотека. Python/Delphi - языки программирования. Что обсуждаем? Как связать динамически линкуемые библиотеки, написанные на разных языках и скомпилированные разными компиляторами?

DonDublon3 пишет:

Поэтому искусственно ограничивать список примитивов, как, по твоим словам, делали создатели С++,

Это как раз-таки натуральное ограничение. Почему - см. ниже.

DonDublon3 пишет:

Но в рамках одного процессора-то ABI таки одинаковый. И это уже круто.

Это не так. Пример. Класс Container. У него члены (API): void set(Object), Object get(void), boolean isUsed(), void setUsed(boolean)

Реализация 1 (только поля):
class A
{
int used;
Object o;
}

Реализация 2
{
Object o;
boolean used;
}

Всё. Обе реализации корректны, но ABI у них разный. Раз'яснения нужны?
Как реализовывать - выбор разработчика, пока API неизменен.

Tiphon · 28-07-10 18:34:11

petrun пишет:

Не дойдет он в таком виде.С ядром NT.

Ну его сила в том, что он и не обязательно привязывается к ядру NT. К слову о той же сингулярности или cosmos. В случае чего его можно оттуда отвязать, а приложения так и будут работать.

whoknows · 28-07-10 18:37:06

Tiphon пишет:

Ты делаешь using, но ты делаешь его не для конкретно экстеншена, а для целой части функционала библиотеки.

Вот, а если я не делаю импорт пакета с экстеншином в единицу трансляции (.c# файл) - то будет компилейшен еррор. Т.е. действия нужны на самом деле smile Это ок, просто спросил, уточнить.

Tiphon пишет:

Я поэтому и говорю, что ты - глянь.

Я до уже глянул. Не понял как это поможет не подключать явно экстеншин.

Никогда не импортирую всё содержимое пакетов (a-las using namespace std or import java.*) smile

Tiphon · 28-07-10 18:38:09

whoknows пишет:

Как реализовывать - выбор разработчика, пока API неизменен.

Ну учитывая, что в логических операторах в .net допускаются только bool переменные без всяких true if !=0, кроме того удобно (о боже, по сравнению с С++) сделаны enum перечисления - это ведет к тому, что обе реализации корректны
Реализация 1 (только поля):
class A
{
int used;
Object o;
}

Реализация 2
{
Object o;
boolean used;
}

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

Tiphon · 28-07-10 18:41:35

whoknows пишет:

Не понял как это поможет не подключать явно экстеншин.

В общем случае ты не делаешь using MyByb.MyExtension

whoknows пишет:

Никогда не импортирую всё содержимое пакетов (a-las using namespace std or import java.*)

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

using namespace std - совершенно по-уродски в С++ сделано)) Я тоже не люблю таким пользоваться.

whoknows · 28-07-10 18:51:34

Tiphon пишет:

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

Э-не. Поменяй местами Object и boolean - как 2 реализации. ABI уже бужет разным. Я могу добавить туда мьютекс в своей третьей реализации (если хочу, чтобы даже если юзер и даун и не делает внешнюю синхронизацию, у него ничего не слетело). Ну и пример лубочный.
Тот же TreeSet можно сделать минимум 2я способами концептуально. А на деле - хоть 500ми.

Tiphon пишет:

Говорю же, глянь, как пользоваться юзингами.

Including using System; establishes that the System namespace is assumed, and you can subsequently write just this.

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

Редактировался whoknows (28-07-10 18:54:41)

Tiphon · 28-07-10 18:54:01

whoknows пишет:

Поменяй местами Object и boolean - как 2 реализации. ABI уже бужет разным.

Так, я запутался. Аби с точки зрения CIL или результирующего машинного кода?

whoknows · 28-07-10 18:55:47

Tiphon пишет:

Аби с точки зрения CIL или результирующего машинного кода?

Оба примера не дают _гарантированно_ ни того ни другого. Я про CLI для начала (на уровне байт-кода)

Armanx64 пишет:

кто-кто, а линуксоид такую фразу сказать не может

Почитай что-нить про unixway wink

Редактировался whoknows (28-07-10 18:56:40)

Tiphon · 28-07-10 18:58:48

whoknows пишет:

Оба примера не дают _гарантированно_ ни того ни другого. Я про CLI для начала (на уровне байт-кода)

Эт да. На самом-то деле да) Но четкий ответ требует размышлений. Может на днях поэкспериментирую - напишу сюда.

Гареев Станислав · 29-07-10 00:22:16

Собственно я только что подписался на эту тему.
Всё прочитать не осилил, так как спать охото и в сях я не понимаю.
Моё мнение:
Баги - это следствие того что сознание упускает подробности функционирования замысла, то есть воображение не проводит трассировку проекта. Касаемо больших проектов, нужно много ремарок, подробных описаний функций, классов и т.д.
В случае риска возникновения несовместимости, надо не делать костыль и писать код под баги модулей. А надо переписать этот модуль и весь наработанный под его баги код. Естественно лень, влом и впадлу. Но ведь если это не сделать, то будет в коде дыра, которую потом несколько лет не смогут закрыть.
Собственно, большие проекты в Linux этим страдают и ядро особенно (тонны кода), в данном случае уместен переход на систему плагинов. Да это снижает производительность. Но unix-way изначально отдаёт предпочтение масштабируемости и переносимости.
Ведь вспомните, c++ был изначально побочным продуктом написания unix. И если бы существовали в то время высоко уровневые языки с низко-уровневымы конструкциями, то такого явления и не появилось бы.
Но ведь изначальный смысл был в абстракции от железа и возможности писать программы под любую платформу. А что получилось....?

Tiphon · 29-07-10 00:46:05

Гареев Станислав пишет:

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

А был ли изначально такой смысл у С++.

Гареев Станислав · 29-07-10 00:50:25

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

whoknows · 29-07-10 01:00:01

Гареев Станислав, вы путаете C++ с C

whoknows · 29-07-10 01:52:22

pavel2403 пишет:

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

Пашок, не все программы имеют "морду лица" wink

pavel2403 пишет:

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

А что можно сказать в твой адрес, читая такой коммент?

Гареев Станислав · 29-07-10 10:36:05

pavel2403 пишет:

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

Дело в том что я как раз по этой книге и освоил Visual Basic smile
Собственно пока учился в школе, сделал одно учебное приложение (экзаменатор) работающий по сети. Хотя конечно приложение было жутко дырявым (поскольку работало через сетевые шары) но оно использовалось несколько лет. И не только в той школе, я его ещё высылал по емайлу в какую то поселковую школу. Я о том, что я прекрасно знаю специфику разработки на этом языке. Собственно, я на этом языке делал небольшие утилитки на заказ и всякую дребедень.
Я конечно не против разработки красивых интерфейсов, но я считаю что гуй должен быть в большинстве случаев лишь фронт-эндом.

Tiphon · 29-07-10 10:42:24

Гареев Станислав пишет:

но я считаю что гуй должен быть в большинстве случаев лишь фронт-эндом.

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

А что делать? Ознакомтесь, отличная книжка, программерам советую хотябы один раз за жизнь прочитать что-то подобное:
http://uibook2.usethics.ru/uibookII.pdf

Редактировался Tiphon (29-07-10 10:46:25)

DonDublon3 · 29-07-10 10:51:50

whoknows пишет:

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

И опять-таки нет. Такая же история как со строками - есть стандартный char*, но он ужасен. Есть стандартный массив, но без указания длины. Поэтому и массивы делают кто во что горазд - в boost один, в delphi другой, в D наверняка третий.

whoknows пишет:

DonDublon3 пишет:
QThread из Qt, потоки в Питоне, TThread в delphi..)
Ты мешаешь всё в кучу. Qt - это библиотека. Python/Delphi - языки программирования. Что обсуждаем? Как связать динамически линкуемые библиотеки, написанные на разных языках и скомпилированные разными компиляторами?

ОБщее между Qt и Delphi - что и там и там создатели сделали свой класс строк, т.е. как раз по теме разговора. В Питоне тоже, он он все-таки не нативный, так что ну его.

whoknows пишет:

DonDublon3 пишет:
Но в рамках одного процессора-то ABI таки одинаковый. И это уже круто.
Это не так. Пример. Класс Container. У него члены (API): void set(Object), Object get(void), boolean isUsed(), void setUsed(boolean)
Реализация 1 (только поля):
class A
{
int used;
Object o;
}
Реализация 2
{
Object o;
boolean used;
}
Всё. Обе реализации корректны, но ABI у них разный. Раз'яснения нужны?
Как реализовывать - выбор разработчика, пока API неизменен.

Ну так реализации же разные, хоть и корректные! Ненене. Тут (у дотнета ) крутость в другом. Я могу взять класс написаный в каком-то девяносто лохматом году на Delphi, и скомпилить его под дотнет. И юзать его в свом приложении на C#. Ну или на C++.net, если мс-хейтер и сишарп не признаю.
Или вот, я смотрел, чиста из интереса, в нете, как народе делает связку разных (ненативных) языков с OCaml. а именно - php и python. Везде писались прослойки на С. Потому что нативный код дает передавать только числа и указатели. А ведь дотнет может классы. Уж не знаю точно, как будет вестись передача между php.net-F# или IronPython-F#, но уверен на стопудов, что существенно проще.

Tiphon · 29-07-10 11:10:31

DonDublon3 пишет:

А ведь дотнет может классы. Уж не знаю точно, как будет вестись передача между php.net-F# или IronPython-F#, но уверен на стопудов, что существенно проще.

Да конечно просто:
http://geekswithblogs.net/MarkPearl/arc … -talk.aspx
http://www.chrisumbel.com/article/scrip … python_dlr

К тому же, есть очень удобные механизмы обмена данным между процессами. Как раз нормальными классами.
http://www.dotnetheaven.com/UploadFile/ … hange.aspx

Форум StopLinux

Объявление

#101 28-07-10 18:27:39

Re: Linuxway

#102 28-07-10 18:33:18

Re: Linuxway

#103 28-07-10 18:34:11

Re: Linuxway

#104 28-07-10 18:37:06

Re: Linuxway

#105 28-07-10 18:38:09

Re: Linuxway

#106 28-07-10 18:41:35

Re: Linuxway

#107 28-07-10 18:51:34

Re: Linuxway

#108 28-07-10 18:54:01

Re: Linuxway

#109 28-07-10 18:55:47

Re: Linuxway

#110 28-07-10 18:58:48

Re: Linuxway

#111 29-07-10 00:22:16

Re: Linuxway

#112 29-07-10 00:46:05

Re: Linuxway

#113 29-07-10 00:50:25

Re: Linuxway

#114 29-07-10 01:00:01

Re: Linuxway

#115 29-07-10 01:52:22

Re: Linuxway

#116 29-07-10 10:36:05

Re: Linuxway

#117 29-07-10 10:42:24

Re: Linuxway

#118 29-07-10 10:51:50

Re: Linuxway

#119 29-07-10 11:10:31

Re: Linuxway

Подвал форума