Требуется директива препроцессора visual studio ошибка - Ремонт и установка крупной бытовой техники

вредина

0 / 0 / 3

Регистрация: 08.10.2012

Сообщений: 141

Требуется директива препроцессору

14.11.2012, 15:39. Показов 17072. Ответов 3

Метки нет (Все метки)

у меня проблема такого плана (опишу все действия сначала, т.к. не уверен в их правильности):
создаю пустой проект, добавляю «файл с кодом» (разрешение .cs), пишу саму прогу

#include "stdafx.h";
#include "stdio.h";
#include "math.h";
 
 
 
int _tmain(int argc, _TCHAR* argv[])
{ 
    float x1, y1, x2, y2, dln;
    printf ("vvedite x1n");
    scanf_s("%f", &x1);
    printf ("vvedite y1n");
    scanf_s("%f", &y1);
    printf ("vvedite x2n");
    scanf_s("%f", &x2);
    printf ("vvedite y2n");
    scanf_s("%f", &y2);
    dln=sqrt(pow((x2-x1),2)+pow((y2-y1),2));
    printf("rasstjjnie mejdu tochkami %.2fn", dln);
    return 0;
}

и тут же мне внизу пишет ошибки
«требуется директива предпроцессору»
з.ы. может в начале еще что-то надо ?
у меня Visual Studio 2008 express edittion, скачанная с сайт ms

__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь

Don’t worry, be happy

17779 / 10543 / 2035

Регистрация: 27.09.2012

Сообщений: 26,514

Записей в блоге: 1

14.11.2012, 16:13

точки с запятой после includ’ов уберите.

0 / 0 / 3

Регистрация: 08.10.2012

Сообщений: 141

14.11.2012, 19:12

[ТС]

писал с ними и без, все равно ошибку выдает

перед самим #include больше ничего не надо ?

uburuntu

95 / 95 / 58

Регистрация: 04.10.2012

Сообщений: 189

14.11.2012, 19:19

Могу ошибаться, но попробуй так:

1
2
3

#include <stdio.h>
#include <math.h>
#include "stdafx.h"

А точки с запятой точно не надо

При создании решения VS2013 (перенесенного из VS8) я получаю следующую ошибку:

Ошибка 1 ошибка C2220: предупреждение рассматривается как ошибка — нет файла объекта
сгенерированный C: Program Files Microsoft Visual Studio
12.0 VC atlmfc include afx.h 38 Предупреждение 2, предупреждение C4996: ‘MBCS_Support_Deprecated_In_MFC’: поддержка MBCS в MFC устарела
и может быть удален в будущей версии MFC. C: Program
Файлы Microsoft Visual Studio 12.0 VC atlmfc include afx.h 38

Это вызвано следующим кодом:

    #ifdef _MBCS
// Warn about MBCS support being deprecated: see http://go.microsoft.com/fwlink/p/?LinkId=279048 for more information.
#pragma warning(push)
#pragma warning(1 : 4996)
inline __declspec(deprecated("MBCS support in MFC is deprecated and may be removed in a future version of MFC.")) void MBCS_Support_Deprecated_In_MFC() { }

class MBCS_Deprecated_MFC
{
public:
MBCS_Deprecated_MFC() { MBCS_Support_Deprecated_In_MFC(); }
};
#pragma warning(pop)
#endif

Как я могу найти, где _MBCS определяется в решении. Поиск не имеет никаких результатов.

Решение

_MBCS Символ будет определен в результате настроек в свойствах вашего проекта. смотреть на General->Character Set — это то, что добавляет необходимые записи в командную строку.

Чтобы продолжить использовать MBCS, вам необходимо установить дополнительную поддержку от Microsoft здесь

Как это отмечено в MSDN:

MSDN

Код в вашем вопросе на самом деле дает ссылку на этот блог, который обсуждает изменения и включает ссылку на скачивание:

