- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
#include <iostream>
#include <vector>
#include <memory>
using namespace std;
struct i
{
virtual void g() = 0;
};
struct c:i
{
virtual void g() {}
};
struct ic
{
virtual void f(const std::vector<std::shared_ptr<i>>& a) = 0;
};
struct tc:ic
{
virtual void f(const std::vector<std::shared_ptr<i>>& a)
{
for(auto&& k: a) k->g();
}
};
int main() {
vector<shared_ptr<c>> k;
tc a;
a.f(k);
cout<<"ok"<<endl;
return 0;
}
Follow us!
Тогда и слов таких не знали наверное (я вот и сейчас не знаю).
Вообще, в реальном коде, я уверен что было что-то вроде такого: http://coliru.stacked-crooked.com/a/3e0aec08a554a4bf
Но так как предназначение кода не ясно и теоретически потомок может не хотеть там цикла, сделаем по другому. Так как тут уже shared_ptr и интерфейсы с виртуальными функциями, то на пирфоманс нам насрать.
Получается так: http://coliru.stacked-crooked.com/a/b1db9770b8f33cc0
А вот первый - плохо. Разбомбил виртуальные функции, тут может и не важно, но где-то может быть важно
https://ideone.com/55z8Hz
http://ideone.com/rT4ttC
ну, да ладно, у меня есть варик потупей
http://ideone.com/RqCxfU
upd: а, бля, уже запостили аналогичное
Копирование стопитсот элементов вектора? ну хрензнает
да, было бы приятно если бы работало. но с другой стороны, у меня мало сочувствия к клепателям пяти-этажных темплейтов и прочего. или как говорили классики: Inside every large problem, there is a small problem trying to get out.
Плохо. Хочу хранить в майне мост дерайвед потомка c. Мне доступ к его шаблонным методам нужен
ага. а я видел как люди гвозди феном забивали
> хавает vector/list/deque/
Во-первых, какой это эррей, если хавает список. Во-вторых, все варианты не предусмотришь. Есть, например, еще boost.containers и boost.intrusive, ты в курсе? В-третьих, это не перфомансно.
да написан он давно. boost::any_range, но это все в итоге костыли и от отсутствия нормальной поддержки в крестах полиморфизма не спасает
как и всегда делают крестовики: нет в языке, значит оно не нужно. Примерно это меня ждет.
А так то реализации ко\контр в крестах нет и вменяемую на базе шаблонов сделать проблематично. Генерики бы помогли, но их в кресты никогда не завезут
Ну можно так например. Как видишь компилируется без всяких преобразований. Полиморфизм есть в языке
в крестах они как бы уже "есть": список указателей на интерфейсы + dynamic_cast( + опционально throw если что не то). потому что генерики именно это и реализуют, и именно так себя ведут. но бля dynamic_cast он же как goto: его религия не позволяет...
Аллокации, векторы, поинтеры какие-то.
Вот потому всё больше людей выбирает PHP. Там вообще ничего знать не надо. Бери себе код с интернета, да копируй
они любовники
Ид аль-Адъхьа мубарак!
http://coliru.stacked-crooked.com/a/f869a306c93fbf56
В добавок нельзя иметь контейнер с указателями на абстрактный интерфейс: каждый "интерфейс" на самом деле свой класс.
В общем, если архитектуру приложения разрабатывал жабист, то так не покатит.
Да, это так, в точке инстанцирования компилятор должен знать конкретный передаваемый тип. Другое дело, что часто все уже известно на этапе компиляции и виртуальные функции кроме как оверхеда ничего не дадут.
>> В добавок нельзя иметь контейнер с указателями на абстрактный интерфейс: каждый "интерфейс" на самом деле свой класс.
Тут вы неправы, вот пример: http://coliru.stacked-crooked.com/a/7bca0150ba91a374
Объявлен вектор указателей на абстрактный класс, добавляются элементы разных типов, узнаваемые в рун-тайме. Или что-то другое имелось в виду?
В общем случае да, для абстрактной архитектуры в вакууме не подойдет, но в некоторых случаях очень даже, учитывая перформанс. Из минусов - раздутый бинарник за счет инстанцирования классов для всех возможных входных типов.
Еще один минус в том, что это нечитаемая параша.
из минусов это будет компилятся полчаса на каждый спп фаел
блин. меня опередили...
нахуй так жить. лучше сразу вдоль лучше сразу перебраться на другой язык.
Борми, а что скажешь тут про раст? он как разрулит эту проблему? никак же?
Береш код на С# из поста
http://ideone.com/PNIH9b
запускаеш тулзу от сюдава https://github.com/ASDAlexander77/cs2cpp и все. Нихрена делать не нада
Пример из http://ideone.com/PNIH9b сконвертировался лишь с явным приведением типа: вместо
При этом компилятор (как родной от фреймворка для C# 5, так и от MSBuild 14.0) спокойно принимает исходник без явного приведения типа.
ГОВНО
Кстати, где nackaJIb?
ах
initgraph(gd, gm, '');
Я (и Инканус) кому-то из спамеров понравился
Дело было правда на си, но сути это не меняет. Асм мне был почти не нужен: у меня была запись в память (через присваивание значения указателю), были API для I/O и для INT, причем послднему можно было передать структуру со значниями регистров)
у борланда для поскаля и сей были совершенно одинаковые API для всего практически
ну если что-то можно было в турбо си то можно было и в турбо паскале наверняка
ps: тем паче что прерывания (DOS, BIOS) с передачей параметров через регистры, IO (железа) и писяние в память (того же самого железа) это были три главные API во времена ДОСа
Потому доступ к ним был даже из QBASIC, например
И уж конечно он был из промышленных компиляторов
О достойнейший, не поможете ли мне, старому джинну, наверстать хронологию? Что с капчей?
На деле, антигейтом она обходится все так же как два пальца обоссать
Вот мой друг Волька такого никогда себе не позволял.
Ох, как мне было хорошо с моим Волькой... Он был пионером, прилежным, в галстучке. Сколько же лет назад это было...
Мне грустно от мысли, что от моего друга, пожалуй, и костей не осталось...
Наверно он уже старенький, а я помню его совсем маленьким мальчиком, в тщательно выглаженной форме.
О, мой бедный Волька!..
p,s, Капча сейчас - shzk... ;(
http://s011.radikal.ru/i318/1704/f9/8201507957e9.png
Я не поскалист, я не знаю
http://www.standardpascal.org/compiler.html
GPC и FPC могут работать в режиме, максимально совместимом со стандартным Паскалем, но это всё равно не то.
Значит, нужно смотреть, что умеет P5.
А ISO/IEC 10206:1990 Extended Pascal будем считать чистым Паскалем или нет? Это уже не Standard Pascal, но ещё не Object Pascal (TP/Delphi).