In the Artistic Style documentation, in General Information, Other Considerations, there is a list of terminology used for special characters used in programming. The terms used by Artistic Style have been different than is used by Visual Studio, Clang, and others. In this release the terms used by Artistic Style have been changed to the ones most commonly used in programming documentation. The following chart indicates the changes.
| NEW | OLD | |
| braces or curly braces | { } | brackets |
| parens or round brackets | ( ) | parens |
| square brackets | [ ] | block parens |
| angle brackets | < > | angle brackets |
Parens and angle brackets do not change. Brackets has been changed to braces. Block parens has been changed to square brackets. Brackets can now collectively refer to the group containing round brackets (parens), square brackets, and angle brackets. The documentation has been updated and the variable names in the source code have been changed.
There are four options affected by the change, "break-closing-brackets", "add-brackets", "add-one-line-brackets", and "remove-brackets". These have been changed to the corresponding "break-closing-braces", "add-braces", "add-one-line-braces", and "remove-braces". Also, the option "max-instatement-indent" has been changed to "max-continuation-indent". The old options and method names have been depreciated, but will continue to be accepted for the next several releases.
The source code now uses the C++11 standard. Compilers that need a standard declared should use C++11. Visual Studio 2010 is currently still currently supported. The classes were made independent of the containing source code files (the source files contain multiple classes). The dependency on global variables in the console build was removed.
A new option, "indent-after-parens", will indent continuation lines following lines that contain an opening paren '(' or an assignment '='. This includes function definitions and declarations and return statements. This option may be preferred for editors displaying proportional fonts.
A new option, "attach-closing-while", will attach the closing "while" of a "do-while" statement to the closing brace. It has precedence over both the brace style and the break closing braces option.
The option "break-closing-braces" has been included in "style=stroustrup". This is the correct style according to Wikipedia. The new option "attach-closing-while" is not included in the style but can be used if you want. If there is a problem with the new format, change to the K&R style using the same options as for Stroustrup.
If you are using Windows XP, there is a download file available that has an XP compatible executable. Artistic Style will still compile with Visual Studio 2010.
Thanks to Jochen Tucht and Matthew Woehlke for their contributions.
The following are additional topics.
Artistic Style was written in the 1990's when personal computers were much slower and compilers were not as sophisticated as today. It used a lot of global variables instead of class members. In previous releases, classes were created for the astyle_main.h source code. With this release, the classes have been made independent of the source file containing them and the shared and global data has been eliminated. The classes could now be separated into separate source files. They have not been actually separated because it seems more convenient to leave them combined.
As explained previously, the terminology for special characters has been changed to agree with various development environments and compilers. The variable and method names in the source code were changed as well as the documentation. This was a major renaming. If not for the "rename" refactoring feature in Visual Studio, and the AStyleTest programs, it would probably not have been attempted.
Artistic Style has also started using C++11. Older compiler versions and compilers without C++11support cannot be used. If your compiler requires a compiler directive for C++, such as -std=c++11 or -std=c++0x, it will need to be used.
The shared library object (DLL) compile was originally intended to be a local library used by a single program. Users could update the library at their convenience. Recently, it has started being distributed as a system library for some distributions. In the past was not maintained for doing this. Since it is already being offered as a distribution, the library soname on Linux has been standardized.
It can still be used as a local or a static library if you want to control the changes. Or the system library can be used. The system library version, of course, may change at any time. With this release the system library will be available on Debian based systems, as well as possibly others.
The Windows library name has been changed also. This Windows version is AStyle30.dll. The "30" refers to the Artistic Style release number "3.0". The Linux library name is a soname version number, not the Artistic Style release number.
There is a new GUI test program AStyleWx that uses wxWidgets. This replaces the old AStyleWin program. AStyleWx is multi-platform and has more features simply because they are easier to implement with wxWidgets.
It has download files and a website in a new sub-project directory of Artistic Style. The downloads contain source code, documentation, and scripts. The Windows download contains an executable. The needed Artistic Style source files are included.
It is licensed under the MIT license. The source code may be used and modified for any purpose you choose. Developers using Artistic Style in another project may use any part of AStyleWx in their project. The modified source code does NOT need to be made available to others.
Code::Blocks is a free, open-source cross-platform IDE that supports multiple compilers. It currently gets over 100,000 downloads per week. It is used by Artistic Style to test compilers on various systems. Code::Blocks build files for several free compilers are now provided with the Artistic Style release. The "Install Information" contains additional information.
Embarcadero is offering a new, free, BCC32C C++ compiler. It includes C++11 language support, the Dinkumware Standard Template Library, and the Embarcadero Runtime Library. Included are a linker, a resource compiler, and a number of command line tools. It is currently for Win32 only. There is more information at their Free Tools web page. They are also currently offering a free debugger and two different development environments.
If you use cppcheck, it has an add-on to check naming standards for functions and variables by using regular expressions. Cppcheck must be run first to generate ".dump" files. The Python program, naming.py, can then be run to check the names. It is basically a shell that you will probably want to modify for regular use. The add-ons must be installed with cppcheck for naming.py to be available.
WinMerge 2011 is a fork of the original WinMerge application published on SourceForge by Thingamahoochie Software. It is has removed the ATL/MFC dependencies and added some useful features. It uses Artistic Style to format the source code.
Whatstyle finds a code format style that fits given source files. This program looks at your source code and generates a style definition that fits its original formatting style as closely as possible. Several formatters and programming languages are supported. It is written in Python and has an interesting method for finding the style options.
A new bracket style option, "style=mozilla", has been added. It uses linux brackets with opening brackets broken from classes, structs, enums, and function definitions. Brackets are attached to everything else, including namespaces, arrays, and statements within a function.
A new option, "break-one-line-headers" will break a header (if, while, else, etc...) from a following statement on the same line. There is more information in the "Formatting Options" section of the documentation.
A new option, "pad-comma", will add a space following a comma. The option "pad-oper" has not been changed and will also add a space following a comma.
A new option, "indent-continuation", will add extra indents to continuation lines following a line that ends with an opening paren '(' or an assignment '='. This includes function definitions and declarations. There is more information in the "Indentation Options" section of the documentation.
All spaces before a comma are now removed. Use the "disable formatting" comment tags if there are arrays with vertical alignment where this is not wanted.
A correction has been made to the Pico style indentation of one line blocks. And there is a fix to always compute the indentation of a one line block. If you use Pico style with an indentation greater than 2, you may have a lot of changes made to the code.
New Objective-C options "pad-return-type" and "unpad-return-type" will add or remove space padding after the Objective-C return type in a method definition. They are described in the "Objective-C" section of the documentation.
New Objective-C options "pad-param-type" and "unpad-param-type" will add or remove space padding after the Objective-C parameter type in a method definition. They are described in the "Objective-C" section of the documentation.
The Objective-C "align-method-colon" option is now applied to Objective-C method calls in addition to method declarations and definitions. The method call colons will be aligned, if possible. If this option is not declared, the method calls will align on the first keyword. See the astyle documentation for an example.
The Objective-C "align-method-colon" has been changed for long keywords. For multi-line arguments when the first keyword is shorter than the others the colons are aligned on the longest line instead of the first line. The alignment includes room for the indentation. This aligns all colons after the first line for a better appearance. Arguments that do not have a short keyword in the first line will remain the same. This style conforms to the Google Objective-C style.
Processing for C++14 single-quote digit separators has been added.
Translations have been added for Bulgarian, Estonian, Greek, Hungarian, Norwegian, and Romanian. The translations were done with an automated translation program, Google Translate, so they may not be the best translation possible. The translations are at the end of ASLocalizer.cpp in the form of an English-Translation pair. If you correct a translation, send the source as a bug report and it will be included in the next release. To add a language, see "Internationalization" in the "General Information" section of the documentation.
The C# example, in the Developer Information has been updated. Objects for the AStyle callback functions are no longer required. These have been removed and the delegates used instead.
There is a new C# example in the Developer Information, that loads the AStyle shared library using explicit linking. This allows the shared library name to be dynamically changed so that a program compiled with "Any CPU" can load either a 32-bit or 64-bit shared library at run-time. It runs on both Windows and Linux.
Visual Studio Code, the text editor from Microsoft, has an Artistic Style extension. The extension runs from the Visual Studio Code menu and is controlled by entries in the User Settings file. It can be installed from Visual Studio Code. There are links to the websites on the Artistic Style Links page.
Thanks to David Faure for his contribution.
The following are additional topics.
The Artistic Style software license has changed. It is now under the MIT license. This is a permissive license which can be used in proprietary software and does NOT require modified Artistic Style source code be made available. It is compatible with the GNU General Public License (GPL) and most other software licenses. The change was made to remove restrictions on using the software and to make it available for any project that wants to use it.
In order to be used on both Linux and Windows, the ASLocalizer.cpp UTF-8 file in Artistic Style does not contain a Byte Order Mark (BOM). With Visual Studio 2015 there has been a change in how UTF-8 files without a BOM are processed. The new procedure is described here. It affects only the language translations in the ".exe" file. The shared libraries and static libraries are not affected. It is necessary only if you are using a translation other than English.
In addition to the "auto detect" option in Tools > Options... > Text Editor > General, an additional compiler option is required. The option "/source‑charset:utf‑8" must be added to the project properties at C++ > Command Line > Additional Options. Since the non‑unicode files in Artistic Style are ASCII, the option can be applied to the entire project instead of just one file. This option has been added in the files distributed with Artistic Style. There is also a new "/validate‑charset" option, which gets turned on automatically with the above option. This switch enables the validation of the UTF-8 input files.
This compiler option was not available until Update 2 of Visual Studio. If you are using an earlier version of 2015, a BOM should be added to the file using File > "Advanced Save Options". Change the encoding to "Unicode (UTF-8 with signature) - Codepage 65001".
In the above "Visual C++ Team Blog" Microsoft mentions that in a future major release of the compiler, they would like to change the default handling of BOM-less files to assume UTF-8.
Visual Studio 2013 and 2015 have an Edit option "Align Assignments" that will align assignment operators across multiple lines. There is also an extension named "Code alignment" that will align the code on other items as well. Other development environments may have something similar. These will selectively align the data and allow for customization of the format.
These options and extensions can be used with Artistic Style. If you choose to do this, the space padding will be maintained and the alignment will be preserved.
Coding style, or programming style, is a set of rules or guidelines used when writing the source code. It is often claimed that following a particular programming style will help in reading and understanding source code conforming to the style, and help to avoid introducing errors.
This Artistic Style distribution has a new "file" folder containing AStyle options files for various coding styles. Using the option files will give approximately the indicated coding style. The files can be used as they are, or modified as desired.
There is a new GUI test program AStyleWx that uses wxWidgets. This replaces the old AStyleWin program. AStyleWx is multi-platform and has more features simply because they are easier to implement with wxWidgets.
It has download files and a website in a new sub-project directory of Artistic Style. The downloads contain source code, documentation, and scripts. The Windows download contains an executable. The needed Artistic Style source files are included.
It is licensed under the MIT license. The source code may be used and modified for any purpose you choose. Developers using Artistic Style in another project may use any part of AStyleWx in their project. The modified source code does NOT need to be made available to others.
The executable in the Windows distribution package is now compiled with a Visual Studio version that will no longer work on Windows XP. Beginning with Visual Studio 2012, auto-vectorization tries to make loops run faster by automatically vectorizing the code. Auto-vectorization is on by default, and there are no compiler switches, #pragmas, or hints to disable it. It uses SSE instructions not available in Windows XP. Microsoft ended support and updates for XP on April 8, 2014, and the usage share percentage continues to decrease.
To compile on a non-XP machine for use on XP, using a compiler other than Visual Studio should always produce an XP executable. Using Visual Studio 2010 or earlier should always produce an XP executable. If you are using Visual Studio 2012, 2013, or 2015 on a non-XP machine, do the following for the Artistic Style configuration you want to use:
In newer releases of Visual Studio 2015, the "Universal CRT" files have been moved. There is a notification here. To compile using XP there may need to be additional include and library directories added. If the compile gets errors add the appropriate directories to the project properties.
Release 2.05.1 (December 2014) is a maintenance release and no new features were added. A list of changes is in the Release Notes. The following information is for the original 2.05 release.
A new bracket style option, "style=vtk", has been added. It uses indented brackets, like Whitesmith, except opening brackets for classes, functions, and methods are not indented. A complete description of the VTK style is available at the "Visualization Toolkit" website (http://www.vtk.org/).
A new preprocessor indent option "indent-preproc-block" will indent preprocessor block statements one additional indent. The block must be top-level, or included within a namespace, and there are restrictions on what can be indented. The option is described in the "Indentation Options" section of the documentation.
A new option, "dry-run", will run Artistic Style without updating the files. The report will be output as usual.
Formatting of source code may now be disabled for portions of a program by embedding special comment tags in the program. These are described in a new "Disable Formatting" section of the documentation. They work the same as in other formatters. There are tags to disable formatting for a block of code, and a tag to disable formatting of a single line. This should allow any custom formatting to be retained.
The product version number has been added to the filename of shared library (DLL) compiles. This will allow multiple versions of a shared library on the same system without conflicts.
An attribute '__attribute__ ((visibility ("default")))' has been added to exported functions on Linux shared libraries. This allows the option "-fvisibility=hidden" to be used on dynamic library compiles. According to the GNU documentation, "Using this feature can very substantially improve linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is strongly recommended that you use this in any shared objects you distribute."
Improvements have been made in the formatting of C++11 uniform initializers (enclosed by brackets). The opening bracket will not be space padded unless it is padded initially. The closing bracket will not be broken from the final line unless it is broken initially. And the known problems with uniform initializers in class constructors have been fixed.
The Windows compiler definition ASTYLE_NO_VCX (no Visual Studio exports) has been changed to ASTYLE_NO_EXPORTS. It is sometimes needed for static libraries on other compilers to prevent error and warning messages.
Qt and Boost macros foreach, forever, Q_FOREACH, and Q_FOREVER will now be recognized as headers.
The main documentation for Artistic Style is in HTML format. Until now there has not been a way to display it from the astyle console program. A new option, "html" or "-!" will display the help documentation in the default browser. This documentation is more complete than the astyle "help" option. It includes examples, and has an index for easier navigation. Since astyle is typically run from a script this should allow an easy way to access the documentation. The option is available only from the command line.
The new "html" option assumes the documentation is installed in the standard install path. This is /usr/share/doc/astyle/html for Linux and the path %programfiles%\AStyle\doc for Windows. If it is installed to a different directory, use the variation "html=<actual_install_path>astyle.html. This option can also be used to open other HTML files. More information is in the "Command Line Only" section of the documentation.
The "html" option on Linux uses the script "xdg-open" from the install package "xdg-utils" to find the default browser. This should be available on most systems. If it is not available on your system you can file a bug report requesting a change. It would be helpful if you could determine how it is done before filing the report. You can also file a bug report if the documentation is not installed to the above "default" directories. The HTML documentation takes quite a bit of effort to maintain and I would like to make it easily available.
The "help" option has been changed to send the output to stdout instead of stderr. This will allow piping and redirection of the output. A common way to use the option on Linux is "astyle --help | less", which will page the display. The "version" option has also been changed to stdout.
A shared library error handler argument has been changed from "char*" to "const char*". In some cases this may cause compile errors in a user program until the references have been changed.
The "Indent Style" topic on Wikipedia states that the "ANSI" style refers to K&R style brackets and not Allman style as used by Artistic Style. The option "style=ansi" is therefore being deprecated and will be removed in a future release. Use one of the other long options instead (style=allman, style=bsd, or style=break).
Some of the documentation has been removed from the distribution package. It still contains all files needed to install and run Artistic Style. The included files can be used without an Internet connection.
There are now build files available for Xcode on Mac. The makefile is still available for those who want it. Both now use the LLVM Clang compiler. There has been a change to the makefile debug locations to make them similar to Xcode. The "Install Instructions" have been updated for both.
The Python Example in the Developer Information now supports Iron Python. The programming instructions are sometimes different since the ctypes module works differently. The example script documents the differences. If you use Python Tools for Visual Studio, it now installs in the Express editions (beginning with release 2.1). Node.js can also be installed in Visual Studio Express.
The executable in the Windows distribution package is now compiled with Visual Studio 2013 and will no longer work on XP. If you are using XP, Artistic Style will need to be recompiled on the XP machine.
A new Visual Studio Community Edition has been released. It is free, combines all of the Express editions into a single development environment, and allows the addition of Visual Studio extensions. There is an AStyle Extension available for installation. It has a graphic interface, adds menu entries, and can be used from within Visual Studio. To install it search the "Extensions and Updates", "Online" entry for "astyle".
Thanks to Peter A. Bigot, HyungKi Jeong, David Faure, and Carl Moore for their contributions.
With a new Artistic Style release some unchanged source files will be formatted because of changes to Artistic Style. You may want to format your source before making program changes in order to bring it up to date.
A new programming language, Objective‑C, has been added to Artistic Style. Four new options, "align‑method‑colon", "pad‑method‑colon=", "pad‑method‑prefix", and "unpad‑method‑prefix" have been added to format the methods. The options are described in a new "Objective‑C" section in the documentation. These new options affect only Objective‑C source code. They have no effect on the other programming languages.
Because of the longer continuation indents sometimes needed for Objective‑C, the option "max-instatement-indent" may need to be increased. If you are not getting the paren and block paren alignment you want, try increasing this value. The default minimum is 40 and the maximum is 120.
A new bracket style option, "style=google", has been added. It uses attached brackets and indents the class access modifiers one-half indent. A complete description of the Google style is available at the google‑styleguide website (https://code.google.com/p/google-styleguide/). The website has standards for several programming languages along with a python program to verify the style and an emacs script for using the style.
A new indent option "indent-modifiers" will indent class access modifiers (public, protected, or 'private) one-half indent. The rest of the class is not indented. It is described in the "Indentation Options" section of the documentation.
Four new bracket modify options, "attach-namespaces", "attach-classes", "attach-inlines", and "attach-extern-c", can be used to modify your selected bracket style. They are described in a new "Bracket Modify Options" section of the documentation.
A new option, "remove-brackets", will remove brackets from conditional statements. The statement must be a single statement on a single line. It is described in the "Formatting Options" section of the documentation.
A new option, "indent-preproc-cond", will indent preprocessor conditional statements (#if #elif, #else, #endif). It is described in the "Indentation Options" section of the documentation. The option "indent-preprocessor" has been deprecated and will be removed in a future release. Use "indent-preproc-define" instead. The processing of preprocessor #define statements has not changed.
A new option, "remove-comment-prefix", will remove a leading '*' from multi-line comments. It is described in the "Formatting Options" section of the documentation. With the syntax coloring of modern editors a leading '*' for comment lines is not as useful as it once was. The current trend is toward code that is easier to maintain. The idea is that a style that is hard to maintain will discourage modification and updating. The converted style should retain most of the formatting within the comment and result in a comment that is easier to maintain. For consistency the option also indents multi-line comments that are not preceded by the '*'. This may slightly modify the indentation of any commented-out code.
The option "pad-first-paren-out" was fixed to not pad if the following paren is empty. This makes the option consistent with "pad-paren-out". To fix empty parens that have been padded run with the option "unpad-paren" in addition to "pad-first-paren-out". This needs to be done only once.
Processing of C++11 raw string literals has been added.
The compiler definition ASTYLE_NO_VCX (no Visual Studio exports) has been changed to ASTYLE_NO_EXPORTS and can be used with any Windows compiler. The Clang compiler needs this option to avoid errors on dynamic libraries. It removes the "__declspec(dllexport)" definition from exported functions. Linux compilers do not use this.
A new shared object (DLL) entry point, AStyleMainUtf16, has been added for processing C# UTF-16 strings. C# does not have built in functions for converting the UTF-16 strings to UTF-8. This entry point will accept UTF-16 strings, format the source code, and return UTF-16 strings. The error handling function and version number still use UTF-8 strings. The C# example program in the "Developer Information" shows the new calling procedure. Changes from the previous release are marked in the example.
C# strings are UTF-16 on both Windows and Linux. C# does not use the UTF-32 wchar_t strings on Linux. Qt also uses UTF-16 on both Windows and Linux, but has built in UTF-8 conversion functions. Qt strings can be converted to UTF-8 by Qt, or the new entry point can be used. There may be other "managed code" applications on Linux that use UTF-16.
The "Links" page has two new sections for links mentioned in previous versions of Artistic Style. It links to free software and other information.
The "Developer Information" section has a new example and download for calling Artistic Style from an Objective‑C program. Since it is another "C" language the only thing needed is to link the program with a library build of Artistic Style. The example was developed on Windows and Linux using the GNUstep project. Since the example is a console program the problems with the GNUstep GUI have been avoided. It has not been tested on a Mac, but should be close to working. The "Developer Information" section also has a new page for "Objective‑C on Windows and Linux" which has information on compiling and running the example on those systems.
The executable included in the Windows distribution was compiled with Visual Studio 2010 (platform toolset v100). Higher releases contain dependencies on Windows API functions that exist only on Windows Vista, Windows 7, and Windows 8. This means that applications built with a Visual Studio 2012 C++ compiler would fail to load and execute on Windows XP.
If you are using Windows Vista or higher, and have a Visual Studio 2012 or higher compiler available, recompiling will probably result in faster execution. If you use a compiler other than Visual Studio, you can probably get better execution by compiling using the C++11 standards. Artistic Style uses a lot of string vectors and the new move semantics will probably result in faster execution.
Thanks to Evmenov Georgiy, Matthew Woehlke, Jiang, Ruzzz, and beta100100 for their contributions.
With a new Artistic Style release some unchanged source files will be formatted because of changes to Artistic Style. You may want to format your source before making program changes in order to bring it up to date.
A new option, "max-code-length=#" or "xC#", will limit the length of code on a line. A new option "break‑after‑logical", or "xL", will modify a line break for conditionals. See the documentation for details.
A new option, "pad-first-paren-out" or "xd", will pad only the first paren in a series on the outside. See the documentation for details.
A new option, "indent=force-tab-tab=#" or "xT#", will allow force tab indents with a tab length that is different than the indent length. See the documentation for details.
The short option for delete-empty-lines has changed from "xd" to "xe".
The C++11 standard for range-based "for" loops, "enum" with a base type, and rvalue references is now supported. The formatting of rvalue references is determined from the existing "align-pointer" and "align-reference" options.
Closing the ending angle brackets of templates is now allowed by the C++11 standard. A new option, "close-templates" or "xy", will close the whitespace in the angle brackets of template definitions. Be sure your compiler supports this before making the changes.
The C/C++ keyword 'extern "C"' in a preprocessor no longer causes an extra indent.
Formatting of C++/CLI managed pointers (the '^' character) has been added to the "align-pointer" option.
The breaking of switch "default" statements has been fixed. The "default" statements that have been incorrectly broken will be fixed in this release.
The byte order mark (BOM) has been removed from ASLocalizer.cpp for all platforms. The encoding of the file is UTF-8. Many Windows editors can now recognize UTF-8 encoding without the BOM. Visual Studio has an option that needs to be set. With others, such as CodeBlocks, identification is automatic. On Linux, UTF-8 is the default encoding.
Translations have been added for Dutch, Finnish, Italian, Japanese, Korean, Polish, Portuguese, Russian, Swedish, and Ukrainian. The translations were done with an automated translation program, Google Translate, so they may not be the best translation possible. The translations are at the end of ASLocalizer.cpp in the form of an English‑Translation pair. If you correct a translation, send the source as a bug report and it will be included in the next release. To add a language, see "Internationalization" in the "General Information" section of the documentation. Send the addition as a bug report and it will be included in the next release.
There is a new Linux makefile for the Clang Compiler. Clang is a free compiler can be installed as a package on many Linux distributions. Some of its features are fast compiles, low memory use, expressive diagnostic messages, and GCC compatibility. It includes a static analyzer tool that finds potential bugs in your source code. An experimental version can be installed on a Windows platform. There is more information in the Install Information documentation.
Visual Studio automatically creates an import library and an export file when you link a program that contains exports. It will do this for even a static library if it contains a __declspec(dllexport) definition. The Artistic Style library (ASTYLE_LIB) build contains such exports, which causes an import library and export file to be created when they may not be needed. A new preprocessor definition, ASTYLE_NO_VCX (no Visual Studio exports) can be declared to eliminate the files from the output. Use this only for static libraries or when the AStyle source is included in the compile. Do NOT use this when compiled as a shared (dynamic) library. It is effective only for Visual Studio 2012. It will NOT work with previous versions. It has no effect with other compilers since they require a separate option to create the import library and export files.
The executable included in the Windows distribution was compiled with Visual Studio 2010 (platform toolset v100). Visual Studio 2012 (platform toolset v110) contains dependencies on Windows API functions that exist only on Windows Vista, Windows 7, and Windows 8. This means that applications built with a Visual Studio 2012 C++ compiler would fail to load and execute on Windows XP. Artistic Style was therefore compiled with Visual Studio 2010 to work on computers using Windows XP.
If you are using Windows Vista or higher, and have the Visual Studio 2012 compiler available, recompiling with Visual Studio 2012 will probably result in faster execution. The Windows distribution has Visual Studio 2012 project files available.
If you use a compiler other than Visual Studio, you can probably get better execution by compiling using the C++11 standards. Artistic Style uses a lot of string vectors and the new move semantics will probably result in faster execution. (To use C++11 on GCC and MinGW use the option --std=c++0x). This may change on future compiler releases.
The "Developer Information" page has a new example and download for calling Artistic Style from a Python script. It will run with both Python 2 and Python 3. Using Python 3 shows an example of formatting a Unicode string with Artistic Style. Unicode strings must be encoded to UTF-8 before formatting and decoded back to Unicode afterward. The example script shows the technique for doing this. It also shows how to set up the function pointers and allocate memory in Python.
If you use Visual Studio on Windows, it can now be used for Python development. Python Tools for Visual Studio (PTVS) is a free and open source plug-in for Visual Studio 2010 that supports Python and Iron Python. Other interpreters such Jython can be added. It can be easily switched between Python versions or different interpreters. But the best thing is the Visual Studio debugging support using the .NET debugger and the normal Visual Studio debugger. It enables you to set break points, step through functions, change the current statement, inspect local variables, and perform other operations while debugging. It is best to use it with a project file, a minor irritation for single page scripts. And there are some minor bugs. But overall it works quite well.
Thanks to Christopher Sean Morrison, Keith OHara, louis6g, and J for their contributions.
Previous releases are available in the News Archives.