Could Not Open Language File English.lng Dev C%2b%2b

Posted on by

Dev c 打开时 出现 could not open language file chine怎么解决，求大神 展开 我来答 可选中1个或多个下面的关键词，搜索相关资料。. Download Dev-C for free. A free, portable, fast and simple C/C IDE. A new and improved fork of Bloodshed Dev-C. One of the tools that is still very useful, even though is hasn't received an update for years on, is DEV-C. This open-source utility comes with many handy features, but mainly for basic.

The code model is the part of an IDE that understands the language you are using to write your application. It is the framework that allows Qt Creator to provide the following services:

  • Syntactic and semantic highlighting
  • Navigating in the code by using the locator, following symbols, and so on
  • Inspecting code by using the class browser, the outline, and so on
  • Diagnostics
Could not open language file english.lng dev c 2b 2b b

Qt Creator comes with a plugin that provides some of these services for C++ on top of Clang.

Could Not Open Language File English.lng Dev C 2b 2b C

About the Clang Code Model

The Clang project provides libraries for parsing C language family source files. The feedback you get through warning and error markers is the same as a compiler will give you, not an incomplete set or a close approximation, as when using the built-in Qt Creator code model. Clang focuses on detailed information for diagnostics, which is really useful if the code contains typos, for example.

Clang keeps up with the development of the C++ language. At the time of this writing, it supports C++98/03, C++11, C++14, C++17, C89, C99, Objective-C, and Objective-C++.

On the downside, for large projects using Clang as code model is slower than using the built-in code model. Clang does not need to generate object files, but it still needs to parse and analyze the source files. For small projects that only use STL, this is relatively fast. But for larger projects that include several files, processing a single file and all the included files can take a while.

The Clang code model plugin now provides some of the services that were previously provided by the built-in C/C++ code model. Currently, the following services are implemented:

  • Code completion
  • Syntactic and semantic highlighting
  • Outline of symbols
  • Tooltips
  • Renaming of local symbols

To use the built-in code model instead, select Help > About Plugins > C++, and deselect the ClangCodeModel check box. Select Restart Now to restart Qt Creator and have the changes take effect.

You can configure Clang diagnostics either globally or separately for:

  • Clang code model (globally or at project level)
  • Clang tools (globally or at project level)

Configuring Clang Code Model

To configure the Clang code model globally:

  1. Select Tools > Options > C++ > Code Model.
  2. To instruct the code model to interpret ambiguous header files as C language files if you develop mainly using C, select the Interpret ambiguous headers as C headers check box.
  3. To process precompiled headers, deselect the Ignore precompiled headers check box.
  4. To avoid out-of-memory crashes caused by indexing huge source files that are typically auto-generated by scripts or code, the size of files to index is limited to 5MB by default. To adjust the limit, edit the value for the Do not index files greater than check box. To index all files, deselect the check box.
  5. Select Manage to specify the Clang checks to perform.

Clang Checks

The predefined configurations perform the following Clang checks:

  • Clang-only pedantic checks uses the -Wpendantic option that performs checks as required by strict ISO C and ISO C++.
  • Clang-only checks for questionable constructs combines the -Wall and -Wextra checks for easily avoidable questionable constructions and some additional issues.
  • Clang-only checks for almost everything uses the -Weverything option with negative options to suppress some warnings.

You can edit the predefined configurations to perform particular checks beginning with -W. Each of these checks also has a negative version that begins with -Wno.

Keep in mind that some options turn on other options. For more information, see Options to Request or Suppress Warnings or the GCC or Clang manual pages.

Specifying Clang Code Model Settings at Project Level

You can specify Clang code model settings at project level by selecting Projects > Clang Code Model.

In addition to configuring the diagnostics, you can select the Enable MSVC-compliant template parsing check box to parse templates in a MSVC-compliant way. This enables Clang to parse headers for example from Active Template Library (ATL) or Windows Runtime Library (WRL). However, using the relaxed and extended rules means that no highlighting or completion can be provided within template functions.

Could Not Open Language File English.lng Dev C 2b 2b B

Using Compilation Databases

The JSON compilation database format specifies how to replay single builds independently of the build system.

A compilation database is basically a list of files and the compiler flags that are used to compile the files. The database is used to feed the code model with the necessary information for correctly parsing the code when you open a file for editing.

To generate a compilation database from the information that the code model has, select Build > Generate Compilation Database.

You can add files, such as non-C files, to the project in compile_database.json.files.

You can use the experimental Compilation Database Project Manager to open the files in a compilation database with access to all the editing features provided by the Clang code model.

To switch between header and source files, select Tools > C++ > Switch Header/Source.

You can specify custom build steps and run settings for compilation database projects in the Projects mode. For more information, see Adding Custom Build Steps and Specifying Run Settings.

To enable the plugin, select Help > About Plugins > Build Systems > Compilation Database Project Manager. Then select Restart Now to restart Qt Creator and load the plugin.

© 2020 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.

Introduction

In this intermittent series, I’ll be looking at the most common error messages your C++ compiler (and linker) can produce, explaining exactly what they mean, and showing how they can be fixed (or, better still avoided). The article will specifically talk about the errors produced by the GCC command line compiler, but I’ll occasionally provide some coverage of Microsoft C++ as well. The articles are aimed at beginner to intermediate C++ programmers, and will mostly not be OS-specific.

Error Messages 101

Compiler error messages from the GCC g++ compiler generally look like something this:

which was produced by this code:

The first line of the error says which function the following error(s) is in. The error message itself comes in four main parts; the file the error occurs in, the line number and character offset at which the compiler thinks the error occurs, the fact that it is an error, and not a warning, and the text of the message.

Could Not Open Language File English.lng Dev C 2b 2b 1b

As well as error, the compiler can also produce warnings. These are usually about constructs that, while not being actually illegal in C++, are considered dubious, or constructs that the compiler has extensions to cover. In almost all cases, you don’t want to use such constructs, and you should treat warnings as errors; in other words, your code should always compile with zero warnings. You should also increase the level of warnings from the compiler’s default, which is usually too low. With g++, you should use at least the -Wall and -Wextra compiler options to do this:

No such file or directory

The error I’m looking at today most commonly occurs when you are including a header file using the preprocessor #include directive. For example, suppose you have the following code in a file called myfile.cpp:

and you get the following error message:

What could be causing it? Well, the basic cause is that the compiler cannot find a file called myheader.h in the directories it searches when processing the #include directive. This could be so for a number of reasons.

The simplest reason is that you want the compiler to look for myheader.h in the same directory as the myfile.cpp source file, but it can’t find it. this may be because you simply haven’t created the header file yet, but the more common reason is that you either misspelled the header file name in the #include directive, or that you made a mistake in naming the header file when you created it with your editor. Look very closely at the names in both the C++ source and in your source code directory listing. You may be tempted to think 'I know that file is there!', but if the compiler says it isn’t there, then it isn’t, no matter how sure you are that it is.

This problem is somewhat greater on Unix-like system, such as Linux, as there file names are character case sensitive, so Myheader.h, MyHeader.h, myheader.h and so on would all name different files, and if you get the case wrong, the compiler will not look for something 'similar'. For this reason, a very good rule of thumb is:

Never use mixed case when naming C++ source and header files. Use only alphanumeric characters and the underscore when naming C+++ files. Never include spaces or other special characters in file names.

Apart from avoiding file not found errors, this will also make life much easier if you are porting your code to other operating systems which may or may not respect character case.

The wrong directory?

Another situation where you may get this error message is if you have split your header files up from your C++ source files into separate directories. This is generally good practice, but can cause problems. Suppose your C++ project is rooted at C:/myprojects/aproject, and that in the aproject directory you have two sub-directorys called src (for the .cpp files) and inc (for the header files), and you put myfile.cpp in the src directory, and myheader.h in the inc directory, so that you have this setup:

Now if you compile the source myfile.cpp from the src directory, you will get the 'No such file or directory' error message. The C++ compiler knows nothing about the directory structures of your project, and won’t look in the inc directory for the header. You need to tell it to look there somehow.

One thing some people try when faced with this problem is to re-write myfile.cpp so it looks like this:

or the slightly more sophisticated:

Both of these are a bad idea, as they tie your C++ code to the project’s directory structure and/or location, both of which you will probably want to change at some point in the future. If the directory structure does change, you will have to edit all your #include directories.The better way to deal with this problem is to tell the compiler directly where to look for header files. You can do that with the compiler’s -I option, which tells the compiler to look in the specified directory, as well as the ones it normally searches:

Now the original #include directive:

will work, and if your directory structure changes you need only modify the compiler command line. Of course, writing such command lines is error prone, and you should put such stuff in a makefile, the use of which is unfortunately outside the scope of this article.

Could Not Open Language File English.lng Dev C 2b 2b 1

Problems with libraries

Somewhat similar issues to those described above can occur when you want to use a third-party library. Suppose you want to use the excellent random number generating facilities of the Boost library. If you are copying example code, you may well end up with something like this in your C++ source file:

This will in all probability lead to yet another 'No such file or directory' message, as once again the compiler does not know where 'boost/random.hpp' is supposed to be. In fact, it is one of the subdirectories of the Boost installation, and on my system I can get the #include directive to work using this command line:

where /prog/boost1461 is the root directory for my specific Boost library installation.

Can’t find C++ Standard Library files?

One last problem that beginners run into is the inability of the compiler to find header files that are part of the C++ Standard Library. /adobe-flash-cs6-free-download-full-version.html. One particular favourite is this one:

where you are learning C++ from a very, very old book. Modern C++ implementations have not contained a file called iostream.h for a very long time indeed, and your compiler is never going to find it. You need to use the correct, standard names for such headers (and to get a better book!):

If this still fails, then there is almost certainly something very wrong with your GCC installation. The GCC compiler looks for Standard Library files in a subdirectory of its installation, and locates that directory relative to the directory containing the compiler executable, so if the Standard Library headers are available, the compiler should always find them.

Conclusion

This article looked at the 'No such file or directory' message of the GCC C++ compiler. If you get this message you should:

  • Remember that the compiler is always right in situations like this.
  • Look very closely at the file name to make sure it is correct.
  • Avoid naming file using mixed-case or special characters.
  • Use the -I compiler option to tell the compiler where to look for files.
  • Make sure that GCC is correctly installed on your system.