Показать полную графическую версию : [решено] cannot convert 'std::string {aka std::basic_string<char>}' to 'const char*'
Всем привет!
Работаю с плюсами недавно, перехожу с PHP, и уже понял, что знакомство будет долгим :D
Возникла проблема с разными типами данных в разных функциях.
Вот у меня имеется простенькая функция:
string read_file (string file) {
return file;
}
Ее вывод такой:
cout << read_file ("C:/ru.ini");
То есть я засовываю в нее строку. Все работает отлично. Но если в ней попытаться запустить еще одну какую-либо функцию, например
string read_file (string file) {
FILE *fp = fopen (file, "rb");
return file;
}
возникает ошибка
cannot convert 'std::string {aka std::basic_string<char>}' to 'const char*' for argument '1' to 'FILE* fopen(const char*, const char*)'
То есть как я понял, в fopen должно суваться char, а я пытаюсь сунуть строку, ибо у меня введена строка.
Что тут можно сделать? Затыкнулся в самом начале)
Заранее благодарен!
То есть как я понял, в fopen должно суваться char, а я пытаюсь сунуть строку, ибо у меня введена строка. »
Не совсем. Нужно не char, а char*. Это наследие языка C, где не было типа данных "строка". Строки там представлялись как символьный массив завершаемый нулевым символом. Но типа данных "массив" в C тоже нет, так что используется их более низкоуровневое представление как указателя на первый элемент. Так что ничего удивительного, что функция, ожидающая получить указатель на символ, начинает ругаться получив объект класса string (обратите внимание, что string это именно класс).
Попробуйте воспользоваться методом c_str (http://www.cplusplus.com/reference/string/string/c_str/). Скорее всего поможет.
Попробуйте воспользоваться методом c_str. Скорее всего поможет. »Если редактор юникодный то иногда вместо c_str(), канает t_str()
torauma, Drongo, большое спасибо!
Честно сказать, ни в коем случае не хочу никого обидеть, но я разочарован. Я почти 7 лет пишу на PHP в крупном проекте. С плюсами пришлось иметь дело, ибо решил создать один проектик для души. В общем, много говорится о языках высокого уровня, как это круто и мощно, но как же так? Проблемы возникают на каждом символе! То нельзя, то недоработано, того нет. С массивами можно работать только благодаря огромной библиотеке map, нет даже банальной str_replace! Находил в инете много примеров ее, но большинство из них - классы на пол страницы. Понятно, что языки такого рода - это просто каркас, и на нем каждый пишет так, как считает нужным, но стоит ли тратить время на такую писанину, которую можно сократить в разы? Да и оптимально ли это, когда одни и те же функции пишут люди с разным уровнем знаний и умений? Начиная писать на сях, я думал, что меня будет удивлять каждый символ, я буду говорить "Вау!", "О даааа!", Он такой классный!", "Все-таки PHP - это #&%№". А что я получил в итоге? Еле рабочий и то с кучей костылей код, и то который неизвестно как будет вести себя на разных машинах... С PHP вообще проблем такого рода никогда не было. Жаль, конечно, что он только сетевой...
Розовые очки разбились, честно сказать(
Acuna, вы слишком рано делаете выводы - вы ещё слишком мало познали С++ :)
1) в своём коде вы перемешали С и С++.
std::string - это из С++
fopen - это из С
2) вот вам пример чтения из файла
#include <iostream>
#include <fstream>
#include <algorithm>
#include <iterator>
#include <sstream>
void main() {
std::string file_name("test.txt");
std::ifstream file(file_name);
std::ostringstream result_sstr;
std::copy(std::istreambuf_iterator<char>(file),
std::istreambuf_iterator<char>(),
std::ostreambuf_iterator<char>(result_sstr));
std::cout << result_sstr.str() << std::endl;
}
Комментарии писать лень - надеюсь разберётесь :)
Acuna, любое познание нового начинается со слов: "забудьте всё, что знали до этого". C++ вырос на C, вобрал в себя огромный опыт разработчиков в т..ч. низкого уровня, достаточно изощрённых инженеров. PHP предназначен чтобы быстро слабать на коленке домашнюю страничку (без обид, метафора). Чтобы почувствовать красоту и мощь C++ требуется знать много мат.части, абстракций и приёмов программирования (на низком уровне). Оттуда и трудности у начинающих). Моя первая "hello c++", 15 лет назад, вообще не скомпилировалась.
Холивар по пунктам:
То нельзя, то недоработано »
Всё можно, и очень тонко проработано. Почитайте про контейнеры, итераторы, фасеты, буферизованные потоки. При этом оставлена куча дверей для наращивания функционала. Почитайте про библиотеки (например boost). Также C++ обеспечивает совместимость с C, поэтому если ваша любимая функция (например perl regex) в сишной библиотеке - велкам!
С массивами можно работать только благодаря огромной библиотеке map »
Категорически не согласен. Массив и map - это линейный набор однотипных экземпляров и сортированный словарь соответственно. С массивами работать через алгоритмы над итераторами. Map тут вообще не причём. И библиотека малюсенькая, пару классов содержит, Iostream куда больше будет.
нет даже банальной str_replace »
В STL отсутствует множество "нужных" функций. Как правило их можно получить простой комбинацией того, что есть. По этой причине они и выкинуты. С/С++ обычно применяется для задач, требующих высокую скорость и управляемый расход памяти. Str_replace можно сделать так:
1. использовать вашу любимую реализацию (из любой библиотеки)
2. заменить на месте (в строке) - for(p1=0; 1+(p1=str.find("what", p1)); str.replace(p1, 4, "to"), p1+=2) {}
3. заменить в другой буфер (если заранее выделить память - будет работать экстремально быстро) - for(p1=0; (out.append(str, p1, (p2=str.find("what", p1))-p1), p2+1); out.append("to"), p1=p2+4) {}
4. заменить с выводом в поток (позволяет офигительно экономить память в некоторых случаях) - for(p1=0; (out.write(&str[p1], (p2=str.find("what", p1))-p1), p2+1); out.write("to"), p1=p2+4) {}
и т.д.
3 реализации, менее, чем на пол-страницы
Понятно, что языки такого рода - это просто каркас »
Любой язык бесполезен без сказок/историй. Для программистов - это библиотеки функций. Используйте библиотеки и будет вам лаконичное счастье.
Acuna, если у вас задача сделать быстро и не париться, то С++ - не для вас. Он для сугубо дотошных людей, которым надо чтобы было идеально. Если цель узнать, что в нём другие нашли - добро пожаловать, спрашивайте - расскажем. Запаситесь терпением, там ооочень много всего.
pva,
PHP предназначен чтобы быстро слабать на коленке домашнюю страничку
Да, я часто встречаю такое мнение. Но чаще всего оно мотивировано тем, что как правило люди даже не знают, насколько продвинулся в своем развитии PHP за эти годы. Действительно, возникнув изначально как набор инструментов для клепания одиночных страничек, со временем он перерос в очень мощный и серьезный инструмент разработки, на сегодняшний день полноценно (именно так) поддерживающий такие вещи как ООП (поддерживающего практически все существующие на сегодняшний день паттерны типа синглтонов, обозревателей, декораторов, фабрик, ну и прочих достаточно специфичных), переключатели, исключения (try, catch, finally, как полагается :) ), области видимости методов, и даже трейты :/ В общем, теперь он настолько не похож на свои первые версии, что даже потребовалось переименовать его аббревиатуру (да-да, мало кто знает, что теперь она расшифровывается как PHP: Hypertext Preprocessor вместо Personal Home Page Tools)! Ну и как я уже говорил, он помогает избежать излишней писанины, как например в случае со str_replace (). Кстати, она написана С. Вообще, в PHP много что написано на С, просто он позволяет не изобретать велосипед, ну и дает уверенность в том, что стандартная функция написана получше, чем моя, надерганая из инета, да еще и с кучей костылей... Мне не надо думать, как распределяется память переменных, не бывает конфликтов с типами данных (и правда, а зачем?). Разве что не получится сконкатенировать строку с массивом и тому подобное. Если уж очень хочется - можно принудительно определить переменную как (int) $var, например. Ну и так далее...
Ну и всем известно, что практически все известные крупные веб-ресурсы написаны на PHP: eBay, Amazon - это PHP и немного Java, Facebook и некая небезызвестная маргинальная социальная сеть - это чистый PHP, и т. д. А ведь это даже не сайты, они называются "продукты". О как!) Особенно когда сейчас все уходит в облака, это особенно актуально.
Так что возможно дело просто в понимании того или иного вопроса? ;)
если у вас задача сделать быстро и не париться, то С++ - не для вас.
Да все дело в том, что изначально я выбрал плюсы, чтобы после окон можно было легче портировать ее для никсов. Ну уже все, начал, дак начал) Да и изучение чего-то нового очень даже не помешает) Хотя в PHP столько уже нового, что я уже давно считаю, что мое развитие остановилось очень давно :)
Если цель узнать, что в нём другие нашли - добро пожаловать, спрашивайте - расскажем.
О, это спасибо, это действительно очень приятно! Вообще, если бы такой же подход был у преподавателей в универах (ну вкупе с желанием самих студентов, конечно же), разработка в нашей стране была бы в разы лучше. А там того и гляди, ВВП бы пошел бы вверх... Не, ну а вдруг?)
насколько продвинулся в своем развитии PHP за эти годы. »
Интерпретатор научился принимать код в UTF-8 с BOM?
чтобы после окон можно было легче портировать ее для никсов »
Если цель - портировать, то погляди в сторону явы. Там офигительно много библиотек, нет возможности заморачиваться с памятью, при правильном писании работает на любой платформе без изменений. И полно инструментов для быстрой разработки.
не бывает конфликтов с типами данных (и правда, а зачем?) »
Типизацию данных придумали для того, чтобы проверять программу на корректность до запуска. Задавая тип данных, мы постулируем условия использования, принимаемые значения и т.д., ограничиваете возможные варианты, расставляете проверочные контрольные точки. Если возникает конфликт типов - это признак некорректности программы, указатель на логическую ошибку.
Также придерживаюсь мнения о нужности варнингов компилятора и отладчика, ассертов и юнит-тестов
pva, хм, интересно... Я о Java не думал... И консольные приложения тоже можно на ней писать? У меня консольное.
Ну да ладно, не каждый день попробуешь С++ все-таки ;)
Iska, что Вы имеете ввиду? Если поддержку utf-8 в проектах, то окончательно на нее перешли уже давно. Функции для работы с многобайтовыми кодировками (не обязательно utf-8) были введены несколько лет назад, и за эти годы уважающие себя проекты полностью перешли на нее. Хотя изначально это было сродни проблеме 2k. Ну ничего, все всё переписали. Теперь это уже считается просто стандартом де-факто.
Также придерживаюсь мнения о нужности варнингов компилятора и отладчика, ассертов и юнит-тестов
Вы имеете ввиду для С++?
И консольные приложения тоже можно на ней писать? »
Можно для консоли. Ява ни в чём не ущемлена. Сейчас можно даже для чиповых карт писать (думаю скоро для холодильников, пылесосов и утюгов можно будет) Несмотря на откровенную рекламу явы, я всё же приверженец С++
Вы имеете ввиду для С++? »
Речь идёт об инструментах разработчика в принципе (независимо от языка; существуют различные средства в зависимости от среды выполнения). Язык - это лишь средство выражения (кодирования) мысли.
Iska, что Вы имеете ввиду? »
Я имею в виду ровно то, что написал: научился ли интерпретатор языка корректно понимать исходный код в UTF-8 с BOM?
Habetdin
26-04-2014, 17:45
чтобы проверять программу на корректность до запуска »
Но PHP - интерпретируемый язык и состояние "до запуска" не совсем возможно :tomato2:
[hr]Iska, а чем мешает BOM? Разве только тем, что мешает header() - но тут уже ССЗБ, если допустил какие-либо символы в выводе (кроме BOM там может оказаться много чего, даже написанного человеком - "а почему у меня header в середине скрипта не срабатывает?") до функции, которая должна вызываться до любого вывода :)
Iska, а чем мешает BOM? »
На forum.farmanager.com раз за разом апологеты php требуют запрет BOM при сохранении файла из редактора по умолчанию, апеллируя тем, что, дескать, для php это некошерно, ибо не работает. Вот я и интересовался, научился ли.
Но PHP - интерпретируемый язык и »
Дело больше в нетипизированности, чем интерпретируемости. Вот примеры: http://ru.wikipedia.org/wiki/%D0%90%D0%BA%D1%81%D0%B5%D0%BB%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80_PHP, ищем слово "байткод". До запуска можно проверить любой код. Было бы желание ;)
Я имею в виду ровно то, что написал: научился ли интерпретатор языка корректно понимать исходный код в UTF-8 с BOM?
А, ну если так, то можно ответить просто: нет) Ибо незачем. Это не более, чем символ указания кодировки utf-8. А она и без этого идентифицируется безошибочно, если конечно правильно включить ее на сервере, и сохранять файлы в utf-8. Все остальное весьма доходчиво объяснил pva)
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.