Friday, September 12, 2014

Digest for comp.lang.c++@googlegroups.com - 19 updates in 7 topics

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
ram@zedat.fu-berlin.de (Stefan Ram): Sep 12 09:42PM

>"Now, here, you see, it takes all the running you can do, to keep in
>the same place. If you want to get somewhere else, you must run at
>least twice as fast as that!" -- The Red Queen
 
In fact, it suffices to run just ever so slightly
faster than that. »That« is called the »break-even
point«. (Sorry for replying to a signature, I could
not resist.)
Juha Nieminen <nospam@thanks.invalid>: Sep 12 11:10AM

> I read that we could use the following syntax in C++11 with standard
> containers. This is not working for me in msvc 2012.
 
MSVC 2012 is too old. It doesn't support all of C++11.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Lynn McGuire <lmc@winsim.com>: Sep 12 03:47PM -0500

On 9/12/2014 6:10 AM, Juha Nieminen wrote:
>> I read that we could use the following syntax in C++11 with standard
>> containers. This is not working for me in msvc 2012.
 
> MSVC 2012 is too old. It doesn't support all of C++11.
 
Oh man, I hate to think of what you think about MSVC
2005 which we are stuck on.
 
Can MSVC 2013 even produce executables for Windows XP?
Vista? 7?
 
Lynn
Geoff <geoff@invalid.invalid>: Sep 12 02:29PM -0700

On Fri, 12 Sep 2014 15:47:53 -0500, Lynn McGuire <lmc@winsim.com>
wrote:
 
>Can MSVC 2013 even produce executables for Windows XP?
>Vista? 7?
 
Yes. It produces executables for WIN32, this includes NT, 2000, Vista,
XP, 7, 8.x. It can also produce x64 binaries for the Windows 64 bit
OS. It can be used to produce command line tools as well and programs
written in standard C. You might have to deliver a runtime library
with your application, but you can test for that. I have even
translated a C console program to C# just for the fun of it.
 
I hit a few stumbling blocks upgrading from Visual Studio 6.0 to
VS2010 but once I had my projects converted to the new tools I have
never looked back. I think there might be some pain involved going
from VS2005 to VS2013 and you might have to use VS2008 as an
intermediate step if you want to automate the conversion but a lot
depends on the nature of your project and the language and libraries
you're using.
 
Between MS and their tools and frameworks du jour (COM, MFC, ATL,
etc...) and Apple with their variants of Xcode tools and frameworks
they can keep you pretty busy.
 
--
"Now, here, you see, it takes all the running you can do, to keep in
the same place. If you want to get somewhere else, you must run at
least twice as fast as that!" -- The Red Queen
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 12 06:13AM

On Thu, 2014-09-11, SG wrote:
> be as convenient (or even more convenient) as popular IDEs. But it
> probably takes more time to learn compared to a single, well-
> integrated application.
 
I feel the same way about "proper" IDEs like Eclipse (or whatever it's
called when it's used for C++ programming).
 
I've used Unix for all of my work (programming in different languages,
and anything else that requires a computer) since 1996 or so. You
can't help learning the tools over the years (although you will almost
certainly miss some of them).
 
> But maybe it's just me not having come across a nice article
> explaining how to setup editor X, compiler Y, debugger Z and
> accompanioning tools/plugins for language L.
 
You normally don't have to invest in that many new tools for a new
language. Same editor, same build system, same version control.
 