// Warn about MBCS support being deprecated: see http://go.microsoft.com/fwlink/p/?LinkId=279048 for more information.

Таким образом, вы можете скачать патч по ссылке выше или перенести приложение в UNICODE.

Другие решения

Других решений пока нет …

When building a VS2013 solution (migrated from VS8) I get the following error :

Error 1 error C2220: warning treated as error — no ‘object’ file
generated C:Program FilesMicrosoft Visual Studio
12.0VCatlmfcincludeafx.h 38 Warning 2 warning C4996: ‘MBCS_Support_Deprecated_In_MFC’: MBCS support in MFC is deprecated
and may be removed in a future version of MFC. C:Program
FilesMicrosoft Visual Studio 12.0VCatlmfcincludeafx.h 38

This is caused bij the following code :

    #ifdef _MBCS
// Warn about MBCS support being deprecated: see http://go.microsoft.com/fwlink/p/?LinkId=279048 for more information.
#pragma warning(push)
#pragma warning(1 : 4996)
inline __declspec(deprecated("MBCS support in MFC is deprecated and may be removed in a future version of MFC.")) void MBCS_Support_Deprecated_In_MFC() { }

class MBCS_Deprecated_MFC
{
public:
MBCS_Deprecated_MFC() { MBCS_Support_Deprecated_In_MFC(); }
};
#pragma warning(pop)
#endif

How can I find where _MBCS is defined in the solution. Find doesn’t has any results.

asked Dec 20, 2013 at 15:24

The _MBCS symbol will be defined as a result of the settings in your project properties. Look at General->Character Set — this is what adds the required entries to the command line.

To continue using MBCS, you need to install the optional support from Microsoft here

As it notes in MSDN:

msdn

The code in your question actually gives a link to this blog post, which discusses the changes and includes a link to the download:

// Warn about MBCS support being deprecated: see http://go.microsoft.com/fwlink/p/?LinkId=279048 for more information.

So, you can either download the patch from the link above or migrate your application to UNICODE.

answered Dec 20, 2013 at 15:32

Roger RowlandRoger Rowland

25.6k11 gold badges71 silver badges113 bronze badges

When building a VS2013 solution (migrated from VS8) I get the following error :

Error 1 error C2220: warning treated as error — no ‘object’ file
generated C:Program FilesMicrosoft Visual Studio
12.0VCatlmfcincludeafx.h 38 Warning 2 warning C4996: ‘MBCS_Support_Deprecated_In_MFC’: MBCS support in MFC is deprecated
and may be removed in a future version of MFC. C:Program
FilesMicrosoft Visual Studio 12.0VCatlmfcincludeafx.h 38

This is caused bij the following code :

    #ifdef _MBCS
// Warn about MBCS support being deprecated: see http://go.microsoft.com/fwlink/p/?LinkId=279048 for more information.
#pragma warning(push)
#pragma warning(1 : 4996)
inline __declspec(deprecated("MBCS support in MFC is deprecated and may be removed in a future version of MFC.")) void MBCS_Support_Deprecated_In_MFC() { }

class MBCS_Deprecated_MFC
{
public:
    MBCS_Deprecated_MFC() { MBCS_Support_Deprecated_In_MFC(); }
};
#pragma warning(pop)
#endif

How can I find where _MBCS is defined in the solution. Find doesn’t has any results.

asked Dec 20, 2013 at 15:24

The _MBCS symbol will be defined as a result of the settings in your project properties. Look at General->Character Set — this is what adds the required entries to the command line.

To continue using MBCS, you need to install the optional support from Microsoft here

As it notes in MSDN:

msdn

The code in your question actually gives a link to this blog post, which discusses the changes and includes a link to the download:

// Warn about MBCS support being deprecated: see http://go.microsoft.com/fwlink/p/?LinkId=279048 for more information.

So, you can either download the patch from the link above or migrate your application to UNICODE.

answered Dec 20, 2013 at 15:32

Roger RowlandRoger Rowland

25.6k11 gold badges71 silver badges113 bronze badges

Предупреждение C4668 «STDC_WANT_SECURE_LIB» не задано как
макроопределение препроцессора, замена на «0» для «#if/#elif»

в справочнике написано:
Предупреждение компилятора (уровень 4) C4668
«символ» не определен в качестве макроса препроцессора и будет заменен в «директивах» на «0»
Символ, который не был определен, использовался с директивой препроцессора. Символ будет иметь значение false. Чтобы определить символ, можно использовать либо директиву #define , либо параметр компилятора /d .
Это предупреждение отключено по умолчанию. Подробнее: Выключенные по умолчанию предупреждения компилятора .

Вопрос не в том как это игнорировать а как это исправить

     #include <iostream>

int main()
{
    
    return 0;

}

Предупреждение C4668 «STDC_WANT_SECURE_LIB» не задано как макроопределение препроцессора, замена на «0» для «#if/#elif»

Серьезность Код Описание Проект Файл Строка Состояние подавления
Ошибка C2220 следующее предупреждение рассматривается как ошибка Proverka C:Program Files (x86)Microsoft Visual Studio2019EnterpriseVCToolsMSVC14.29.30133includelimits.h 70
Предупреждение C4668 «STDC_WANT_SECURE_LIB» не задано как макроопределение препроцессора, замена на «0» для «#if/#elif» Proverka C:Program Files (x86)Microsoft Visual Studio2019EnterpriseVCToolsMSVC14.29.30133includelimits.h 70
Предупреждение C4365 аргумент: преобразование «long» в «unsigned int», несоответствие типов со знаком и без Proverka C:Program Files (x86)Microsoft Visual Studio2019EnterpriseVCToolsMSVC14.29.30133includexmemory 162
Предупреждение C4365 аргумент: преобразование «long» в «unsigned int», несоответствие типов со знаком и без Proverka C:Program Files (x86)Microsoft Visual Studio2019EnterpriseVCToolsMSVC14.29.30133includexmemory 172
Предупреждение C4365 аргумент: преобразование «long» в «unsigned int», несоответствие типов со знаком и без Proverka C:Program Files (x86)Microsoft Visual Studio2019EnterpriseVCToolsMSVC14.29.30133includeatomic 292
Предупреждение C4365 аргумент: преобразование «long» в «unsigned int», несоответствие типов со знаком и без Proverka C:Program Files (x86)Microsoft Visual Studio2019EnterpriseVCToolsMSVC14.29.30133includeatomic 308
Предупреждение C4365 аргумент: преобразование «long» в «unsigned int», несоответствие типов со знаком и без Proverka C:Program Files (x86)Microsoft Visual Studio2019EnterpriseVCToolsMSVC14.29.30133includeatomic 325
Предупреждение C4365 аргумент: преобразование «long» в «unsigned int», несоответствие типов со знаком и без Proverka C:Program Files (x86)Microsoft Visual Studio2019EnterpriseVCToolsMSVC14.29.30133includeatomic 388

Источник

Содержание

C# Preprocessor bug?; found in VS2017 (15.7.2) #27109
Comments
#if preprocessor directive incorrectly handles enclosed C# verbatim string #4726
Comments
Main cs 2 0 error cs1024 wrong preprocessor directive

C# Preprocessor bug?; found in VS2017 (15.7.2) #27109

The code below gives the following compilation error:

error CS1024: Preprocessor directive expected

The strange part is that it ONLY happens when the code is part of a #if/#endif block that is NOT defined.

This seems like a bug.

The text was updated successfully, but these errors were encountered:

This is not a bug and is very much the design of C# since v1. 🙂

When _THIS_IS_NOT_DEFINED_ is not defined, then the compiler gets to the #if , sees that the condition is false, and considers all text up to the next preprocessor directive (like #else , #elif or #endif ) as ‘disabled text’. In this case, this means it just consumes the code blindly as text until it sees teh # in #rates . There, it says «aha, what sort of directive do i have? ‘rates’?? that’s not a thing. ERROR!».

The difference here is that when the scanner is dealing with ‘disabled text’ sections, it’s not going and making tokens like the normal scanning does. So it has no concept that @» is special and starts some sort of string. Instead, it just does not give a hoot.

** This is important as you want people to put any code they want into a verbatim string (except a quote) and not have the compiler ‘interpret’ it in any fashion. Otherwise, you’d have to escape your pp-directives in a string, which would defeat the purpose of it being a ‘verbatim’ string. 🙂

Thanks for the detail explanation. It does feel odd that valid code can start to fail if wrapped in an undefined preprocessor block in this way; however, it is certainly easy to work around. Should the scanning of disabled text take into account the @» text as a future improvement to the C# preprocessor? I’m just curious on your take.

text take into account the @» text as a future improvement to the C# preprocessor? I’m just curious on your take.

Unfortunately, that can’t happen, it would be a breaking change. There is code out there that def depends on this behavior. :-/

Maybe it would make sense to ignore unknown preprocessor directives in disabled sections of code? I think that wouldn’t be a breaking change.

Источник

#if preprocessor directive incorrectly handles enclosed C# verbatim string #4726

To reproduce, just use this code and make sure that DEBUG is set:

Actually, this produces a CS1024 error because the compiler seems to interpret the «# text» portion of the string as a preprocessor directive.

The text was updated successfully, but these errors were encountered:

I’m pretty sure this is by design. Once the compiler sees the #if !DEBUG it’s going to be in an inactive region. Once in that state it will continue scanning through the inactive region handling other preprocessor directives, until it finally ends that region (with the #endif ). Inside that region, the compiler has no concept of things a multi-line string literal.

We should investigate whether this is a bug or per spec.

From my reading, this is ‘per spec’. The relevant sections are:

Because ‘DEBUG’ is defined, then the pp-expression evaluates to false , meaning we’ll be in a skipped-section .

The spec then says:

The remaining conditional-sections, if any, are processed as skipped-sections: except for pre-processing directives, the source code in the section need not adhere to the lexical grammar; no tokens are generated from the source code in the section; and pre-processing directives in the section must be lexically correct but are not otherwise processed.

As such, it is ‘per spec’ that an error is produced as the compiler is checking that the #text «pre-processing directives in the section must be lexically correct». As #text is not a legal pp-directive, the error is appropriate.

Fair enough; per the spec I agree that this can’t be considered a bug. Nonetheless it is rather unintuitive behavior — requiring pre-processing directives to be «lexically correct» while declaring that they are unprocessed goes contrary to what one would expect — that everything is skipped until the #endif directive is encountered at the beginning of a line. Sounds like my problem is actually with the spec and not the implementation 🙂

All that being said, this was a rather odd scenario that popped up and was easy to work around. Thanks for looking into it.

When commenting out a block of code, I recommend using line-ending comments. In VS, select the code to be commented out and hit control-K control-C. To uncomment a block of code select it and hit control-K control-U.

I acknowledge that this doesn’t help in your scenario, where you want the code commented or not depending on a PP-symbol.

Agreed on the line-ending comments; I’m a big fan of ctrl-K,C. This was literally a case of production code having a C# verbatim string inside a skipped block with a line that happened to begin with #. I can’t imagine that this is a very common use case, but I wanted to at least report this behavior in case it wasn’t intended. Again, thanks for taking the time to check this out and explain it to me.

I think it’s so you don’t end up accident writing something like:

in the middle of your skipped section. With the current spec approach, you’ll get a nice error here and you can fix the directive.

From: gdivismailto:notifications@github.com
Sent: ‎8/‎24/‎2015 10:21 AM
To: dotnet/roslynmailto:roslyn@noreply.github.com
Cc: Cyrus Najmabadimailto:cyrusn@microsoft.com
Subject: Re: [roslyn] #if preprocessor directive incorrectly handles enclosed C# verbatim string (#4726)

