Sunday, February 15, 2015

Digest for comp.lang.c++@googlegroups.com - 12 updates in 8 topics

Denis Corbin <dar.linux@free.fr>: Feb 15 06:08PM +0100

Hello world!
 
Just to let you know that a very simple library is now available to
manage threads from C++ code and having exceptions of any type
propagating from a thread to another.
 
Unlike thread support based on C++11, thread support within libthreadar
is not function oriented but class oriented.
 
I found it useful for two of my projects so to avoid duplicating code I
moved it as a separated library which today I let available to anyone
under the Lesser GPL v3.
 
Its name is libthreadar, and it is available at
 
http://libthreadar.sourceforge.net/ (documentation)
http://sourceforge.net/projects/libthreadar/ (source code,etc.)
 
Cheers,
Denis Corbin
Christopher Pisz <nospam@notanaddress.com>: Feb 12 05:13PM -0600

On 2/12/2015 4:33 PM, David Brown wrote:
> it cannot use anything but the standards-specified libraries. With
> those restrictions, you cannot write much of a program on any single
> platform, never mind being portable.
 
That's my point exactly.
 
> #if's as needed, or having some sort of abstraction layer). It also
> usually means using libraries that are designed to facilitate portable
> and cross-platform development, such as Qt or wxWidgets.
 
My opinion has always been that is the same thing as writing a project
for OS A and a project for OS B, but merging it together, when you start
plopping in #if preprocessor directives, scripting up compiler options,
etc. My opinion is that it isn't portable at all, it might actually run
on OS A and OS B after all is said and done, but it certainly won't run
on OS C without more work and it just becomes more difficult to follow.
 
I would think it far easier to create an entirely separate solution for
OS A and an entirely separate solution for OS B, with them sharing the
OS agnostic code from a common library that can be compiled for each.
 
I suppose this common library would be where all the discussion on types
and portability would apply.
 
Those "portable" libraries do the same thing. They're really just
libraries for Windows and Linux merged together into one. I'd rather
have them separated and not deal with keeping track of define this for
that and set this environment variable for that, when building.
 
Portable to me, means it runs on anything, without any trickery to
choose a separate execution path into OS specific code. In that regard,
only interpreted languages can be portable.
 
Cholo Lennon <chololennon@hotmail.com>: Feb 12 05:52PM -0300

