Суббота, 23 Ноября 2024, 10:42

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 1 из 2
  • 1
  • 2
  • »
Конвертирование вектора (списока) в строку.
RDeviceДата: Пятница, 11 Декабря 2015, 20:56 | Сообщение # 1
был не раз
Сейчас нет на сайте
У меня возникла проблема, используя вот такой код:
Код

    std::vector<char> Data;
    Data.push_back('6');    

    char* Array = new char[(int)Data.size()];
    memcpy(Array, &(Data[0]), sizeof(Data[0]));


И на выходе получаю:
Код

Array    0x03fa2160 "6ээээ««««««««юоюоюою"    char *


Следовательно, вопрос:
Как это сделать по другому?
Без части, что идет после '6?

Не предлагать (результат тот же):
Код

Array = &Data[0];
Array = Data.data();

Добавлено (11 декабря 2015, 20:56)
---------------------------------------------
Упс, накладочка вышла...
У меня есть подобный код, сорь.

Код

    char* ToChar()
    {
        return (char*)(new std::string(Data.begin(), Data.end()))->c_str();
    }
YellowAfterlifeДата: Пятница, 11 Декабря 2015, 21:36 | Сообщение # 2
Сейчас нет на сайте
Цитата RDevice ()
Без части, что идет после '6?

Полагаю, это были случайные данные за концом строки (так как '\0' не был добавлен после данных для явного окончания строки).


SaiteiДата: Пятница, 11 Декабря 2015, 21:49 | Сообщение # 3
старожил
Сейчас нет на сайте
Код
char* to_char_array(const std::vector<char>& vec)
{
    char* result = new char[vec.size() + 1];
    std::copy(vec.begin(), vec.begin() + vec.size(), result);
    result[vec.size()] = '\0';
    return result;
}
RDeviceДата: Понедельник, 21 Декабря 2015, 02:04 | Сообщение # 4
был не раз
Сейчас нет на сайте
Спасибо за ответы, ребят.

Добавлено (21 декабря 2015, 02:04)
---------------------------------------------
Нашел метод, при помощи которого после создания char* можно будет его удалить:

Код

#define STRING_SIZE 128

char* String::operator & ()
{
    std::string Text(Data.begin(), Data.end());
    char* Array = new char[STRING_SIZE] { 0 };

    for (int i = 0; i < Text.length(); i++)
        Array[i] = Text[i];

    std::string().swap(Text);

    return Array;
}


Код

char* Четотам = &String("Hello, world!");
delete[] Четотам;


- В итоге, после этих действий, память не растет
- Минусы - фиксированный размер строки (STRING_SIZE = 128), выставленный перед сборкой, иначе строка записывается неправильно


Сообщение отредактировал RDevice - Понедельник, 21 Декабря 2015, 02:55
GudleifrДата: Понедельник, 21 Декабря 2015, 11:01 | Сообщение # 5
почти ветеран
Сейчас нет на сайте
Оффтоп! Хороший пример того, за что я не люблю C++. Есть "просто строка, заканчивающаяся нулем", но за то, чтобы иметь возможность смотреть на нее "с нужной стороны" C++-программист согласен нести жуткие издержки. Конечно, и в C++ можно иметь дело с "просто строкой", но почему-то это (работа с "просто данными") первое, от чего отучаются C++-программисты.

Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
OpenGOOДата: Понедельник, 21 Декабря 2015, 19:34 | Сообщение # 6
почти ветеран
Сейчас нет на сайте
Работать с С строками, это и есть издержки.
Цитата RDevice ()
delete[] Четотам;


Мои проекты:
- Свободный и открытый клон World Of Goo
- TrueEngine2D (2D игровой фреймворк основанный на FreeBASIC)

[GameMaker: Studio v1.4.9999]
GudleifrДата: Понедельник, 21 Декабря 2015, 19:50 | Сообщение # 7
почти ветеран
Сейчас нет на сайте
Цитата OpenGOO ()
Работать с С строками,
К счастью, никаких "C строк" не бывает. C пользуется Unix-библиотекой (или ее эмулятором) для работы с Unix-строками.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
OpenGOOДата: Вторник, 22 Декабря 2015, 11:43 | Сообщение # 8
почти ветеран
Сейчас нет на сайте
Unix на каком языке был написан или может Unix это язык программирования? Уточню что имел в виду под С строками, строки в стиле С (C-style strings)

Мои проекты:
- Свободный и открытый клон World Of Goo
- TrueEngine2D (2D игровой фреймворк основанный на FreeBASIC)

[GameMaker: Studio v1.4.9999]


Сообщение отредактировал OpenGOO - Вторник, 22 Декабря 2015, 12:07
GudleifrДата: Вторник, 22 Декабря 2015, 12:13 | Сообщение # 9
почти ветеран
Сейчас нет на сайте
OpenGOO, Unix - ОС, содержащая, как и положено хорошей ОС, библиотеки (в т.ч. работы со строками). На чем она написана, в данном случае не важно. (На C написано много игр, но не считаем же мы их частью языка). Язык C, "взятый в вакууме", никаких "собственных" библиотек не имеет. Это как считать, что С под DOS включает INT 21h.
Я встречал дебилов, заявлявших, что они пишут "свою операционку", используя "stdio.h", но, ведь, в отсутствие ОС нет никаких описанных там ф-ий.
Цитата OpenGOO ()
C-style string
Вы видели в описании языка тип string? Этот "термин" родился как тупое средство отличать строки, заканчивающиеся нулем (Unix) от строк со счетчиком (Pascal-style). Нет никакого запрета, окромя религиозных, использовать в C-программах строки со счетчиком. C пофигу.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
DaeloceДата: Вторник, 22 Декабря 2015, 12:17 | Сообщение # 10
был не раз
Сейчас нет на сайте
Раз уж пошел оффтоп.

Цитата Gudleifr ()
Конечно, и в C++ можно иметь дело с "просто строкой", но почему-то это (работа с "просто данными") первое, от чего отучаются C++-программисты.


Если под "простой строкой" вы понимаете char*, то я вам скажу почему "это первое, от чего отучаются C++-программисты". Потому что за использование указателей на чары вместо string нужно не то что бить по рукам, а лишать права подходить к компьютеру ближе чем на пару метров. Потому что после таких вот советов, плюсовый код превращается даже не в Си с классами, а в нечитабильную лапшу из смеси malloc, new, free, delete, char*, string и прочего. Практически не существует случаев, при которой нужно использовать сырые указатели вместо string'а(вызов сишных библиотек не в счет).


Сообщение отредактировал Daeloce - Вторник, 22 Декабря 2015, 12:18
GudleifrДата: Вторник, 22 Декабря 2015, 12:22 | Сообщение # 11
почти ветеран
Сейчас нет на сайте
Daeloce, да, именно так это обычно и формулируют (даже в учебниках). Однако, найти в программах "нечитабельную лапшу" из умных указателей обычно не труднее, чем из сырых. Плюс ошибки "от ума". "А, если нет разницы, зачем платить больше?"

Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
DaeloceДата: Вторник, 22 Декабря 2015, 12:47 | Сообщение # 12
был не раз
Сейчас нет на сайте
Gudleifr,

Цитата Gudleifr ()
найти в программах "нечитабельную лапшу" из умных указателей обычно не труднее, чем из сырых.


Естественно, говно-код он есть везде, я нечитабельную лапшу даже на шарпе с джавой видел, а там её породить надо умудриться я вам скажу. Вот только нужно смотреть не количество кривых программ, а наоборот. И читабельных программ на С++ где используются char*'ы с malloc'ами не существует(точнее как, существуют естественно, вот только эти программы обычно без модификаций компилируются чисто сишным компилятором :)). Поэтому во всех руководствах/учебниках и в любой нормальной команде разработчиков есть простое как 3 рубля правило: если ты пишешь на С++, то ты обязан использовать STL(или аналогичные библиотеки в случае их использования, например Qt). И каждое написание собственного вектора, использование динамического массива или указателя на чар должно быть четко обосновано, с точки зрения невозможности использования готовых вариантов из стандартной библиотеки.
GudleifrДата: Вторник, 22 Декабря 2015, 12:59 | Сообщение # 13
почти ветеран
Сейчас нет на сайте
Цитата Daeloce ()
И читабельных программ на С++ где используются char*'ы с malloc'ами не существует(точнее как, существуют естественно, вот только эти программы обычно без модификаций компилируются чисто сишным компилятором :))
Правильно!
Цитата Daeloce ()
Поэтому во всех руководствах/учебниках и в любой нормальной команде разработчиков есть простое как 3 рубля правило: если ты пишешь на С++, то ты обязан использовать STL(или аналогичные библиотеки в случае их использования, например Qt).
И опять правильно!
Какой же вывод? Только один: C++ ничего не стоит как язык. И правильный способ его использования: не-ОО код, вызывающий ОО-библиотеки ("быдлокодерский", в отличие от "классического" - честное ООП; и "чтоб было" - замена ненужных struct на ненужные class).


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
DaeloceДата: Вторник, 22 Декабря 2015, 13:08 | Сообщение # 14
был не раз
Сейчас нет на сайте
Цитата Gudleifr ()
Правильно!


Вот только это никакого отношения к С++ не имеет. Это чистый Си.

Цитата Gudleifr ()
Только один: C++ ничего не стоит как язык.


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

Цитата Gudleifr ()
И правильный способ его использования: не-ОО код, вызывающий ОО-библиотеки ("быдлокодерский", в отличие от "классического" - честное ООП; и "чтоб было" - замена ненужных struct на ненужные class).


Нет, это неправильный способ. Правильный способ написания С++ программ, это ООП. Если вам не нужен ООП, вам не нужен С++(не всегда так, я сам например в HPC программах смешиваю плюсы и си, но это исключение, а не правило). Весь коммерческий и серьезный плюсовый код пишется в ООП стиле. Ну а ваши заявления о "правильном способе" расскажите Страуструпу и Александреску! smile
GudleifrДата: Вторник, 22 Декабря 2015, 13:19 | Сообщение # 15
почти ветеран
Сейчас нет на сайте
Цитата Daeloce ()
Что-то я не уловил перехода от сказанного мной к такому выводу.
Ну как же? Вы сами написали, что читабельность C выше "не-ОО C++" и что применение ООП допускается только в виде исключения ("должна быть доказана его необходимость").
Цитата Daeloce ()
Весь коммерческий и серьезный плюсовый код пишется в ООП стиле.
Ни разу не видел такого (окромя учебников). Всегда одно и то же (как у Вас): сплошные отмазки по поводу неспецифичности задачи и практической необходимости делать "через массивы". Страуструп и Парнас были жуткими идеалистами.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
DaeloceДата: Вторник, 22 Декабря 2015, 13:34 | Сообщение # 16
был не раз
Сейчас нет на сайте
Цитата Gudleifr ()
ы сами написали, что читабельность C выше "не-ОО C++" и что применение ООП допускается только в виде исключения ("должна быть доказана его необходимость").


Вы не верно прочитали, что я написал, перечитайте. Мой посыл: читабельность С выше чем "не-ОО С++", поэтому НЕ использование ООП допускается только в виде исключения. По умолчанию код на С++ должен быть ООП.

Цитата Gudleifr ()
Ни разу не видел такого (окромя учебников). Всегда одно и то же (как у Вас): сплошные отмазки по поводу неспецифичности задачи и практической необходимости делать "через массивы".


Прежде чем такое утверждать, нужно хотя бы уточнить, проекты какого уровня вы вообще видели на ++. Возьмите например Qt, открытая С++ библиотека, и посмотрите как она написана. Не видел почти ни одной серьезной программы на ++ в которой использовались бы голые динамические массивы. Даже в случаях когда существующие контейнеры не годятся по той или иной причине, пишутся свои контейнеры, которые скрывают эти самые голые динамические массивы(надеюсь не надо объяснять, что в конечном итоге, STL'ные контейнеры это тоже обертки над динамическими массивами? smile ). Если что у меня 7 летний опыт комерческой разработки на ++, я видел код таких компаний как Sony Ericsson, Samsung и Motorola.

Цитата Gudleifr ()
Страуструп и Парнас были жуткими идеалистами.


Вы уже Страуструпа похоронили, или почему он "был жутким идеалистом"? От ++ он не отказывался, продолжает их развивать и вроде как заявлений о "правильном не-ОО стиле написания программ" я от него не слышал.
GudleifrДата: Вторник, 22 Декабря 2015, 13:57 | Сообщение # 17
почти ветеран
Сейчас нет на сайте
Цитата Daeloce ()
По умолчанию код на С++ должен быть ООП.
Выше Вы допускали выход за пределы STL и Qt только в виде исключения.
Цитата Daeloce ()
Прежде чем такое утверждать, нужно хотя бы уточнить, проекты какого уровня вы вообще видели на ++.
Без комментариев. Единственное, что могу сказать - они были большими и обрабатывали сложные данные, от них требовались запредельное быстродействие и практическая безотказность. Иногда по отдельности, иногда разом.
Цитата Daeloce ()
Возьмите например Qt, открытая С++ библиотека
Удачный пример. Пожалуй, самая дебильная библиотека работы с графикой. Нет, я конечно знаю, что начиная с первых экспериментов XEROX никто так и не предложил не-ОО визуальный интерфейс, но зачем было доводить до абсурда? Мегабайты пустых фантиков при минимальной функциональности. Воистину, торжество ООП над разумом... Но опять же, посмотрим внимательно. Вызовы этой библиотеки честно ОО (как и положено для использовании "быдлометода" пользователями), но насколько "вглубь" библиотеки распространяется эта ОО? Ведь она должна конфликтовать, например, с кривенькой ОО Win-API. Вы уверены, что там нет прослойки "не-ОО быдлокода" как в Visual Studio и Borland?
Цитата Daeloce ()
Вы уже Страуструпа похоронили
Да. После того, как во втором издании он поделился мечтами о классическом ООП, в третьем центр тяжести был перенесен на "быдлокод" - STL.
Цитата Daeloce ()
Если что у меня 7 летний опыт комерческой разработки на ++, я видел код таких компаний как Sony Ericsson, Samsung и Motorola.
У меня - более 30. И я не только видел, но и ломал код перечисленных компаний. Замнем.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Вторник, 22 Декабря 2015, 13:58
DaeloceДата: Вторник, 22 Декабря 2015, 14:25 | Сообщение # 18
был не раз
Сейчас нет на сайте
Цитата Gudleifr ()
Выше Вы допускали выход за пределы STL и Qt только в виде исключения.

Не выход за их пределы, а использование сущностей со схожим функционалом вместо них. Т.е. использование динамического массива вместо vector'а действительно должно быть очень существенно обосновано. Как из этого вы вынесли "не-ОО" стиль, я по прежнему не понял.

Цитата Gudleifr ()
Пожалуй, самая дебильная библиотека работы с графикой.

Вообще-то одна из лучших библиотек, как графических так и общего назначения(те же контейнеры в ней на много удобнее чем STL'ные). Вы на ней что-то сложное писали, чтобы так утверждать? Я писал, и пишу. И много.

Цитата Gudleifr ()
но насколько "вглубь" библиотеки распространяется эта ОО?

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

Цитата Gudleifr ()
Вы уверены

Уверен. Я не однократно правил их исходники и слал им патчи.

Цитата Gudleifr ()
был перенесен на "быдлокод" - STL.

То что STL - "быдлокод" это пока что ваше голословное утверждение. STL это как раз то самое ООП которое вы так тут обличаете. И автор языка(как и все выдающиеся программисты, что Александреску, что Макконел, что десятки других) использует с++ только с ООП парадигмой.

Цитата Gudleifr ()
У меня - более 30. И я не только видел, но и ломал код перечисленных компаний. Замнем.

Какое отношение "ломание" кода имеет к нашему разговору? Или вы его "ломали" получая исходники? Я видел исходники продуктов этих компаний. И там сплошной ООП. И да, у вас 30 лет коммерческой разработки на ++? Если нет, то опять же какое это имеет отношение к нашему разговору? Хоть 30, хоть 60 лет коммерческой разработки например на Си, ни на грамм не добавят вам опыта и видения проектов на С++.

Давайте обозначим тему разговора. Если вы мне хотите доказать что С++ ущербный язык, что Си/Smalltalk/D/Ada/...(подставить нужный язык) лучше и нужно использовать их, то я предлагаю закончить эту дискуссию, она не имеет смысла. Если же вы хотите меня убедить, что правильное использование С++ это использование его в "не-ОО" стиле, и в таком виде он на много удобнее/красивее/лаконичнее/т.п., то чтобы мы как-то перешли в конструктивное русло, приведите мне пример С++ приложения(более или менее коммерческого, школьные поделки меня мало интересуют), написанного в "не-ОО" стиле. Пометка, изначально С++ приложения, потому что есть ряд софта(например gcc) который лишь недавно стал формально ++ софтом, что естественно не может являться образцом стиля разработки на С++. Вместо примера софта, вы можете привести книги авторов, уровня Макконела или Александреску, которые бы утверждали что "не-ОО" стиль написания С++ программ - верный. Наконец, если же вы пытаетесь донести до меня исключительно ваше мнение, то опять же давайте перейдем в конструктивную область, и обсудим преимущества и недостатки обоих подходов, а то все это выливается в пустое припирание.
GudleifrДата: Вторник, 22 Декабря 2015, 14:41 | Сообщение # 19
почти ветеран
Сейчас нет на сайте
Daeloce, речь не о том, как писать на C++ "правильно", а о том, что писать на нем иначе невозможно ("классический" способ не работает, способ "чтобы было" слишком затратен). Конечно грубо утверждать, что Вы "смотрели в книгу, а видели фигу", но, думаю, этого, к счастью, и не требуется. Еще надцать лет попишете (как сейчас) код, к которому нельзя по очевидным причинам прицепить ООП, и сами по другому посмотрите на "красивый код общепринятых классиков".

P.S. Почему я обзываю STL "быдлокодом"? По причине его убожества. Например, каждый человек, сталкивавшийся с большими объемами данных, помнит табличку:

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


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Вторник, 22 Декабря 2015, 14:42
DaeloceДата: Вторник, 22 Декабря 2015, 14:58 | Сообщение # 20
был не раз
Сейчас нет на сайте
Цитата Gudleifr ()
а о том, что писать на нем иначе невозможно

Это как раз мой второй предложенный вариант. Соответственно прошу примеры проектов/книги авторов, которые бы доказывали ваше утверждение.

Цитата Gudleifr ()
Еще надцать лет попишете (как сейчас) код, к которому нельзя по очевидным причинам прицепить ООП,

Спасибо, но я пишу на ++ код, к которому не то что можно прицепить ООП, но который с использованием только этого самого ООП и написан.

Цитата Gudleifr ()
И какой процент этого покрывает STL?

Ну например бинарные деревья, это map. НО. Этого и не должно быть в STL, ибо область применения подобных алгоритмов крайне специфична, и либо они берутся из соответствующих HPC библиотек, либо пишутся самим программистом. Но даже в случае самостоятельного написания данных контейнеров, в нормальном С++ проекте, вам не позволят работать с голыми массивами, вы должны будете их обернуть в свой собственный my_very_hpc_vector, который будет инкапсулировать голый массив и скрывать его от пользователя вашего вектора.

Цитата Gudleifr ()
Так что, STL просто "защищает" пользователя от данных вместо того, чтобы получить к ним доступ в нужной для него форме.

Естественно. Это и есть ООП. И снова я возвращаюсь к вопросу, вы вообще в курсе что такое ООП?
  • Страница 1 из 2
  • 1
  • 2
  • »
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг