copal
> во всех декларациях которые я использую код выглядит вот так ...
да, действительно странно. TS так не делает.. Возможно заморочки из-за commonjs-экспортов. Вообще результат из первого куска куда более чем приемлемый, собтвенно все как и должно быть. Чтобы решить проблему с export = MyLib могу предложить такой изврат: компильте основной бандл с кодом и d.ts в два прохода с разными tsconfig.json: первый проход как сейчас, БЕЗ генерации деклараций, а второй - с генерацией деклараций и с параметром outFile. В самом файле, указанном в outFile ничего толкового не будет, а вот декларации должны сгенериться и смержиться (!) в один файл (только с расширением d.ts). Я совсем не уверен, что это корректный способ и что не вылезут неприятности, но сам TS довольно неплохо мержит d.ts , если компилить с ключом outFile.
> фиг его знает что Вы собирали им, наверное hello word.
Да вроде побольше будет, чем хеллоуворлд, не знаю что у вас за проблемы такие.. Спрошу, как будет возможность, может тулу поменяли потом, или структура зависимостей у вас другая..
А собственно проясните всё-таки ситуацию. Какую модульную систему вы используете? Чем бандл собираете (иначе зачем вам мержить декларации)? Там вроде если amd или system, то TS сам вам и js-файл смержит, и d.ts тоже, могу демку сделать.
copal почему же из кода? Эта тула вроде только готовые d.ts умеет клеить. Т.е. сначала просишь TS сгенерить их, потом этой тулой склеиваешь. У нас вроде как сейчас glob стоит на все d.ts в сборочной директории (что-то вроде output/**/*.d.ts)
IPv4 Как насчёт OpenRead? Вероятно, из потока, который вернет эта функция, можно будет читать до того, как скачается весь файл. Тогда вы сможете дописывать файл частями (допустим, по 1 кб), и все будет сохраняться.
Какой конкретно метод у веб-клиента вы вызываете, что он файл перезаписывает? Может надо куда-нибудь в поток сначала качать, а потом уже самому в файл писать? В чем сложность? Никаких bak-ов создавать не надо, это муть.
xibir что ж тут непонятного - я хотел вас посильнее напугать, что дотнетзараза добралась и до Линуха). Впрочем, вы правильно делаете, что сохраняете спокойствие - дотнет сам по себе Линух не отравит)
voayagen1 для хорошего спеца конкретное API - это детали. Знать/не знать конкретный язык программирования - это еще можно понять, но API - это не проблема для "спеца". Да, виндовое API не самая приятная и легкая вещь на свете, но самое сложное - это концепции. А они везде похожи (например: цикл сообщений, синхронный/асинхронный ввод/вывод и т.д.).
> микрософту C++ как собаке пятая нога
и именно поэтому они выкатывают багфиксы и апдейты к VC++ каждые несколько месяцев)
> от него везде избавляются, продвигая свою дотнетозаразу
знаете, еще лет 8 назад я бы даже согласился с вами насчёт политики MS, но сегодня 2016 год, вот буквально 3 дня назад .net core зарелизился наконец, с полноценной поддержкой всех популярных дистрибутивов Линуха. Так что у меня для вас плохие новости - ваши знания устарели на
> несколько лет назад
Lindon_cano почему же глупость? Что вам мешает вместо VPN поднять прокси там же, и пускать через него браузер? Стим же, слава богу, не блокируется Роскомнадзором. Там тех сайтов раз два и обчелся.
Интересно, а что вы конкретно сделали, когда я предложил вам указать пути в настройках линкера? Какой "другой способ подключения", если он - единственный?
alex_deerk вообще на будущее: старайтесь выкладывать вместе с кодом еще и декларации используемых в нём переменных/полей класса. Да и вообще сущностей, встречающихся в коде. C++ очень гибок, некая переменная может быть указателем, а может быть указателем на массив указателей на указатели, поэтому сначала приходится "компилировать" код в голове, понимать какие типы данных у переменных, а потом заново всё осмысливать. Тем более что в таком виде как у вас в продакшене кода не будет - никто без особых причин не будет игнорировать стандартный класс вектора и пользоваться вместо него "сишным" массивом на куче.
alex_deerk неудобно делать выводы, когда вообще не видишь, какой сейчас тип у places :). Ну раз код new Patient[count_places] компилируется, то очевидно тип places это Patient*.
> а какой тогда должен быть тип places? двойной указатель?
Да. А лучше - вектор из указателей, т.е. std::vector, но раз вам стандартную библиотеку нельзя, то да, Patient** places. Тогда вы сможете присвоить places указатель на массив (!) указателей на Patient, т.е. places = new Patient*[count_places]; И тогда вместо
>places[0] = p;
будет places[0] = &p; ну или если вы передадите параметр как указатель, а не как ссылку, т.е. Patient *p вместо Patient &p, то будет просто places[0] = p;
Напоминаю, что весь этот сыр бор нужен, если вам действительно нужно работать с Пациентом, как с объектом.
> А в прошлом варианте places = &p; я разве не участок памяти присваиваиваю, то есть тот указатель который вне данного метода и указатель places указывают на один и тот же объект?
Да, вы верно это понимаете (фразу "участок памяти присваиваиваю" я читаю как "указатель на участок памяти присваиваю", верно?), мне там привиделось разыменование (places = *p), а не взятие адреса. Привиделось потому, что вы берёте и сохраняете в places адрес объекта, пришедшего извне, и его дальнейшая судьба не вполне ясна. Если вы передадите в функцию addPacient объект, находящийся в куче, и он будет жить как минимум столько же, сколько вы с ним работаете через указатель в places, то всё будет в порядке. Если объект будет создан на стеке, и после добавления в places будет разрушен, то попытка работать с ним после его разрушения ни к чему хорошему не привёдет. Откуда приходит объект Pacient в функцию addPacient - известно только вам).