All that being said, this was a rather odd scenario that popped up and was easy to work around. Thanks for looking into it.

Источник

Main cs 2 0 error cs1024 wrong preprocessor directive

В стандарте написано следующее:

9.5.4 Conditional compilation directives
.
The remaining conditional-sections, if any, are processed as skipped-sections: except for pre-processing
directives, the source code in the section need not adhere to the lexical grammar; no tokens are generated
from the source code in the section; and pre-processing directives in the section shall be lexically correct but
are not otherwise processed.

	От:	Ovl
Дата:	01.06.07 14:01
Оценка:

N>9.5.4 Conditional compilation directives
N>.
N>The remaining conditional-sections, if any, are processed as skipped-sections: except for pre-processing
N>directives, the source code in the section need not adhere to the lexical grammar; no tokens are generated
N>from the source code in the section; and pre-processing directives in the section shall be lexically correct but
N>are not otherwise processed.

	От:	Ovl
Дата:	01.06.07 14:02
Оценка:

	От:	Ovl
Дата:	01.06.07 14:06
Оценка:

Здравствуйте, Ovl, Вы писали:

Ovl>хотя да, даже валидный #if не пропускается. странные коментарии в с#

а, ну да. он же не валиден

вот так все в порядке

	От:	lonli
Дата:	01.06.07 14:59
Оценка:

Здравствуйте, nikov, Вы писали:

Да забей ты

«Чтобы все знать интернет нафик не нужен! НУжен утюг!» ©сб. БГУ

	От:	Алексей.
Дата:	04.06.07 07:58
Оценка:

N>9.5.4 Conditional compilation directives
N>.
N>The remaining conditional-sections, if any, are processed as skipped-sections: except for pre-processing
N>directives, the source code in the section need not adhere to the lexical grammar; no tokens are generated
N>from the source code in the section; and pre-processing directives in the section shall be lexically correct but
N>are not otherwise processed.

	От:	nikov	http://www.linkedin.com/in/nikov
Дата:	04.06.07 08:03
Оценка:

Здравствуйте, Алексей., Вы писали:

А>Компилятор в данном случае соотвествует стандарту. Многострочный комментарий, тот что со звездочками, не имеет эффект в skipped-секциях и обрабатывается как последовательность входных символов, а не как единый токен-комментарий. Поэтому когда компилятор встречает #bugaga внутри skipped-секции он его пытается обработать как директиву препроцессора.

Про комментарии я понимаю. Но в стандарте написано, что директивы препроцессора в skipped-секции не обрабатываются, если они не являются лексически корректными. Иначе получилось бы, что текст внутри skipped-секции, случайно начинающийся с #, будет вызывать ошибку (что мы и наблюдаем).

	От:	Алексей.
Дата:	04.06.07 08:19
Оценка:

Здравствуйте, nikov, Вы писали:

N>Про комментарии я понимаю. Но в стандарте написано, что директивы препроцессора в skipped-секции не обрабатываются, если они не являются лексически корректными. Иначе получилось бы, что текст внутри skipped-секции, случайно начинающийся с #, будет вызывать ошибку (что мы и наблюдаем).

Хм. Похоже ты прав. Невнимательно я прочитал выделенную фразу.

	От:	Ovl
Дата:	04.06.07 08:32
Оценка:

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, Алексей., Вы писали:

А>>Компилятор в данном случае соотвествует стандарту. Многострочный комментарий, тот что со звездочками, не имеет эффект в skipped-секциях и обрабатывается как последовательность входных символов, а не как единый токен-комментарий. Поэтому когда компилятор встречает #bugaga внутри skipped-секции он его пытается обработать как директиву препроцессора.

простите, а как вы перевели фразу?

except for pre-processing directives, the source code in the section need not adhere to the lexical grammar

