Wednesday, January 13, 2016

Digest for comp.lang.c++@googlegroups.com - 25 updates in 13 topics

JiiPee <no@notvalid.com>: Jan 13 12:21AM

If the program uses string (in files, user interface etc), what is best
to be the default character set type? Unicode? How about if currently
all users are english, does it change anything? So should I chose string
or wstring by default in my projects? Does wstring work mostly the same
as string; do most of the STL functions work the same way as if I used
string? I mean if I use (only) english letters, does wstring version of
STL functions (like find and replace, insert, delete, parse) work the
same way as string versions?
 
Specifically for MFC:
And in Visual Studio MFC project I guess its better to use wstring
rather than CString to manipulate the texts in files?
Like lets say for example I have to split the text in file by commas:
22, 3, 55, 6, 7, 23
 
and find the integers what are there. Is better to use wstring or
CString to parse that? I kind of like wstring, but then I have to
convert wstring to CString later on in the code....because MFC uses
CStrings.
Nobody <nobody@nowhere.invalid>: Jan 13 01:26AM

On Wed, 13 Jan 2016 00:21:40 +0000, JiiPee wrote:
 
> string? I mean if I use (only) english letters, does wstring version of
> STL functions (like find and replace, insert, delete, parse) work the
> same way as string versions?
 
std::string is a typedef for std::basic_string<char>.
 
std::wstring is a typedef for std::basic_string<wchar_t>.
 
Both support the same methods. std::basic_string<T> is more or less
std::vector<T> with a few more methods.
 
The biggest difference is that if you use std::wstring, you will
inevitably find yourself having to convert to std::string and/or char*
occasionally or even frequently. If you use std::string, it's often
possible to never need to use std::wstring or wchar_t* for anything
(although this is somewhat less viable on Windows).
 
OTOH, the Windows OS functions all use wide strings (wchar_t*) as their
"string" type (filenames, registry keys, etc). The versions which take
char* are just shallow wrappers around the wchar_t* functions. If you want
to be able to open any file, regardless of the current locale, you need to
use the wide-string functions (and you'll need to use the non-standard
fstream constructors/methods to open such files as fstreams).
 
For files, the default choice should be UTF-8 if you actually need to
treat the data as text (e.g. you need to use <cctype> functions or
convert to wide strings or whatever).
 
If the data is almost entirely ASCII, you need to be able to "deal with"
whatever the user throws at it, and it doesn't matter if non-ASCII
characters aren't handled entirely correctly, using ISO-8859-* has the
advantage that decoding never fails (any sequence of bytes is valid). So
if the program reads a file that's actually some other "extended ASCII"
encoding, you get a few mojibake characters where UTF-8 would give you a
decoding error.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 13 09:26AM

On Wed, 2016-01-13, JiiPee wrote:
> same way as string versions?
 
> Specifically for MFC:
> And in Visual Studio MFC project [...]
 
I won't try to answer, but is this project a Windows-only thing?
I think the right answer will be different for Windows, or for other
environments.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
seeplus <gizmomaker@bigpond.com>: Jan 13 01:49AM -0800

On Wednesday, January 13, 2016 at 11:21:58 AM UTC+11, JiiPee wrote:
 
> Specifically for MFC:
> And in Visual Studio MFC project I guess its better to use wstring
> rather than CString to manipulate the texts in files?
 
For any future projects in MS/MFC you MUST use Unicode.
As from VS2013 they dropped support for MCBS.
You can get a MCBS plugin for higher VS versions still, but doesn't seem
to be available for Community.
 
MS >> "The goal is to remove MBCS support entirely in a subsequent release.
MFC would then support only Unicode".
 
CString always works.. at least for English, and there is always a suitable converter available both ways for just about any other type.
Paavo Helde <myfirstname@osa.pri.ee>: Jan 13 01:13PM +0200

On 13.01.2016 2:21, JiiPee wrote:
> CString to parse that? I kind of like wstring, but then I have to
> convert wstring to CString later on in the code....because MFC uses
> CStrings.
 
(A word of warning: most of the following is pretty Windows/MFC specific.)
 
If your projects are Windows-only, then always use UNICODE and use
std::wstring. In this case the CString and std::wstring ought to be
functionally the same, both should use UTF-16 encoding. The std::wstring
has a bit safer and nicer interface than CString IMO, but it's up to
your preferences which to use.
 
For better control it might be useful to suppress automatic ANSI-Unicode
conversions built into CString. For that
#define _CSTRING_DISABLE_NARROW_WIDE_CONVERSION
before including MFC headers. The default conversion can then be
restored by CA2W and CW2A where appropriate:
catch(const std::exception& e){
AfxMessageBox(CA2W(e.what()));
 
If your projects are portable e.g. to Linux, then use std::string with
UTF-8 encoding. CStrings cannot be made to use UTF-8, so they should
stay at UNICODE/UTF-16. Inside MFC this means that you cannot use
default conversions or CA2W, instead you need to define your own UTF-8
<--> UTF-16 helper functions and translate the strings immediately
before passing or retrieving them to/from MFC.
 
} catch(const std::exception& e) {
AfxMessageBox(UTF8To16(e.what()));
 
(implementing UTF8To16() left as an exercise to the reader). Note that
for avoiding accidental invalid conversions it is essential to #define
_CSTRING_DISABLE_NARROW_WIDE_CONVERSION if your narrow strings are in UTF-8.
 
 
HTH
Paavo
JiiPee <no@notvalid.com>: Jan 13 01:13PM

On 13/01/2016 09:26, Jorgen Grahn wrote:
> I won't try to answer, but is this project a Windows-only thing?
> I think the right answer will be different for Windows, or for other
> environments.
 
yes this one is what am doing currently. But the same question applies
to all projects though.
oh.. well, I currently do only programs for Windows... so for me its
only Windows. But obviously there is a possiblitity that programs need
to run also on linux etc, so those things might need consideration. So
far all my programs run only in Windows
JiiPee <no@notvalid.com>: Jan 13 01:15PM

On 13/01/2016 09:49, seeplus wrote:
 
> MS >> "The goal is to remove MBCS support entirely in a subsequent release.
> MFC would then support only Unicode".
 
> CString always works.. at least for English, and there is always a suitable converter available both ways for just about any other type.
 
yes it works, but just that is it the most efficient and better than
STL? STL might have better functionality?
JiiPee <no@notvalid.com>: Jan 13 01:23PM

On 13/01/2016 11:13, Paavo Helde wrote:
 
> If your projects are Windows-only, then always use UNICODE and use
> std::wstring. In this case the CString and std::wstring ought to be
> functionally the same, both should use UTF-16 encoding.
 
ok this was a good answer. I ll save this answer.
 
> The std::wstring has a bit safer and nicer interface than CString IMO,
> but it's up to your preferences which to use.
 
STL has also more functionality, isnt it? and it works with C++14.
ONe more thing: If I use wstring and manipulate file first with it and
then pass the result to CString, what is the best way to copy from STL
to CString? they both use UTF-16? -- so can I just copy the data byte by
byte or char by char?
JiiPee <no@notvalid.com>: Jan 13 01:24PM

On 13/01/2016 11:13, Paavo Helde wrote:
 
> If your projects are Windows-only, then always use UNICODE and use
> std::wstring. In this case the CString and std::wstring ought to be
> functionally the same, both should use UTF-16 encoding.
 
ok this was a good answer. I ll save this answer.
 
> The std::wstring has a bit safer and nicer interface than CString IMO,
> but it's up to your preferences which to use.
 
STL has also more functionality, isnt it? and it works with C++14.
ONe more thing: If I use wstring and manipulate file first with it and
then pass the result to CString, what is the best way to copy from STL
to CString? they both use UTF-16? -- so can I just copy the data byte by
byte or char by char?
Ramine <ramine@1.1>: Dec 31 03:18PM -0800

Hello....
 
 
Java have also given almost the same performance as C and C++
in the scimark benchmark, so it is really suitable for math
programming also...
 
So Java is the best !
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 03:11PM -0800

Richard Heathfield:
 
>I realise that.
 
>Ramine, are you aware that you are gaining a reputation for being
>unteachable, illogical, and anti-social? And do you feel about that?
 
 
You have not understood my points Richards Heathfield and others...
 
 
What i am trying to do is to spot the right programming language that
is suitable for many programming categories: such us the web,
the GUI , and concurrent programming, and database programming, and Hard
realtime systems etc.
 
Now in doing so i have realized that C and C++ make the programming
life more difficult, because it's difficult to do some categories
of programming with it, so i have researched the web and i have
also thought more, and i have discovered that Java is
the best tool that simplify those requirements, you can do
with it such us web programming, and GUI programming, and concurrent
programming, and database programming, and Hard realtime software
systems programming etc. with easy, and Java is really suitable for
relatime safety critical systems...
 
 
I have searched the webm and here is the tools that you have to choose
for Java:
 
Use this Java VM for hard realtime:
 
https://www.aicas.com/cms/en/JamaicaVM
 
 
Use this Java tool for concurrent programming
 
http://www.contemplateltd.com/threadsafe/pricing
 
 
And use this Java tool for formal proving of Java code:
 
http://www.eschertech.com/products/perfect_developer.php
 
 
So you have to understand me Sir and Madam that Java with those
tools above makes your chance of surviving higher, and this is
what's really important in my and our life.. so i have finally choosen
Java and FreePascal and Delphi for programming and i have abondonned
C and C++ and Ada.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 12:48PM -0800

Hello,
 
 
Read this about C++ and C:
 
Dynamic Memory Allocation in Critical Embedded Systems
 
http://critical.eschertech.com/2010/07/30/dynamic-memory-allocation-in-critical-embedded-systems/
 
 
It`s why i think that C and C++ are not acceptable for realtime safety
critical systems.
 
 
Please use Java instead with this hard realtime Java VM:
 
https://www.aicas.com/cms/en/JamaicaVM
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 10:51AM -0800

Hello...
 
I wrote:
 
> values. Unlike Ada, there is no a runtime check to make sure the value
> is convertible to the new type. For example, you can readily "convert" a
> negative signed value to an unsigned value.
 
 
And Richard Heathfield answered:
 
--
 
That's perfectly true. For example:
 
unsigned long maxval = -1;
 
That's a good thing, not a bad thing.
 
---
 
 
I think Richard Heathfield that your argument about C++ is stupid,
because in FreePascal you have it both ways, you can have it
the way of C++ if you don`t compile with the -Cr compiler option
and you can have it the Ada way if you compile it with the FreePascal
compiler -Cr option, the FreePascal -Cr compiler option is suitable
for realtime safety critical systems where you have to constrain
the system with an unsigned int and you want at runtime to catch
the exception locally in the function or you want to catch the
exception globally, that`s what you can do in FreePascal and Ada, but
you can not do it in C and C++ , so C++ and C are not suitable
for realtime safety critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 11:56AM -0800

Hello.....
 
 
You must not to believe this Richard Heathfield of comp.programming
that defend blindly C and C++ with some stupid arguments.
 
Because read this, it`s the same that i was saying in my previous post:
 
 
``If you're performing formal verification before testing, you may argue
that run-time checks are a waste of testing time. After all, they are
never going to fail, right? Well, even with full formal verification,
errors might occur. The compiler you are using might be generating the
wrong code; or the linker might introduce an error; or the hardware
itself may be faulty. Even formal verification systems have been known
to contain errors. When we test formally verified software, any test
failure is symptomatic of a fault in the development process, tool
chain, or hardware. If we test throughly and find no errors, this gives
us confidence that the process and tool chain are sound. Testing with
run-time checks enabled (as well as without, if we intend to ship
without run-time checks) and experiencing no run-time check failures
adds to that confidence.``
 
 
Read all here please to understand me more:
 
http://critical.eschertech.com/2010/07/07/run-time-checks-are-they-worth-it/
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 10:28AM -0800

Read again please, i correct...
 
Hello.....
 
I think i am getting crazy with C++, because in
realtime safety critical systems we must take the
programming seriously...
 
The following is true in C++:
 
1. C/C++ provide implicit type conversions between signed and unsigned
values. Unlike Ada, there is no a runtime check to make sure the value
is convertible to the new type. For example, you can readily "convert" a
negative signed value to an unsigned value.
 
Read it here:
 
http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
 
 
But what i don`t understand is that unsigned int is a good thing
to have to constrain more the system, so how can we say that
we don`t have to use unsigned int as say the article above...
i am not convinced because if for example we have different
cases in the source code of a realtime safety critical system
that needs to be constrained to an unsigned int by using
an unsigned int on the left of the assignement and we need
also to catch this exception if at runtime we are out of this
constraint and we can catch the exception with FreePascal
with the compiler option -Cr, but in C++ and C we can not
do it, so this is why in my opinion C++ and C are not suitable for
realtime safety critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 10:23AM -0800

Hello.......
 
I think i am getting crazy with C++, because in
realtime safety critical systems we must take the
programming seriously...
 
The following is true in C++:
 
1. C/C++ provide implicit type conversions between signed and unsigned
values. Unlike Ada, there is no a runtime check to make sure the value
is convertible to the new type. For example, you can readily "convert" a
negative signed value to an unsigned value.
 
Read it here:
 
http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
 
 
But what i don`t understand is that unsigned int is a good thing
to have to constrain more the system, so how can we say that
we don`t have to use signed int as say the article above...
i am not convinced because if for example we have different
cases in the source code of a realtime safety critical system
that needs to be constrained to an unsigned int by using
an unsigned int on the left of the assignement and we need
also to catch this exception if at runtime we are out of this
constraint and we can catch the exception with FreePascal
with the compiler option -Cr, but in C++ and C we can not
do it, so this is why in my opinion C++ and C are not suitable for
realtime safety critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 11:02AM -0800

Hello,
 
 
This was my last post in this forum.
 
 
I just wanted to make my point of view about C++ clear.
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 11:12AM -0800

Hello,
 
 
Sorry Richard Heathfield of comp.programming,
i can not use C++ or C for realtime safety critical systems,
because C++ and C have to make it both ways , the way
of C++ and the way of Ada with its runtime checks.
 
Sorry Richard Heathfield, because of the lack of those
runtime checks of Ada, C++ and C have become dangerous
and not suitable for realtime safety critical systems.
 
 
My point is crystal clear.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 31 10:17AM -0800

Hello.....
 
I think i am getting crazy with C++, because in
realtime safety critical systems we must take the
programming seriously...
 
The following is true in C++:
 
1. C/C++ provide implicit type conversions between signed and unsigned
values. Unlike Ada, there is no a runtime check to make sure the value
is convertible to the new type. For example, you can readily "convert" a
negative signed value to an unsigned value.
 
Read it here:
 
http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
 
 
But what i don`t understand is that signed int is a good thing
to have to constrain more the system, so how can we say that
we don`t have to use unsigned int as say the article above...
i am not convinced because if for example we have different
cases in the source code of a realtime safety critical system
that needs to be constrained to an unsigned int by using
an unsigned int on the left of the assignement and we need
also to catch this exception if at runtime we are out of this
constraint and we can catch the exception with FreePascal
with the compiler option -Cr, but in C++ and C we can not
do it, so this is why in my opinion C++ and C are not suitable for
realtime safety critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 30 01:40PM -0800

Hello....
 
 
I have just took a look to operator overloading in FreePascal and
Delphi, so look at how powerful it is, here is an example:
 
===
 
program OperatorsTest;
 
{$APPTYPE CONSOLE}
 
uses
SysUtils;
 
type
TIntValue = record
private
FValue: Integer;
public
class operator Add(const a, b: TIntValue): TIntValue;
class operator Implicit(const a: Integer): TIntValue;
class operator Implicit(const a: TIntValue): Integer;
property Value: Integer read FValue;
end;
 
{ TIntValue }
 
class operator TIntValue.Add(const a, b: TIntValue): TIntValue;
begin
Result.FValue := a.FValue + b.FValue;
end;
 
class operator TIntValue.Implicit(const a: Integer): TIntValue;
begin
Result.FValue := a;
end;
 
class operator TIntValue.Implicit(const a: TIntValue): Integer;
begin
Result := a.FValue;
end;
 
var
Int: TIntValue;
 
begin
Int := 5;
Int := Int + 10;
WriteLn(IntToStr(Int));
 
end.
===
 
 
 
You can overload the following operators in both FreePascal and Delphi,
read here:
 
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Operator_Overloading_(Delphi)
 
In ADA when you define two types like this:
 
type length is new float;
type weight is new float;
 
You can not assign type length to type weight, this strong typing
of Ada you can do it easily with object oriented programming in
FreePascal and Delphi and C++.
 
So what remains about C and C++ is that in C++ and C you can
not at runtime catch the exception of signed int or unsigned int
overflow or underflow , this is a weakness in C++ and C , but
in FreePascal and Delphi you can easily do it by compiling
with the FreePasal compiler option -Co, after that you can catch the
exception named EIntOverflow like this:
 
try
 
except
on EIntOverflow do HandleIntOverflow;
end;
 
 
And the HandleIntOverflow you can reraise the exception by
returning the name of the function that raised this exception
of the signed or unsigned int overflow or underflow so that to catch the
bugs easily and that's good in realtime safety critical systems, so C++
and C can not do that and this is not suitable for realtime safety
critical system.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 30 02:04PM -0800

Here is my answer to Richard Heatfield on comp.programming:
 
Hello,
 
 
You are making your argument stupid..
 
Because we must have a way in the compiler to discipline the
programmer to not make a mistake, you are saying that in C and C++
you have to test for your logic yourself to not overflow
or underflow, that's not good, because in FreePascal
and Delphi and Ada, if you want the compiler to discipline
you to not make an error of logic that makes you overflow
or underflow a signed or unsigned int, you can compile your program
in FreePascal with -Co compiler option and after that you can locally
catch the exception of overflow or underflow and reraise an exception
to detect the faulty function that caused it, or you can globally
catch the exception, but you can not do that in C++ and C , so
this is why in my opinion C and C++ are not suitable for
realtime safety critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
 
 
 
On 12/30/2015 10:50 AM, Richard Heathfield wrote:
Ramine <ramine@1.1>: Dec 30 03:08PM -0800

Hello....
 
 
I think C++ is good for realtime safety critical systems, because:
 
 
1- You can enforce the strong typing of Ada by using
object oriented programming.
 
2- And you can avoid signed or unsigned int overflow and underflow by
using a secure library that uses operator overloading with
the right tests inside them that catch the signed or unsigned int
overflow and underflow.
 
 
So the case is closed ! so i am convinced now that C++ is good for
realtime safety critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 30 03:01PM -0800

Hello.....
 
 
I think C++ is good for reatime safety critical systems, because:
 
 
1- You can enforce the strong typing of Ada by using
object oriented programming.
 
2- And you can avoid signed or unsigned int overflow and underflow by
using a secure library that uses operator overloading with
the right tests inside them that catch the signed or unsigned int
overflow and underflow.
 
 
So the case is claused ! so i am convinced now that C++ is good for
reatime safety critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
woodbrian77@gmail.com: Jan 12 09:09PM -0800

On Tuesday, January 12, 2016 at 1:42:47 PM UTC-6, gwowen wrote:
 
Please don't swear here.
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
Ian Collins <ian-news@hotmail.com>: Jan 13 06:15PM +1300

> On Tuesday, January 12, 2016 at 1:42:47 PM UTC-6, gwowen wrote:
 
Nothing?
 
> Please don't swear here.
 
He didn't....
 
--
Ian Collins
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)