True, teaching people to use Unix could be done much better (unless
there are good books that I'm unaware of).
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Lynn McGuire <lmc@winsim.com>: Sep 12 03:49PM -0500

On 9/10/2014 5:46 PM, Ian Collins wrote:
 
>> Nice! The only real problem that I see is that you
>> have to be running a windowing system.
 
> Are there any IDEs (if you exclude emacs) that don't require a windowing system?
 
Wasn't there a version of Turbo C++ that ran on
DOS?
 
Of course, there was a version of Turbo C for
DOS. I used it and Turbo Pascal religiously.
 
Lynn
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 12 02:22PM -0700

Programmer's Workbench was an integrated text-based IDE in the early/mid 90s. MS C compiler 6.0, 6.1 I believe, and CodeView 4.0, 4.1.
 
I miss the debugger speed of CodeView 3.x.
 
Best regards,
Rick C. Hodgin
szyk100@o2.pl: Sep 12 10:47AM -0700

Hello
I try to compile Corba broker called TAO. And at the begining I need compile ACE (for some unknown reason). I have idea to make my applications multiplatform (at least Windows and Linux). But I have error at the very begining.
Problem lies in file C:\x-unix\ACE_wrappers\ace\GNUmakefile line 21:
include $(ACE_ROOT)/include/makeinclude/macros.GNU
I run bash and type command:
export ACE_ROOT=/cygdrive/c/x-unix/ACE_wrappers
Then I type:
$ mingw32-make
GNUmakefile:21: /cygdrive/c/x-unix/ACE_wrappers/include/makeinclude/macros.GNU:
No such file or directory
mingw32-make: *** No rule to make target '/cygdrive/c/x-unix/ACE_wrappers/includ
e/makeinclude/macros.GNU'. Stop.
 
 
Then I copy path from above error message and call cat program:
 
$ cat /cygdrive/c/x-unix/ACE_wrappers/include/makeinclude/macros.GNU
#-*- Makefile -*-
 
#----------------------------------------------------------------------------
# $Id: macros.GNU 1861 2011-08-31 16:18:08Z mesnierp $
#
# Local and nested target definitions
#----------------------------------------------------------------------------
[[[rest of make file]]]
 
So suprisingly cat can access file but make don't! I am stuck with that! Please tell me what I doing wrong? I want write profesional applications so I need Corba!
This problem doesn't appear under Kubuntu. But I need Corba under Windows (too).
 
 
thank you for your effort
Szyk Cech
Paavo Helde <myfirstname@osa.pri.ee>: Sep 12 01:17PM -0500

szyk100@o2.pl wrote in
 
> Then I copy path from above error message and call cat program:
 
> $ cat /cygdrive/c/x-unix/ACE_wrappers/include/makeinclude/macros.GNU
> #-*- Makefile -*-
 
This has nothing to do with C++, but probably the mingw system does not see
/cygdrive as it is not a cygwin application. Some googling tells me one
needs to mount /cygdrive specially for mingw.
 
hth
Paavo
Martijn Lievaart <m@rtij.nl.invlalid>: Sep 12 09:21AM +0200

On Thu, 11 Sep 2014 15:04:01 -0700, kurt krueckeberg wrote:
 
> managed pointer is the raw pointers are only used internally and never
> exposed to clients. The class looks like this. shared_ptr<Node234> seems
> like needless overhead?
 
It would have masked the problem. Using unique_ptr<> would have exposed
the problem more.
 
 
> template<typename K> class Tree234 {
> protected:
...
> public:
> Tree234() { root = nullptr; }
> ~Tree234();
 
Where is operator=() ??
 
M4
"R. Schubert" <raphael.schubert@gmx.de>: Sep 12 04:55AM -0700

Smart pointers make sense whenever a pointer owns the resource they point to (i.e. whenever it would be used in a call to delete later on), whether it is a single owner expressed through the use of unique_ptr or shared ownership using shared_ptr.
For automatic resource management, you could make root and children unique_ptr, if, which I am guessing is the case, they will only belong to one tree.
 
The parent pointer, however, does not own the pointed-to resource, so it should be a plain pointer. Since we expect the parent to always outlive its children, you should not encounter any dangling pointers there, assuming they are correctly tracked through rotations and the like.
 
Also, as Martijn Lievaart pointed out, whenever you have (owning) pointer members, you should really think about copy behaviour, either forbidding it (by deleting the copy constructor and assignment operator), making a exlicit deep copy or by doing whatever else is appropriate.
Using smart pointers here would also tackle this issue, as they would inject their default behavior into your class: making root a unique_ptr implicitly forbids copying and assignment because its own copy constructor and assignment operator are deleted, while making it a shared_ptr would share it among copies.
CHIN Dihedral <dihedral88888@gmail.com>: Sep 12 10:48AM -0700

On Friday, September 12, 2014 6:04:27 AM UTC+8, kurt krueckeberg wrote:
 
> void insert(K key);
 
> bool remove(K key);
 
> };
 
Don't you use a more powerful hash
to replace the old boring tree opererations in C++?
kurt krueckeberg <kkruecke@gmail.com>: Sep 12 10:48AM -0700

> > Tree234() { root = nullptr; }
 
> > ~Tree234();
 
> Where is operator=() ??
 
I didn't bother to implement operator=() or a copy constructor.
gereon.kremer@gmail.com: Sep 12 12:43AM -0700

Hi everyone,
 
I'm (re-)designing type traits in a library and am kind of stuck.
Our library is about using several number types (along the lines of gmp) for polynomial algebra. For this, we decided to use type traits to distinguish between number types that are integral or are a field and alike.
 
Skimming through the STL, i discovered a bunch of type traits that look like they already kind of do what we want: is_integral, is_floating_point, is_fundamental.
So I decided to simply specialize them and add other ones like is_field.
So, for example, I'd do std::is_integral<mpz_class>::value = true.
However, this automatically makes std::is_fundamental<mpz_class>::value == true, which we do not want (for obvious reasons, I guess).
Now I could also specialize std::is_fundamental<mpz_class>, but this seems like an ugly workaround to me.
 
This basically boils down to the following:
Are the type traits from the STL meant to be extended / specialized for custom types? If so, is there a clear (preferably mathematical) definition of what is_integral or is_arithmetic means?
Or are these type traits only meant to be used for types from the STL and I should simply define my own, even if their functionality is basically the same?
 
Thanks in advance for any hints,
Gereon
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 12 12:03PM +0100

On Fri, 12 Sep 2014 00:43:40 -0700 (PDT)
> type traits only meant to be used for types from the STL and I should
> simply define my own, even if their functionality is basically the
> same?
 
This is an interesting question. On whether you can do it,
§17.6.4.2.1/1 of the C++11 standard states that:
 
"The behavior of a C++ program is undefined if it adds declarations
or definitions to namespace std or to a namespace within namespace std
unless otherwise specified. A program may add a template
specialization for any standard library template to namespace std
only if the declaration depends on a user-defined type and the
specialization meets the standard library requirements for the
original template and is not explicitly prohibited."
 
On 'is_integral' and 'is_arithmetic' in particular, §20.9.2/1 (which
includes those type trait structs) provides that "The behavior of a
program that adds specializations for any of the class templates
defined in this subclause is undefined unless otherwise specified."
This presupposes that there are some type traits amongst these which
are specified elsewhere in the standard as permitted to be specialized,
but I have to say I have not traced what they are, and I should be
interested if you find any. However, they do not appear to include the
ones in which you are interested.
 
Presumably the thinking behind this is that there should never normally
be a need to specialize 'is_integral', 'is_arithmetic' or any of the
other primary or composite type categories in §20.9.4.1 and §20.9.4.2
for user defined types, because these are features that by language
definition only a built-in type can possess. A type is integral if it
meets the definition in §3.9.1/7. It is arithmetic if it meets the
definition in §3.9.1/8.
 
I should have thought it would be less confusing to users of your
library if you provided your own type trait structs for extended
arithmetic types. And I would think it less confusing not to provide
your own type trait which suggests that an extended arithmetic type is
a fundamental type unless in fact it happens to be a typedef for a
fundamental type according to the language definition.
 
Chris
gereon.kremer@gmail.com: Sep 12 04:40AM -0700

Thank you very much for your research on that.
It somewhat confirmed what I already feared.
 
While following your path through the standard, I noticed Note §20.9.4.1/3 stating "For any given type T, exactly one of the primary type categories has a value member that evaluates to true.". As both is_class and is_integral are part of these "Primary type categories", a class that represents integral can either be a class or an integral. This also hints, that is_integral, is_floating_point etc are only intended for native types.
 
So I'll define my own traits...
 
Thanks,
Gereon
Paavo Helde <myfirstname@osa.pri.ee>: Sep 12 01:17AM -0500


> In my case, would you recommend me to move the definition of the
> template to the header file or to do the second solution shown here:
 
> http://www.parashift.com/c++-faq/separate-template-fn-defn-from-
decl.html
 
> The former seems easy enough but I wouldn't like to make a habit
> of it if it happens to be a source of future complications.
 
[for the record: the second solution means explicit instantiation of
templates in a single source file]
 
In software development (and probably especially with C++) you will
notice in time that complexity tends to increase "by itself" and fighting
with the complexity is the most important thing to do. So the rule of
thumb is to always prefer the simplest solution if possible, and here the
first solution (putting all templates in header files) is definitely the
simplest one and means least headaches to write and maintain. Many
template libraries are actually header-only (including many parts of
STL), so the compilers are ready to cope with them.
 
Many people see that the first solution actually has several advantages:
no need to guess which instantiations are required by the program, plus
better optimization possibilities for the compiler (as the function
definitions are visible inline). The only downside is that the compiling
times might become larger, to fight this one can just keep the header
files concsice and include them only in source files which actually need
them.
 
I would suggest to use the second solution (explicit instantiation in a
source file) only when you are experienced enough to decide this is a
better solution.
 
Cheers
Paavo
Wouter van Ooijen <wouter@voti.nl>: Sep 12 10:05AM +0200

Paavo Helde schreef op 12-Sep-14 8:17 AM:
 
> I would suggest to use the second solution (explicit instantiation in a
> source file) only when you are experienced enough to decide this is a
> better solution.
 
That advice totally matches the third law of optimization: optimize only
when you know there is a (speed or other) problem. (The first two law's
are of course "don't" and "don't").
 
Wouter
Juha Nieminen <nospam@thanks.invalid>: Sep 12 11:15AM


> return
> result;
> }
 
You need to instantiate it in *this* compilation unit with every
type it's being used with anywhere else.
 
Unfortunately since C++ does not support export templates (anymore),
the compiler won't do it for you. You'll have to do it manually.
 
If you want to do it like that, you need explicit instantiation
(google for "template explicit insantiation").
 
However, the easiest way is to simply do it like you did in your
first example, and put the implementation in the same header file
where the declaration is.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
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)