On 02/12/2015 04:21 PM, Ian Collins wrote:
>> new core features in several platforms or modify code and recompile the
>> entire base is very, very time-consuming :-(
 
> Are you still using 80s compilers?
 
No... my guidelines are: VC++ 2003/2005/2012, gcc 3.4.1/4.1.2/4.6. My
code has to compile well with all of them (Luckily VC++ 2003 is almost
dead in our production base). I love C++ but I can tell you, is not as
easy as lots of people love to say.
 
 
 
--
Cholo Lennon
Bs.As.
ARG
David Brown <david.brown@hesbynett.no>: Feb 12 11:33PM +0100

On 12/02/15 20:49, Christopher Pisz wrote:
 
> The only truly portable application I could see being done entirely in
> C++ would be something that loaded data from file, manipulated it, and
> saved it to file, from the command line.
 
Being "portable" does not normally mean that exactly the same code is
compiled and linked in exactly the same way for all platforms, and that
it cannot use anything but the standards-specified libraries. With
those restrictions, you cannot write much of a program on any single
platform, never mind being portable.
 
"Portable code" means that the same code base can be compiled for a
variety of systems, using a minimal amount of target-specific code (with
#if's as needed, or having some sort of abstraction layer). It also
usually means using libraries that are designed to facilitate portable
and cross-platform development, such as Qt or wxWidgets.
 
So your portable code can be compiled and linked for Windows, Mac,
Linux, Solaris, or whatever else you want to use - it does not have to
be limited to the libraries and system calls that happen to be in a
common subset of the bare OS's.
Haddock <ffm2002@web.de>: Feb 15 05:55AM -0800

We were using the Sematech CIM Framework back then. It defines static class relationships for a shop floor control system where the material is transferred in carriers from machine to machine. It was quite useful although the real hard park is in the dynamic interactions where this framework from Sematech says nothing about.
 
Couldn't find much about it anymore, though. I only found this:
 
http://dl.acm.org/citation.cfm?id=262809&dl=ACM&coll=DL&CFID=626945930&CFTOKEN=18855310
 
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1561475&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F3468%2F33148%2F01561475.pdf%3Farnumber%3D1561475
 
Maybe you can find it on their homepage: http://public.sematech.org
 
-- Haddock
DSF <notavalid@address.here>: Feb 12 03:11PM -0500

On Tue, 10 Feb 2015 10:11:41 +0100, Marcel Mueller
<news.5.maazl@spamgourmet.org> wrote:
 
 
{big snip}
 
>Maybe you set some string class instance to blank, retrieved its address
>as C compatible char* and then used this as strcpy target. Bad idea!
>I'm just guessing, of course.
 
THANK YOU!!!!
 
Two parts of your paragraph were trigger phrases that lead me right
to the problem. "blank" and "strcpy target".
 
Back in October, Alf P. Steinbach showed me how to avoid having to
create a string array with new with code that expects a pointer to a
string it can use, such as your strcpy above.
 
Instead of:
 
FString output;
 
size_t outputsize;
outputsize = SPrintf(NULL, "%s: %d\n", someotherstring,
somenumber);
char tempstr = new[outputsize+1]
 
SPrintf(tempstr, "%s: %d\n", someotherstring, somenumber);
output = tempstr;
delete[] tempstr;
 
By using:
 
size_t outputsize;
outputsize = SPrintf(NULL, "%s: %d\n", someotherstring,
somenumber);
FString output(outputsize+1); // estab buffer size of output
 
SPrintf(&output[0], "%s: %d\n", someotherstring, somenumber);
 
Note SPrintf is not a typo. I wrote my own printf code to handle
normal and wide characters. Thought I'd increase safety by having
SPrintf return the number of characters (not bytes) if the target is
NULL. (I'm assuming 8-bit characters in the above example.)
 
The Actual Memory Problem:
I have been converting code in various functions that creates a
large C string at the start of the function, adds data, and finally
outputs the string at the end to use FString instead. I had this:
 
LPTSTR output;
output = new TCHAR[8192];
...
SPrintf(output, (LPCTSTR)hlstring, hlid, hlg.hlnumber, hlsz);
...etc.
 
When I changed output to a FString object, I did this:
 
FString output;
...
SPrintf(&output[0], (LPCTSTR)hlstring, hlid, hlg.hlnumber, hlsz);
...etc.
 
See the error? I forgot to give FString an initial buffer value.
And to cut down on overhead of default initializing FString members of
other classes, "FString output;" sets the string pointer member to
point to a static const unsigned int literally called "blank".
 
It became:
 
const FStringSt hlstring(TEXT("Hard Link ID: %s. Hard Links in \
group: %4d. Hard link size: %s.\n"));
FString output;
...
size_t opwidth;
opwidth = SPrintf(NULL, (LPCTSTR)hlstring, hlid, hlg.hlnumber,
hlsz);
output.IncreaseBufferLength(++opwidth);
SPrintf(&output[0], (LPCTSTR)hlstring, hlid, hlg.hlnumber, hlsz);
...etc.
 
 
>many problems.
>I did not take care of wchar_t in my post. Everything which applies to
>char applies to wchar_t as well.
 
I'll do you one better. I have a string template named FStringSt (A
& W) [I used to love their root beer! :o) ] to encapsulate with static
char arrays.
 
>Marcel
 
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
"Norman J. Goldstein" <normvcr@telus.net>: Feb 14 03:35PM -0800

On 02/14/2015 03:02 PM, Jorgen Grahn wrote:
> to assume it follows the standard pattern -- because a std::istream is
> involved, not just because of the ">>".
 
> /Jorgen
 
Both of you make good points -- and I agree with you. The risk of name
clash can be mitigated by putting the overloaded operator into a
namespace. As for usefulness, the following code is quite descriptive
for parsing a text file:
 
string varName;
int varValue;
 
is >> varName >> ":=" >> varValue >> ";";
 
if( is.fail() ) { error }
 
Cheers,
Norm
jt@toerring.de (Jens Thoms Toerring): Feb 15 12:21AM


> string varName;
> int varValue;
 
> is >> varName >> ":=" >> varValue >> ";";
 
In this context it definitely looks much more "natural" than
in your original example, which made me a bit nervous;-) A
nice example that not just the "look" of the oberload itself
but also how it's used in its "natural habitat" can be quite
important in giving an impression of what it will do. I'd
probably still prefer to have a look at the definition, but
when I see it used like this I have some idea what to expect.
 
Best regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 15 07:44AM

On Sat, 2015-02-14, Norman J. Goldstein wrote:
> int varValue;
 
> is >> varName >> ":=" >> varValue >> ";";
 
> if( is.fail() ) { error }
 
I suspected your usecase was something like that, and yes,
it's neat.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
woodbrian77@gmail.com: Feb 14 10:45PM -0800

On Saturday, February 14, 2015 at 11:10:06 PM UTC-6, Stefan Ram wrote:
> ISO page as of 2015-01-01, and possibly even later, as far
> as I remember. So, the publication date might have been
> »backdated« to be in accordance with the name »ISO/IEC 14882:2014«.
 
Nice catch. Sounds like Brian Williams joined the committee.
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
ram@zedat.fu-berlin.de (Stefan Ram): Feb 15 05:09AM

>In 2014, C++14 was »ratified« or »adopted«. But it seems not to
>have been published by the ISO yet. So, is it in effect or not?
 
In the meantime, ISO/IEC 14882:2014 has been published, and
the publication date now is given as 2014-12-15 if I recall
correctly. But this information was not yet visible on the
ISO page as of 2015-01-01, and possibly even later, as far
as I remember. So, the publication date might have been
»backdated« to be in accordance with the name »ISO/IEC 14882:2014«.
legalize+jeeves@mail.xmission.com (Richard): Feb 15 01:15AM

[Please do not mail me a copy of your followup]
 
DSF <notavalid@address.here> spake the secret code
>compared with Visual Studio Express which is lacking several
>components of the Pro version. The only difference is licensing. Can
>you confirm this?
 
I haven't done a bullet-by-bullet feature comparison, but it would
be consistent with previous free editions (i.e. Academic Edition
was the same as Professional IIRC).
 
>Does it require an Internet connection to use?
 
No.
 
The main difference between Community Edition and the previous Express
Editions is that you now have access to a free version that lets you
add-on extensions. This means you can extend VS Community with free
plugins for CMake, Clang, etc., as well as commercial plugins like
Visual Assist X.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
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)