Это расширение ему надо явно "скормить" перед началом компиляции, иначе он байт-код не сгенерит.
Ты делаешь using, но ты делаешь его не для конкретно экстеншена, а для целой части функционала библиотеки. Понимаешь, юзинги не привязаны к отдельным файлам или классам, как #includes. Они привязываются к логическому разбиению библиотек на разный функционал.
Я поэтому и говорю, что ты - глянь.
Поэтому никакого отдельного действия для экстеншена тебе применять не надо.
Редактировался Tiphon (28-07-10 18:28:56)
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Вот понимаешь, сегодня это считается базовыми примитивами, а 40 лет назад не считалось.
Перефразирую: это то, о чём обязан знать компилятор, для того, чтобы генерировать предсказуемый и эффективный код.
А еще через 10 лет список желательных примитивов будет еще существенно расширен. В него добавятся, как минимум, одномерные массивы.
Это уж 40 лет как примитив. Даже на уровне процессоров
QThread из Qt, потоки в Питоне, TThread в delphi..)
Ты мешаешь всё в кучу. Qt - это библиотека. Python/Delphi - языки программирования. Что обсуждаем? Как связать динамически линкуемые библиотеки, написанные на разных языках и скомпилированные разными компиляторами?
Поэтому искусственно ограничивать список примитивов, как, по твоим словам, делали создатели С++,
Это как раз-таки натуральное ограничение. Почему - см. ниже.
Но в рамках одного процессора-то 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 неизменен.
Не дойдет он в таком виде.С ядром NT.
Ну его сила в том, что он и не обязательно привязывается к ядру NT. К слову о той же сингулярности или cosmos. В случае чего его можно оттуда отвязать, а приложения так и будут работать.
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Ты делаешь using, но ты делаешь его не для конкретно экстеншена, а для целой части функционала библиотеки.
Вот, а если я не делаю импорт пакета с экстеншином в единицу трансляции (.c# файл) - то будет компилейшен еррор. Т.е. действия нужны на самом деле Это ок, просто спросил, уточнить.
Я поэтому и говорю, что ты - глянь.
Я до уже глянул. Не понял как это поможет не подключать явно экстеншин.
Никогда не импортирую всё содержимое пакетов (a-las using namespace std or import java.*)
Как реализовывать - выбор разработчика, пока API неизменен.
Ну учитывая, что в логических операторах в .net допускаются только bool переменные без всяких true if !=0, кроме того удобно (о боже, по сравнению с С++) сделаны enum перечисления - это ведет к тому, что обе реализации корректны
Реализация 1 (только поля):
class A
{
int used;
Object o;
}
Реализация 2
{
Object o;
boolean used;
}
но на первую пшикнут и скажут какого х*я? Понимаешь? Важен-то итог. И все это делается ради итога. И вот .нет сделан в этом смысле очень хорошо - подталкивая к тому, что итог будет один)
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Не понял как это поможет не подключать явно экстеншин.
В общем случае ты не делаешь using MyByb.MyExtension
Никогда не импортирую всё содержимое пакетов (a-las using namespace std or import java.*)
Ну и не надо. Говорю же, глянь, как пользоваться юзингами. Ну и за одно, алиасами на юзинги, если хочешь экстеншн не подключая эту часть функционала.
using namespace std - совершенно по-уродски в С++ сделано)) Я тоже не люблю таким пользоваться.
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
но на первую пшикнут и скажут какого х*я? Понимаешь? Важен-то итог. И все это делается ради итога. И вот .нет сделан в этом смысле очень хорошо - подталкивая к тому, что итог будет один)
Э-не. Поменяй местами Object и boolean - как 2 реализации. ABI уже бужет разным. Я могу добавить туда мьютекс в своей третьей реализации (если хочу, чтобы даже если юзер и даун и не делает внешнюю синхронизацию, у него ничего не слетело). Ну и пример лубочный.
Тот же TreeSet можно сделать минимум 2я способами концептуально. А на деле - хоть 500ми.
Говорю же, глянь, как пользоваться юзингами.
Including using System; establishes that the System namespace is assumed, and you can subsequently write just this.
Больше ничего полезного. Ну и не думаю, что там что-то придумали свехнового. идея понятна - явно или неявно указать компилятору сырец или класс с экстеншином.
Редактировался whoknows (28-07-10 18:54:41)
Поменяй местами Object и boolean - как 2 реализации. ABI уже бужет разным.
Так, я запутался. Аби с точки зрения CIL или результирующего машинного кода?
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Аби с точки зрения CIL или результирующего машинного кода?
Оба примера не дают _гарантированно_ ни того ни другого. Я про CLI для начала (на уровне байт-кода)
кто-кто, а линуксоид такую фразу сказать не может
Почитай что-нить про unixway
Редактировался whoknows (28-07-10 18:56:40)
Оба примера не дают _гарантированно_ ни того ни другого. Я про CLI для начала (на уровне байт-кода)
Эт да. На самом-то деле да) Но четкий ответ требует размышлений. Может на днях поэкспериментирую - напишу сюда.
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Собственно я только что подписался на эту тему.
Всё прочитать не осилил, так как спать охото и в сях я не понимаю.
Моё мнение:
Баги - это следствие того что сознание упускает подробности функционирования замысла, то есть воображение не проводит трассировку проекта. Касаемо больших проектов, нужно много ремарок, подробных описаний функций, классов и т.д.
В случае риска возникновения несовместимости, надо не делать костыль и писать код под баги модулей. А надо переписать этот модуль и весь наработанный под его баги код. Естественно лень, влом и впадлу. Но ведь если это не сделать, то будет в коде дыра, которую потом несколько лет не смогут закрыть.
Собственно, большие проекты в Linux этим страдают и ядро особенно (тонны кода), в данном случае уместен переход на систему плагинов. Да это снижает производительность. Но unix-way изначально отдаёт предпочтение масштабируемости и переносимости.
Ведь вспомните, c++ был изначально побочным продуктом написания unix. И если бы существовали в то время высоко уровневые языки с низко-уровневымы конструкциями, то такого явления и не появилось бы.
Но ведь изначальный смысл был в абстракции от железа и возможности писать программы под любую платформу. А что получилось....?
Не ламерствуй лукаво.
"А петь мне нельзя - постановление суда" (с) Бендер
Неактивен
Но ведь изначальный смысл был в абстракции от железа и возможности писать программы под любую платформу. А что получилось....?
А был ли изначально такой смысл у С++.
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Дело в том, что его авторы однажды испытали неудобство всвязи с тем что при смене оборудования пришлось переписывать заново какую то игрушку, Вот они и решили на будущее облегчить себе труд.
Не ламерствуй лукаво.
"А петь мне нельзя - постановление суда" (с) Бендер
Неактивен
Гареев Станислав, вы путаете C++ с C
что именно так он и разрабатывается независимо от языка программирования, все что по другому именно и есть былокодерство.
Пашок, не все программы имеют "морду лица"
и он не утешительный для тебя- ты тупорылый школоло оболваненый луноходами, неофит их секты крсноглазых задротов.
А что можно сказать в твой адрес, читая такой коммент?
Понимаешь, если бы у тебя это книга не лежала на полке, а ты ею бы реально пользовался и работал в среде VB6, то ты бы понял почему так делается. Это во первых, во -вторых, если бы ты реально хотя бы раз участвовал или видел, как разрабатывается софт, то ты бы с удивлением узнал, что именно так он и разрабатывается независимо от языка программирования, все что по другому именно и есть былокодерство. Ну и в третьих в софтверных компаниях даже должность такая есть- дизайнер интерфейсов. Судя по тому что ты ничего из вышепреведенного никогда не видел и не знаешь, то можно легко сделать вывод кто ты на самом деле, и он не утешительный для тебя- ты тупорылый школоло оболваненый луноходами, неофит их секты крсноглазых задротов.
Дело в том что я как раз по этой книге и освоил Visual Basic
Собственно пока учился в школе, сделал одно учебное приложение (экзаменатор) работающий по сети. Хотя конечно приложение было жутко дырявым (поскольку работало через сетевые шары) но оно использовалось несколько лет. И не только в той школе, я его ещё высылал по емайлу в какую то поселковую школу. Я о том, что я прекрасно знаю специфику разработки на этом языке. Собственно, я на этом языке делал небольшие утилитки на заказ и всякую дребедень.
Я конечно не против разработки красивых интерфейсов, но я считаю что гуй должен быть в большинстве случаев лишь фронт-эндом.
Не ламерствуй лукаво.
"А петь мне нельзя - постановление суда" (с) Бендер
Неактивен
но я считаю что гуй должен быть в большинстве случаев лишь фронт-эндом.
Разработка пользовательского интерфейса - носит очень важный характер. Понимаешь, вот ты пишешь, что "ну я считаю что буй гуй должен быть в большинстве случаев лишь..."
Так же к этому относятся многие. На самом деле есть при разработке интерфейсов ряд правил и еще должно быть дофига опыта. Но, даже зная об этом, будут ли разработчики нанимать (хотя бы консультироваться) специального человека дизайнть интерфейс? Или каждый сам с усами?
А что делать? Ознакомтесь, отличная книжка, программерам советую хотябы один раз за жизнь прочитать что-то подобное:
https://uibook2.usethics.ru/uibookII.pdf
Редактировался Tiphon (29-07-10 10:46:25)
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
dondublon3 пишет:А еще через 10 лет список желательных примитивов будет еще существенно расширен. В него добавятся, как минимум, одномерные массивы.
Это уж 40 лет как примитив. Даже на уровне процессоров
И опять-таки нет. Такая же история как со строками - есть стандартный char*, но он ужасен. Есть стандартный массив, но без указания длины. Поэтому и массивы делают кто во что горазд - в boost один, в delphi другой, в D наверняка третий.
DonDublon3 пишет:QThread из Qt, потоки в Питоне, TThread в delphi..)
Ты мешаешь всё в кучу. Qt - это библиотека. Python/Delphi - языки программирования. Что обсуждаем? Как связать динамически линкуемые библиотеки, написанные на разных языках и скомпилированные разными компиляторами?
ОБщее между Qt и Delphi - что и там и там создатели сделали свой класс строк, т.е. как раз по теме разговора. В Питоне тоже, он он все-таки не нативный, так что ну его.
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#, но уверен на стопудов, что существенно проще.
"Фу бля, крохобор вонючий" (с) Svart Testare
Неактивен
А ведь дотнет может классы. Уж не знаю точно, как будет вестись передача между php.net-F# или IronPython-F#, но уверен на стопудов, что существенно проще.
Да конечно просто:
https://geekswithblogs.net/MarkPearl/arc … -talk.aspx
https://www.chrisumbel.com/article/scrip … python_dlr
К тому же, есть очень удобные механизмы обмена данным между процессами. Как раз нормальными классами.
https://www.dotnetheaven.com/UploadFile/ … hange.aspx
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен