|
#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.
|
|
|
|
|
Cool, i like your articles very much, i was looking for something like VLD so i will give it a try, thanks!
|
|
|
|
|
A week ago or so, I noticed the new look of Boost[^] website. But more important, there is a new release with 5 new libraries and many updates for existing ones. This will be the first time I actually build Boost libraries - until now it was handled by a co-worker of mine who has left the company several months ago. Time to learn BJam[^] I guess
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I ran into this book[^] in a bookstore. Generally, I dislike hype very much, and the title of this book is really "Hype to Hype", but I still decided to skim it. The things I expected to find were "how to apply 50 design patterns to write Hello World in Java".
What a surprise! In the very first chapter, author mentions the two most common errors in software design: overengineering and underengineering, and describes how he learned to avoid the first pitfall. Against my expectations, he does his best to warn readers of "patterns panacea" and "pattern happy" programmers. Instead, he advises the use of test driven development, and refactoring to patterns only when a real need justifies it.
I have suffered from both underengineered and overengineered design in my career, but it is the later that actually makes me angry more than the former: I don't want to waste my time learning someone's bloated frameworks that serve no real life purpose, and constrain me in solving real life problems. This kind of behavior is mostly typical of Java culture, which I don't belong to, but recently I have seen the same trend among C# developers, although to a lesser extent: everybody designs their own plug-in frameworks, their own XAML's, their own "enterprise frameworks", and complicate the design of their applications without any real need.
Does anybody remember the "KISS" principle any more? It seems that Joshua Kerievsky does, inspite of the title of his book.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
One of the things I generally liked about Managed C++ (as opposed to i.e. C#) is the support for private virtual functions[^]. Ie. the following code will compile and run fine with MC++:
__gc class Base {
virtual void SomeVirtualFunction()
{Console::WriteLine(S"Base");}
public:
void SomeAccessibleFunction()
{SomeVirtualFunction();}
};
__gc class Derived : public Base {
virtual void SomeVirtualFunction()
{Console::WriteLine(S"Derived");}
};
int _tmain()
{
Base* handle = new Derived();
handle->SomeAccessibleFunction();
return 0;
}
However, take a look at the equivalent C++/CLI (Beta 2) code:
ref class Base {
virtual void SomeVirtualFunction()
{Console::WriteLine(L"Base");}
public:
void SomeAccessibleFunction()
{SomeVirtualFunction();}
};
ref class Derived : public Base {
virtual void SomeVirtualFunction() override
{Console::WriteLine(L"Derived");}
};
int main()
{
Base^ handle = gcnew Derived();
handle->SomeAccessibleFunction();
return 0;
}
(Note the override keyword in the derived class)
This program will compile, but with warnings like:
warning C4486: 'Base::SomeVirtualFunction' :
a private virtual method of a ref class or value class should be marked
'sealed'
However, when the program is run, an exception is thrown:
An unhandled exception of type 'System.TypeLoadException' occurred in
Virtual.exe
Additional information: Method 'SomeVirtualFunction' on type 'Derived'
from assembly 'Virtual, Version=1.0.1999.26811, Culture=neutral,
PublicKeyToken=null' is overriding a method that is not visible from
that assembly.
When comparing the IL generated by the two versions of Managed C++, I found out that C++/CLI adds an attribute strict to the declaration of virtual functions, and that caused this exception at run time.
The explanation came from Microsoft program managers Ronald Laeremans and Brandon Bray: Allowing private virtual functions is a security breach in managed (but not in unmanaged!!!)code, and that's why all Microsoft complers now emit strict .
Take a look at the complete thread here[^]
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
If you have ever thought dispose pattern was simple, read this[^] and you will definitelly change your mind
I just hope C++/CLI will automate this once it is finished.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
wow, i wasnt expecting such a heavy read... It was well worth it though. Thanks
ade me;
while(myKitchen.beerInFridge()) {
me.watchTV();
me.consumeBeer(myKitchen.getBeerCan());
}
|
|
|
|
|
Scary, ha?
The good news is that in C++/CLI you'll just need to write a destructor, and the compiler will take care of the rest.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I guess I was sleepy when I tried this (Windows Forms C#) code:
private void FillList()
{
System.IO.DirectoryInfo di = new System.IO.DirectoryInfo (lblPath.Text);
System.IO.FileSystemInfo[] files = di.GetFileSystemInfos();
lstFiles.ObjectCollection = files;
}
The last line is obviously a mistake, but the error that was reported by compiler could easily make somebody reinstall Visual Studio:
Performing main compilation...
error CS0583: Internal Compiler Error (0xc0000005 at address 535DB559): likely culprit is 'BIND'.
An internal error has occurred in the compiler. To work around this problem, try simplifying or changing the program near the locations listed below. Locations at the top of the list are closer to the point at which the internal error occurred.
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(30,4): error CS0585: Internal Compiler Error: stage 'BIND'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(26,16): error CS0584: Internal Compiler Error: stage 'BIND' symbol 'DefectTrackingConverter.MainForm.FillList()'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(26,16): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'DefectTrackingConverter.MainForm.FillList()'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(26,16): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'DefectTrackingConverter.MainForm.FillList()'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(26,16): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'DefectTrackingConverter.MainForm.FillList()'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(13,15): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'DefectTrackingConverter.MainForm'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(8,11): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'DefectTrackingConverter'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(1,1): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol ''
C:\Documents and Settings\ntrifunovic\My Documents\ChangeManagement\DefectTrackingToVI\DefectTrackingConverter\MainForm.cs: error CS0586: Internal Compiler Error: stage 'COMPILE'
error CS0587: Internal Compiler Error: stage 'COMPILE'
error CS0587: Internal Compiler Error: stage 'BEGIN'
error CS0583: Internal Compiler Error (0xc0000005 at address 536250C6): likely culprit is 'BIND'.
An internal error has occurred in the compiler. To work around this problem, try simplifying or changing the program near the locations listed below. Locations at the top of the list are closer to the point at which the internal error occurred.
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(26,16): error CS0584: Internal Compiler Error: stage 'BIND' symbol 'DefectTrackingConverter.MainForm.FillList()'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(26,16): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'DefectTrackingConverter.MainForm.FillList()'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(26,16): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'DefectTrackingConverter.MainForm.FillList()'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(26,16): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'DefectTrackingConverter.MainForm.FillList()'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(13,15): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'DefectTrackingConverter.MainForm'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(8,11): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol 'DefectTrackingConverter'
c:\documents and settings\ntrifunovic\my documents\changemanagement\defecttrackingtovi\defecttrackingconverter\mainform.cs(1,1): error CS0584: Internal Compiler Error: stage 'COMPILE' symbol ''
C:\Documents and Settings\ntrifunovic\My Documents\ChangeManagement\DefectTrackingToVI\DefectTrackingConverter\MainForm.cs: error CS0586: Internal Compiler Error: stage 'COMPILE'
error CS0587: Internal Compiler Error: stage 'COMPILE'
error CS0587: Internal Compiler Error: stage 'BEGIN'
Build complete -- 23 errors, 0 warnings
My favorite part is this:
An internal error has occurred in the compiler. To work around this problem, try simplifying or changing the program near the locations listed below. Locations at the top of the list are closer to the point at which the internal error occurred.
Just "simplify" the program, and everything should be fine
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
If you ever use the Visual Studio Add-in wizard to generate a skeleton for a VS add-in, pay attention to this piece of code:
catch(System.Exception e)
{
}
Yeah, I know, error handling is not easy, but it can't be replaced by humor.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I decided to play with F#[^], an ML dialect that maps to .NET framework. Reasons? I've never really learned any functional language, and F# looks like an interesting first step. I downloaded the installer from the MS site, and although there were some glitches, I installed it successfuly. It even integrates into VS, although it is far from perfect. Documentation is very poor, so I am mostly using OCaml tutorials for the time being. Here is a simple program in F#:
(* A sample function *)
let avg a b =
let sum = a +. b in
sum /. 2.;;
(* this is what we used to call main *)
let _ =
System.Console.WriteLine(avg 4. 6.);;
Sexy, ah? One thing I hate about C-like languages is curly braces all over the place, and look how cute it looks without them. I might just get to like F#...
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
All those lets in there remind me of GWBASIC
|
|
|
|
|
Consider this piece of code:
#include<new>
#include<iostream>
#include <string>
#include <vector>
using namespace std;
int main()
{
int i = 0;
const wstring rec(1024*1024, L'A');
vector<wstring> korpus;
try
{
for (;;i++)
korpus.push_back(rec);
}
catch (bad_alloc& be)
{
cout << be.what() << " " << i ;
}
catch (exception& e)
{
cout << e.what();
}
return 0;
}
When I run it on my machine, it throws bad_alloc at iteration 711. That means I have roughly 1.4Gb of available heap, which is in line with what I expected. But what if I need more? The ultimate solution is to switch to 64 bits of course, but it may be too early for that: the user needs to have hardware and OS that supports this new architecture. However, it turns to be pretty easy to increase available heap by 50% on existing architectures. Here is the procedure for that:
- Link your application with /LARGEADDRESSAWARE flag. If you don't have the source or don't want to recompile, use the utility Editbin.exe to add this flag to an existing executable.
- On a client machine, add /3GB parameter to boot.ini and restart the machine.
Result: for my test application, the exception is thrown at 1066th iteration - a 50% increase in memory space.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
At a forum I moderate, someone asked why this code results in a linker error:
#include<iostream>
using namespace std;
template<class T>
class SomeClass{
private:
T member;
public:
...
friend ostream& operator<<(ostream &,SomeClass <T>&);
};
template <typename T>
ostream& operator<<(ostream &os, const SomeClass<T>&some){
os<<"( " <<some.member <<") ";
return os;
}
int main(int argc, char* argv[])
{
SomeClass<int> sc(5);
cout << sc;
return 0;
}
It reported that operator << was not found.
The problem is that in the class definition, a friend was declared as a function, not a template function. To make the code link properly, the friend declaration should be changed to:
friend ostream& operator<< <>(ostream &,SomeClass <T>&);
Just another little C++ twist
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
There has been a Code Project survey[^] on the features of an "ideal" language, and also several VB vs C# rants in the Lounge recently. That made me think again: how would my favourite language look like?
Without any doubt, semantics would be modeled after C++[^]. I simply love its static type system, support for value semantics and multi-paradigm nature. One thing I don't like about C++ is the syntax: in my opinion it is too expressive and unreadable. Even Bjarne Stroustrup admits he would have prefered to use Algol 68-like syntax, but C was much more popular.
On the other hand, I like the syntax of Modula-3[^]. Watch this snippet of code:
MODULE MyModule;
IMPORT IO;
PROCEDURE PrintThing(READONLY r: Thing) =
BEGIN
IO.Put(r.name&"\t");
IO.PutInt(r.size);
IO.Put("\n");
END PrintThing;
PROCEDURE MakeThing(n: TEXT; s: INTEGER): Thing =
BEGIN
RETURN Thing{n, s};
END MakeThing;
END MyModule.
Even if you've never programmed with Modula-3 (I didn't), the code is readable and logical. Compare
END MakeThing;
END MyModule.
with (Java or C#)
}
}
However, I don't like Modula-3 semantics: single inheritance, garbage collector on per type basis, no support for type-safe collections, no deterministic finalization.
The solution would be: a language with Modula-3 syntax and C++ semantics. Funny enough, some of the most popular languages are quite opposite: C++ syntax and Modula-3 semantics - in my eyes the worst of both worlds.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Your code snippet in Modula-3 reminds me of Pascal. The simplicity and readability were indeed superior. I fretted when I had to give it up when moving on to windows programming in Borland C++ (ugh!) in the early 90's.
One thing I can't remember was the use of caps. Did it require the use of all caps for BEGIN, END, PROCEDURE, etc...? Unfortunately I'm being lazy tonight and instead of digging my pascal textbooks out of the garage, I thought it easier to ask that question here.
I rate languages nowadays not only for readability, but for typing ease. If caps were required, then my opinion would easily be swayed to say it may not be as nice as I remember it to be. If they were optional, would you still consider the code to be as readable with lower case keywords? I wouldn't mind trading C's curly braces for "begin" and "end".
Anyway, it's nice to see that other's found syntax to pascal more readable and wouldn't mind a hybrid, syntax wise, with C++ without trading out the power of C++.
|
|
|
|
|
bob16972 wrote:
Your code snippet in Modula-3 reminds me of Pascal.
It is not a coincidence. Modula-3 is a direct descendant of Pascal, although not written by Niklaus Wirth (unlike Modula 2 and Oberon).
bob16972 wrote:
One thing I can't remember was the use of caps. Did it require the use of all caps for BEGIN, END, PROCEDURE, etc...?
Pascal does not use caps (actually, it is case-insensitive). AFAIK, they were introduced with Modula -2.
bob16972 wrote:
I rate languages nowadays not only for readability, but for typing ease.
I don't You type once, but read many times. Also, modern IDE's make typing a lot easier these days. In short, I think readability is far more important than ease of typing.
bob16972 wrote:
Anyway, it's nice to see that other's found syntax to pascal more readable and wouldn't mind a hybrid, syntax wise, with C++ without trading out the power of C++.
Yep, it would be great to have something like that. Unfortunatelly, I don't think it is going to happen.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Why not create a language then? You could easily use one of the many compilercompilers out there to create a language you like to write in, and then have it compiled into C++ or other. Ofc, that would add the need of pre-compiling of all files, and debuggin would be horrible, but it's a start
Internet - the worlds biggest dictionary
|
|
|
|
|
ShermansLagoon wrote: Why not create a language then?
Technically speaking, it would be achiavable, if not easy. But making it a mainstream language (users, tools, community) would be all but impossible, IMHO
|
|
|
|
|
Last weekend, Boost[^] 1.32.0 was released.
This relaese contains some really great new libraries, like Assigment Library[^] for quick and easy filling of containers, Boost Multi-index Containers Library [^] for providing multiple indices to values stored in containers (analog to indices in RDBMS), Boost Program Options[^], for command-line parsing and more, Serialization Library[^] - something that I really miss in standard C++, Boost String Algorithms Library[^] which provides additional functionality to C++ strings, like trimming, splitting, etc.
I really look forward to using Boost 1.32.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|