Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am starting to work on a completely new project for Windows Desktops written in C++. When I learned Windows programming, I read that using TCHAR is a great improvement because I can build an ANSI or a Unicode version of my program without changing the code. However, I never really used the option to build the ANSI version. Moreover, in the standard library of C++, there is no TCHAR, I have to create typedefs for std::string, std::stringstream, etc. and their wide string counterparts. So currently I am thinking of abandoning TCHAR in favor of wchar_t, and I collected the following advantages and disadvantages.
Advantages:
TCHAR is a macro, so if I don't use it, the front-end compiler and Intellisense will give better results.
It is more explicit what the type of a variable is.
L"" is easier to type than _T("").
Disadvantages:
Loss of modularity regarding the character type (even though I don't really need the ANSI version, I find using an abstract character type to be a neat feature, and what if in the future I will need a UTF-8 or UTF-32 version?).
I would have to postfix some API functions with W, like GetWindowTextW.
And my questions:
Is there an easier way in the C++ standard library to use TCHAR than the one I described above? Like a standard header file that has these typedefs?
Do you think that my reasoning is correct?
Do I miss any important point?
What is the state-of-the-art solution today? Do professional Windows programmers still use TCHAR (in new code)?
If I remove TCHAR, than should I write L"" or u"" instead of _T("")?
In modern windows all ANSI functions are internally converting char* to wchar_t* and calling unicode versions of same function. Basically, by adopting TCHAR instead of wchar_t you gain nothing, but have to deal with quirky syntax.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 12 months ago.
Improve this question
I've just started doing some Windows programming.
I'm trying to decide how best to handle non-ASCII text.
I'd prefer to use 8-bit characters rather than 16-bit i.e. declare all my strings as char.
I've read the UTF-8 Everywhere proposals, and I think they misrepresent the current state of Windows.
Since Windows 10 version 1803 (10.0.17134.0) support for a UTF-8 page has been implemented to the same standard as other multibyte character encodings.
I think now that I can:
Ensure Visual Studio uses UTF-8 to store source code using an EditorConfig file and use UTF-8 strings by specifying '/utf-8' as an "additional" option in the C/C++/Command Line
Make sure the system knows the program is using UTF-8 character strings by calling setlocale(LC_ALL,".UTF-8"); and/or setting <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage> in the manifest. (The system will actually expect UTF-8 by default if 'Beta: Use Unicode UTF-8 for worldwide language support' is ticked in Region/Language/Administrative language settings/Region Settings - I believe this sets the active code page to UTF-8, and is the default for Windows 11).
Don't define UNICODE and _UNICODE in source, and so use the Win32 'Ansi' interfaces. Windows will convert any text to UTF-16 internally.
Use the standard strings and char variables I'm used to, rather than wstring and wchar.
Have I got this right?
Is there anything else I need to do, apart from watching out for any code that in some way depends on a single character being held in a single byte?
Or is there some gotcha that is waiting to trip me?
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I asked a question about this topic and people say that there is something wrong with my university for teaching me these ancient library. Is it really true and what should I be using instead? Sorry I am still quite new I am in the first year.
Raw C strings are responsible for a significant percentage of security flaws in real world software.
Properly handling buffers is hard, and getting it wrong is depressingly common. There is a use for low level raw memory buffer manipulation of strings, but teaching it first is questionable.
One way of teaching C++ is to teach it as C, then add on some C++ features. Another is to teach it first as C++, and then add on the C compatible sub dialect.
The criticism you are hearing is objecting to the teach C then C++ option.
Learning how to program in C is great; trying to learn both C and C++ at the same time makes you a bad C and bad C++ programmer.
When C++ was first invented, this was a reasonable way to do it. There were C experts but no C++ experts. It has been a few decades since then, and best practices in C++ are no longer that similar to best practices in C, and vice versa.
Knowing what they do is useful since you may encounter ancient code that uses them.
But no, there is no need to use them in modern C++. By modern, I mean something that is being written now or has been written during this millennium.
One of the functions you mentioned, std::strlen is fairly OK to use. Technically you dont need it, but neither is it terribly bad to use.
what should I be using instead?
Most of the time: std::string and std::string_view and their member functions.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've just finished reading Accelerated C++ so I'm still new to C++, but I want to learn Unix/Linux programming (as in command line applications and daemons). I've seen everyone recommending Advanced Programming in Unix Environment but it seems it's C-oriented. I know C++ is drawn from C so I can use every function in book in my C++ project, but for example - when it comes to opening a file: should I use open() from < fcntl.h> (as stated in book), or from < fstream>? Same goes with other functions in book. So, question is whether and when to use POSIX C functions when there are also "corresponding/matching" C++ functions.
The Unix API is C (as is the Windows API); any calls into Unix will look
like C. That doesn't stop you from using C++, however: if the function
requires a char const*, for example, you can call
std::string::c_str() on an std::string.
Whether you want the Unix function (e.g read()) or the C++ (>> on a
stream) depends on what you need. The C++ functionality is generally at
a higher level; read() will only read an array of bytes, for example,
and will not parse integers in text format. On the other hand, you
have a lot more low level control with read() and its assorted
functions; if you need transactional itegrity, for example, you'll need
to use open(), passing it the approriate flags, which aren't available
in std::fstream::open(). More generally, the C++ functions that
involve interaction with the exterior (or with other threads) are built
on the underlying Unix system calls. They provide a higher level of
abstraction, and will generally be simpler to use, but in specific
cases, they may not offer all of the functionality available at the lower levels.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Which is the most common in C++? Is it different between member functions and free functions? Obviously the standard lib uses snake_case for everything, but almost nobody uses that.
A lot of people (including me) prefer the underscore_style. I think from my 20+ years of experience, currently working in a 100.000+ employees company, having reviewed other company's code, etc. I would expect the underscore style to be the most commonly used style. Why? The STL uses it and almost everyone uses the STL. Also, large parts of Boost use it. Of course, there is no way to prove this.
In some domains other style guides or habbits are in place with different naming conventions, but this might be misleading you if you are in such environment to think that it is also common in other places.
To answer your question about member- vs. free functions: I don't think there is a difference wrt the style used.
What I think is most common in C++ is:
Template parameters: They are usually PascalCase.
Macros: They are usually UPPERCASE_UNDERSCORE_STYLE.
Most everything else, including function-, method-, variable- and parameter-names are underscore style.
There are also studies about the underscore style, here's an except from a study from 2010:
Although, no difference was found between identifier styles with respect to accuracy, results indicate a significant improvement in time and lower visual effort with the underscore style.
These studies will IMHO lead to even more adoption of the underscore style in the future. But again, there is no way to prove this (or to predict the future).
It depends. If you're working alone, I'd recommend picking a standard and going with it. If there's some code you're interfacing with, it may make sense to follow that code style.
On projects without a defined style guide, I default to the Google C++ style guide (https://google.github.io/styleguide/cppguide.html).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I need a good Unicode library for C++. I need:
Transformations in a Unicode sensitive way. For example sort all strings in a case insensitive way and get their first characters for index. Convert various Unicode strings to upper and to lower case. Split text at a reasonable position -- words that would work for Chinese and Japanese as well.
Formatting numbers, dates in locale sensitive way (should be thread safe).
Transparent support of UTF-8 (primary internal representation).
As far as I know the best library is ICU. However, I can't find normal developer friendly API documentation with examples. Also as far as I see, it is not too friendly with
modern C++ design, work with STL and so on. Like this:
std::string msg;
unistring umsg.from_utf8(msg);
unistring::word_iterator wi;
for(wi=umsg.words().begin(),n=0;wi!=usmg.words().wi_end(),n<10;++wi,++n)
;
msg=umsg.substr(umsg.words().begin(),wi).to_utf8();
cout<<_("Five 10 words are ")<<msg;
Is there a good STL friendly ICU wrapper released under Open Source license? Preferred is a license permissive like MIT or Boost, but others, like LGPLv2 compatible, are OK as well.
Is there another high quality library similar to ICU?
Platform: Unix/POSIX, Windows support is not required.
Edit: unfortunately I wasn't logged in, so I can't make accept an answer. I have attached the answer by myself.
This question was asked quite a long time before by myself. There was no such library.
So I had written C++ friendly Boost.Locale library that wraps ICU.
Docs: http://cppcms.sourceforge.net/boost_locale/html/
Sources: https://sourceforge.net/projects/cppcms/files/
Edit Now part of Boost: see Boost.Locale documentation
The wxWidgets GUI toolkit has some rather nice string classes and unicode support. You don't need to build/use GUI classes if you don't want to. See here for details.
Does this fit the bill?
http://www.codeproject.com/KB/string/utf8cpp.aspx