|
The current state of the new C++ 09 Standard is summed up here[^].
The best thing I see is that the Garbage Collector is dropped out
|
|
|
|
|
|
It's been a while, but finally the new version of Boost[^] is out.
Among the new libraries there is Boost.Foreach[^] which enables something like:
std::string hello( "Hello, world!" );
BOOST_FOREACH( char ch, hello )
{
std::cout << ch;
}
Also, there are Boost Statechart[^] for easy coding of finite state machines, Expressive[^], a regex library that enables compile time regexes and Boost.Typeof[^] that offers a library-based alternative to the typeof keyword, planned to be introduced in the next version of the Standard.
As for the library updates, I find the performance optimization of Boost.Function significant - now it doesn't use heap at all in some cases.
|
|
|
|
|
It always astonishes me how I learn something new after all these years of programming with C++.
Say you have a built-in array of C++ string objects:
string s1[3] = {"1", "2", "3"};
Declare the second array of the same type, and try to assign the first array to the second one:
string s2[3];
s2 = s1;
and you'll get a compiler error (C2106 with VC++ 8.0).
OK, we all knew that, right? But what happens if we just wrap it in a class:
struct test {
string s[3];
};
test a = {"1","2","3"};
test b = a;
This works just fine: members of b are copies of the members of a .
This is the result of the standard behavior of default copy constructors:
The implicitly-defined copy constructor for class X performs a member-
wise copy of its subobjects. The order of copying is the same as the
order of initialization of bases and members in a user-defined con-
structor (see _class.base.init_). Each subobject is copied in the
manner appropriate to its type:
--if the subobject is of class type, the copy constructor for the
class is used;
--if the subobject is an array, each element is copied, in the manner
appropriate to the element type;
--if the subobject is of scalar type, the built-in assignment operator
is used.
|
|
|
|
|
I have a question regarding this post.
I was reading at the following url:
http://www.fredosaurus.com/notes-cpp/oop-condestructors/copyconstructors.html[^]
That a copy constructor is only called when initalizing a variable in the declaration. If this is true it seems like the code above declares b, then does b = a which would not call the copy constructor.
I compiled and tested your code and it does work so is the link above wrong or am I missing something.
I agree with you about always learning something new with c++. I'm fairly new to it so finding something to learn is easy but it even seems like once I think I know all there is to know about even a part of the language there is yet more to it. Really interesting and fun.
Thanks.
|
|
|
|
|
yadrif wrote: That a copy constructor is only called when initalizing a variable in the declaration. If this is true it seems like the code above declares b, then does b = a which would not call the copy constructor.
Argh, you are right. My sample should really be:
test b = a;
However, it still works because the same logic applies for the default assignment operator.
Sorry for the confusion
|
|
|
|
|
Many developers are shocked by a drop in performance when upgrading an application that uses STL from VC 2003 to VC 2005. The reason for this is that the MS version of the Standard Library has checked iterators[^]switched on by default even in release mode. To turn this feature off, define _SECURE_SCL to be 0 in your project settings; the performance gain is impressive.
|
|
|
|
|
I was happy to learn that an official proposal for introducing lambda expressions to the next version of the C++ Standard was submitted.
According to that proposal, a lambda expression would look like:
<>(int n)->int {return 2*n;}
That may not be very pretty, but who cares - as long as we don't need to write functors for every for_each operation.
The proposal can be found here[^]
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
According to Herb Sutter's PDC presentation[^], for each syntax in C++0x will most likely be modeled after Java, and not after C# or C++/CLI. It may be we will write something like:
for each (int i : v) {...}
rather than
for each (int i in v) {...}
Two small remarks from my side:
1. Isn't C++ too expressive already? I know the C++ standard comitee is very reluctant to introduce new keywords, but the price is too often reduced readability.
2. Is C++ now catching up with Java and C#? Of course, with all these millions of existing lines of code written in C++, being conservative is the only way to go, but where is the fine line between the helthy dose of conservativism and becoming obsolete? For instance, C# 3.0 is getting lambda expressions, and it is going to be released probably in a couple of years. The next version of C++, optimistically called C++0x which may or may not include lambda expressions is far from being adopted, and even when it happens, how long will it take for major compiler vendors to implement its features?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote: Is C++ now catching up with Java and C#?
Nemanja Trifunovic wrote: ut where is the fine line between the helthy dose of conservativism and becoming obsolete?
C++ is already being old, and i don't think the possibly new for each() syntax would "younger" it.
and as you said, yes, C++ is expressive enough to stick with the good'ol' for( ; ; ) ...
TOXCCT >>> GEII power [toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
-- modified at 6:03 Tuesday 31st January, 2006
|
|
|
|
|
|
Pavel Vozenilek wrote: BOOST_FOREACH, a C++ library solution
I know
However, BOOST_FOREACH is not going into C++ 0x.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
> However, BOOST_FOREACH is not going into C++ 0x.
I'd heard some noises that this library solution (and its horrible complexity inside) may serve as proof of feasability and as s hint of real world need, helping to get "native" construct into the language. If that ever happens it'll be years and years from now, though.
The BOOST_FOREACH works with current compilers (even BCB & VC6).
|
|
|
|
|
One of the language features that are likely to get included into the next version of the standard is type inference. Namely, if the compiler can deduce the type of the variable, we can declare it with keyword auto :
auto i = 1;
Many people confuse type inference with variant types, but it is not the case. In the sample above, i is declared as int , not variant . In other words, it is exactly equivalent to:
int i = 1;
Type inference is also going to be included in C# 3.0, but the choice of the keyword is very unfortunate: var . For instance the same construct:
var i = 1;
means one thing in JavaScript (i is variant ) and another in C# (i is int )
How is this useful? It can save us a lot of typing, and annoying syntax errors. Say we have:
vector<int> v;
vector<int>::iterator b = v.begin();
auto e = v.end();
For more information, see the official proposal document.[^]
|
|
|
|
|
i simply don't like this kind of things...
when a programmer knows what he does, yes, it can be safely hidden and the choice can be let to the compiler, but what i see is that rarely programmers (mostly beginners, but hey, programmers anyway) know exactly what the compiler does with their code (implicit conversions, implicit operators calls, etc...).
if we let the choice to the compiler to choose the most appropriated type to a variable, such as variants, then we will loose the power - i fell - of C++, joining the VB road...
Nemanja Trifunovic wrote: How is this useful? It can save us a lot of typing, and annoying syntax errors. Say we have:
as i was saying, just know what you do while code, and everything should be ok...
moreover, don't auto keyword already mean something specific within the C++ language ?!
TOXCCT >>> GEII power [toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
-- modified at 5:58 Tuesday 31st January, 2006
|
|
|
|
|
toxcct wrote: if we let the choice to the compiler to choose the most appropriated type to a variable, such as variants, then we will loose the power - i fell - of C++, joining the VB road...
But there is a big difference: C++ is still statically typed language, and type inference does not mean variants. If someone makes a mistake about the infered type, he will be greeted by a compiler error. With variants, one would end up with a run-time error, which is much worse.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
In general, I try to be somewhat conservative when it comes to adopting new technologies in production work. Sure, it is important to stay informed and try all the latest buzz, but for the work that actually brings food to the table I prefer widely adopted and well tested tools.
Having said all that, I spent last couple of days porting the client side of a distributed linguistic application from VC++ 6.0 to VC++ 8.0 (aka VC++ 2005), and the later was released a couple of weeks ago. That was a two-step operation: first I did the port from 6.0 to 7.1 which I know very well, and once it compiled there, another step was from 7.1 to 8.0.
It was somewhat surprising how many errors appeared in the second step. Most of them actually come from unstandard programming practices that originate in VC 6.0, but were tolerated in VC 7.1 (declarations within for loops, wchar_t a typedef for unsigned short,...), but some of them are really surprising. For instance, I found out that some libraries (xalan, crypto++) compile fine in Release mode, but in compile mode they report compile error C2678 somewhere from xutility. The solution is not exactly obvious: adding a preprocessor definition _HAS_ITERATOR_DEBUGGING=0.
All in all, I like VC 2005 so far. The compiler is better, and IDE has some nice new features: Error window, graying out "ifdef-ed" code, Intelisense is better than ever. The interesting question is C++/CLI. Is it going to be adopted among developers? I wish it did, but frankly it would surprise me: C++ developers don't need .NET, and .NET developers don't know what to do with C++.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I was very impressed to find your code for gcstl.h, but when I try it with Visual Studio 2005, I get these errors:
----------------------------------------------------------------------
C:\spring2007\STL\gcstl>cl /clr:oldSyntax *.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.42
for Microsoft (R) .NET Framework version 2.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
test_gcstl.cpp
C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\xutility(2282) : warning C
4996: 'std::_Copy_opt' was declared deprecated
C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\xutility(2270) : s
ee declaration of 'std::_Copy_opt'
Message: 'You have used a std:: construct that is not safe. See document
ation on how to use the Safe Standard C++ Library'
test_gcstl.cpp(25) : see reference to function template instantiation '_
OutIt std::copy<std::_vector_iterator<_ty,_alloc>,textwriter_iterator<t>>(_InIt,
_InIt,_OutIt)' being compiled
with
[
_OutIt=textwriter_iterator<system::string __gc="" *="">,
_Ty=gcroot<system::string __gc="" *="">,
_Alloc=std::allocator<gcroot<system::string __gc="" *="">>,
T=System::String __gc *,
_InIt=std::_Vector_iterator<gcroot<system::string __gc="" *="">,std::alloc
ator<gcroot<system::string __gc="" *="">>>
]
Microsoft (R) Incremental Linker Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
/out:test_gcstl.exe
test_gcstl.obj
C:\spring2007\STL\gcstl>test_gcstl
abc bac bca
C:\spring2007\STL\gcstl>
-----------------------------------------------------
I used the old syntax option since that was also flagged as an error due to the __gc keyword which I guess is no longer used. I know it is hard to keep up with MS, but wondering if you have upgraded gcstl.h or will? Thanks, Dave
|
|
|
|
|
Hi Dave.
In short, nothing is wrong with my code - the warning is wrong. std::copy is a perfectly valid standard function, and Microsoft has no business deprecating it - only the C++ Standard Comitee has that power. Authors of most other libraries take the same stand as I do - for instance, this is from the Boost[^] home page (scroll down to the Supported Compilers section):
Note: Boost does not support the non-standard "Safe" C++ Library shipping with Visual C++ 8.0, which may result in many spurious warnings from Boost headers and other standards-conforming C++ code. To suppress these warnings, define the macro _SCL_SECURE_NO_DEPRECATE
Best regards.
|
|
|
|
|
#if defined(_MSC_VER) && _MSC_VER >= 1400
#pragma warning(push)
#pragma warning(disable:4996)
#endif
/* your stuff */
#if defined(_MSC_VER) && _MSC_VER >= 1400
#pragma warning(pop)
#endif
Thank you for your reply. I added this wrapper around your code to get rid of the other similar warnings, and it works fine! I like the idea very much.
-Dave
p.s.
cl /clr:oldSyntax /wd4996 test2_gcstl.cpp
These compiler options also work without adding the pragmas, but will I have to use "oldSyntax"? ...or is there a way to update your code to "new" syntax (whatever that is!)
-- modified at 11:21 Sunday 6th May, 2007
|
|
|
|
|
ddtopham wrote: These compiler options also work without adding the pragmas, but will I have to use "oldSyntax"? ...or is there a way to update your code to "new" syntax (whatever that is!)
The new syntax is now called C++/CLI. Apparently there is some sort of converter to automatically convert the "old" Managed C++ syntax to the new one. Also, there is an STL implementation geared towards this new syntax - STL/CLR[^] which makes my gc wrappers pretty much obsolete, so if you want you can check it out as well.
|
|
|
|
|
It is no secret that I am not very impressed with C#. I have worked with it because at one point it was declared a standard language in the company I work for, but I never really enjoyed it. Version 2.0 that is expected to appear in November is an improvement, but still nothing that would tempt me to switch to C# as my primary programming language.
However, I have seen the proposals for C# 3.0, and now I begin to wonder. So far, the new features include:
- type inference[^] for local variables;
- lambda expressions[^];
- anonymous types[^];
- object and collection initializers;
- query expressions;
C# 3.0 looks like a hybrid between an object and a functional language, almost like OCaml. To be honest I never expected C# team to be that brave in introducing new features, especially given the profile of a typical C# developer. It still does not mean I would take it by default for my new projects when I have a chance to choose: lack of performance and the fact that it runs in a managed environment still turn me off; however, just for the curiosity, I might take a good look into it.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nevermind, Happy Birthday .
"I am a lair" Is this statement true or false ?
|
|
|
|
|
|
So, I downloaded Boost 1.33, built it with BJam, and checked it in our VSS database. Having finished the whole exercise much sooner than originally planned, I decided to play a little bit with Boost Thread library. So I ran a simple test:
#include <vld.h>
#include "boost/thread.hpp"
#include <iostream>
void threadFunc ()
{
std::cout << "Hello, thread!";
}
int main()
{
boost::thread th(threadFunc);
th.join();
}
Note the vld.h header. I got into habbit of using the excellent Visual Leak Detector[^] by Dan Moulding, and sometimes I just include it even in the most trivial samples like the one above.
Surprise! The output from VLD:
WARNING: Visual Leak Detector detected memory leaks!
---------- Block 137 at 0x00328DE8: 24 bytes ----------
Call Stack:
c:\myprojects\libraries\boost\v1.33\libs\thread\src\mutex.inl (55): `anonymous namespace'::new_critical_section
c:\myprojects\libraries\boost\v1.33\libs\thread\src\mutex.cpp (48): boost::mutex::mutex
c:\myprojects\libraries\boost\v1.33\libs\thread\src\tss_hooks.cpp (29): `anonymous namespace'::init_threadmon_mutex
c:\myprojects\libraries\boost\v1.33\libs\thread\src\once.cpp (174): boost::call_once
c:\myprojects\libraries\boost\v1.33\libs\thread\src\tss_hooks.cpp (150): on_thread_exit
c:\myprojects\libraries\boost\v1.33\libs\thread\src\thread.cpp (117): thread_proxy
f:\vs70builds\3077\vc\crtbld\crt\src\threadex.c (241): _threadstartex
0x7C80B50B (File and line number not available): GetModuleFileNameA
Data:
A0 3F 14 00 FF FF FF FF 00 00 00 00 00 00 00 00 .?...... ........
00 00 00 00 00 00 00 00 ........ ........
---------- Block 136 at 0x00328AB0: 8 bytes ----------
Call Stack:
c:\myprojects\libraries\boost\v1.33\libs\thread\src\tss_hooks.cpp (29): `anonymous namespace'::init_threadmon_mutex
c:\myprojects\libraries\boost\v1.33\libs\thread\src\once.cpp (174): boost::call_once
c:\myprojects\libraries\boost\v1.33\libs\thread\src\tss_hooks.cpp (150): on_thread_exit
c:\myprojects\libraries\boost\v1.33\libs\thread\src\thread.cpp (117): thread_proxy
f:\vs70builds\3077\vc\crtbld\crt\src\threadex.c (241): _threadstartex
0x7C80B50B (File and line number not available): GetModuleFileNameA
Data:
E8 8D 32 00 01 CD CD CD ..2..... ........
Visual Leak Detector detected 2 memory leaks.
'cpptest.exe': Unloaded 'C:\WINDOWS\system32\dbghelp.dll'
'cpptest.exe': Unloaded 'C:\WINDOWS\system32\version.dll'
What happened here? Let's concentrate on the second one, from tss_hooks.cpp. The function from which the leak is reported looks like this:
void init_threadmon_mutex(void)
{
threadmon_mutex = new boost::mutex;
if (!threadmon_mutex)
throw boost::thread_resource_error();
}
So, the mutex object is created, but apperently never destroyed. Why?
If we look again at the call stack reported by VLD, we'll notice that function init_threadmon_mutex was called by boost::call_once , which in effect means we have a singleton here: threadmon_mutex can be created only once. Therefore, we don't really have a leak here: an object is created on the heap and never destroyed (more precisely, it gets destroyed when the process ends), but that's it. The problem with memory leaks is really repeatingly allocating memory that never gets released, and thus ending up with a crash; with Boost Thread library it can't happen - we can't create threadmon_mutex multiple times, it is a singleton. It is really a "memory drop", not a memory leak.
|
|
|
|
|