and pre-processing directives in the section shall be lexically correct but are not otherwise processed

	От:	nikov	http://www.linkedin.com/in/nikov
Дата:	04.06.07 09:44
Оценка:	-1

except for pre-processing directives, the source code in the section need not adhere to the lexical grammar

код в этой секции, за исключением директив препроцессора, не обязан придерживаться [правил] грамматики

and pre-processing dirctives in the section shall be lexically correct but are not otherwise processed

директивам препроцессора в этой секции следует быть лексически правильными, иначе они не будут обработаны

	От:	Ovl
Дата:	04.06.07 09:46
Оценка:	23 (2)

except for pre-processing directives, the source code in the section need not adhere to the lexical grammar

код в этой секции, за исключением директив препроцессора, не обязан придерживаться [правил] грамматики

and pre-processing dirctives in the section shall be lexically correct but are not otherwise processed

директивам препроцессора в этой секции следует быть лексически правильными, иначе они не будут обработаны

	От:	nikov	http://www.linkedin.com/in/nikov
Дата:	04.06.07 09:50
Оценка:

директивам препроцессора в этой секции следует быть лексически правильными, иначе они не будут обработаны

Ovl>директивам препроцессора в этой секции следует быть лексически правильными, кроме этого они никак не обработываются

Спасибо, я согласен. Мой перевод был неверным.
Однако, #bugaga — это не директива препроцессора, и она не обязана быть лексически правильной.

	От:	Ovl
Дата:	04.06.07 09:53
Оценка:

N>Однако, #bugaga — это не директива препроцессора, и она не обязана быть лексически правильной.

директива — это последовательность # если перед ним до начала строки ничего нет

	От:	nikov	http://www.linkedin.com/in/nikov
Дата:	04.06.07 09:55
Оценка:

Здравствуйте, Ovl, Вы писали:

N>>Однако, #bugaga — это не директива препроцессора, и она не обязана быть лексически правильной.

Ovl>директива — это последовательность # если перед ним до начала строки ничего нет

Откуда это следует?
Я ориентируюсь на следующее определение:

	От:	Алексей.
Дата:	04.06.07 10:00
Оценка:

and pre-processing dirctives in the section shall be lexically correct but are not otherwise processed

директивам препроцессора в этой секции следует быть лексически правильными, иначе они не будут обработаны

Спасибо за перевод. Значит компилятор и я все-таки правы.

	От:	nikov	http://www.linkedin.com/in/nikov
Дата:	04.06.07 10:09
Оценка:

Здравствуйте, Ovl, Вы писали:

Ovl>директива — это последовательность # если перед ним до начала строки ничего нет

Компилятор выдает ошибку и на таком коде:

, где никакого слова нет.

	От:	Ovl
Дата:	04.06.07 10:12
Оценка:

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, Ovl, Вы писали:

N>>>Однако, #bugaga — это не директива препроцессора, и она не обязана быть лексически правильной.

Ovl>>директива — это последовательность # если перед ним до начала строки ничего нет

N>Откуда это следует?
N>Я ориентируюсь на следующее определение:

верно. это правильные директивы.
а списка неправильных там разве не приведено?

A pre-processing directive always occupies a separate line of source code and always begins
with a # character and a pre-processing directive name. White space may occur before the # character
and between the # character and the directive name.

	От:	nikov	http://www.linkedin.com/in/nikov
Дата:	04.06.07 10:14
Оценка:

Ovl>A pre-processing directive always occupies a separate line of source code and always begins
Ovl>with a # character and a pre-processing directive name. White space may occur before the # character
Ovl>and between the # character and the directive name.

	От:	Ovl
Дата:	04.06.07 10:19
Оценка:

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, Ovl, Вы писали:

Ovl>>директива — это последовательность # если перед ним до начала строки ничего нет

N>Компилятор выдает ошибку и на таком коде:

N>
N>, где никакого слова нет.

нету. об этом вам компилятор и говорит. что-нибудь типа «directive expected»

	От:	nikov	http://www.linkedin.com/in/nikov
Дата:	04.06.07 11:02
Оценка:

Здравствуйте, Ovl, Вы писали:

Ovl>нету. об этом вам компилятор и говорит. что-нибудь типа «directive expected»

В общем, ситуация понятна. Если внутри skipped-секции встречается строка, первый непробельный символ в которой — #, то эта строка должна содержать корректную директиву препроцессора, иначе возникает ошибка компиляции. Я бы не сказал, что эта мысль ясно выражена в стандарте.

Источник

C# Error

CS1024 – Preprocessor directive expected

Reason for the Error & Solution

Preprocessor directive expected

A line began with the pound symbol (#), but the subsequent string was not a valid .

The following sample generates CS1024:

// CS1024.cs  
#import System   // CS1024

Источник

вредина

0 / 0 / 3

Регистрация: 08.10.2012

Сообщений: 141

Требуется директива препроцессору

14.11.2012, 15:39. Показов 17973. Ответов 3

Метки нет (Все метки)

Студворк — интернет-сервис помощи студентам

#include "stdafx.h";
#include "stdio.h";
#include "math.h";
 
 
 
int _tmain(int argc, _TCHAR* argv[])
{ 
    float x1, y1, x2, y2, dln;
    printf ("vvedite x1n");
    scanf_s("%f", &x1);
    printf ("vvedite y1n");
    scanf_s("%f", &y1);
    printf ("vvedite x2n");
    scanf_s("%f", &x2);
    printf ("vvedite y2n");
    scanf_s("%f", &y2);
    dln=sqrt(pow((x2-x1),2)+pow((y2-y1),2));
    printf("rasstjjnie mejdu tochkami %.2fn", dln);
    return 0;
}

Неэпический

17819 / 10592 / 2044

Регистрация: 27.09.2012

Сообщений: 26,636

Записей в блоге: 1

14.11.2012, 16:13

точки с запятой после includ’ов уберите.

0 / 0 / 3

Регистрация: 08.10.2012

Сообщений: 141

14.11.2012, 19:12

[ТС]

писал с ними и без, все равно ошибку выдает

перед самим #include больше ничего не надо ?

uburuntu

95 / 95 / 58

Регистрация: 04.10.2012

Сообщений: 189

14.11.2012, 19:19

Могу ошибаться, но попробуй так:

1
2
3

#include <stdio.h>
#include <math.h>
#include "stdafx.h"

А точки с запятой точно не надо

Источник

I’m just trying to use MS Visual for some really simple C++ coding for school purposes. The point is I can’t even write a simple hello-world alike program.
I’ve got that error «Preprocessor expected» in line with library. Line with code looks like this: #include <iostream>

Any help with solving this (probably) minor problem is welcomed.

Here is whole code:

#include <iostream>

int main()
{
    std::cout << "aogaohgo";
}

asked Oct 8, 2015 at 16:11

OP’s reported error message is reminiscent of a C# error message.

Testing this theory and pasting OPs C++ code into a C# console project I receive:

error CS1024: Preprocessor directive expected

As the first error.

Solution: Create a new project and make sure the selected language is C++

answered Oct 8, 2015 at 17:44

user4581301user4581301

32.9k7 gold badges33 silver badges53 bronze badges

#include isn’t valid on it’s own.

The correct syntax is #include <filename>.

I suggest you pick up a better Hello World tutorial

answered Oct 8, 2015 at 16:13

slaphappyslaphappy

6,8843 gold badges34 silver badges59 bronze badges

Источник

Требуется директива препроцессору

Решение

Другие решения

C# Preprocessor bug?; found in VS2017 (15.7.2) #27109

#if preprocessor directive incorrectly handles enclosed C# verbatim string #4726

Main cs 2 0 error cs1024 wrong preprocessor directive

C# Error

Reason for the Error & Solution

Related Posts

Требуется директива препроцессору