|
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.
|
|
|
|
|
Last Thursday, a colleague of mine and I were integrating our core C++ libraries into a .NET application, trying to complete a "death march project" that we were invloved in for the last several weeks.
Pretty much everything went smoothly except for one function, and the .NET runtime kept throwing
System.NullReferenceException: Object reference not set to an instance of an object.
into us, whenever this function was called. Of course, the message is totally missleading, but we did not pay any attention on it anyway. Instead, we started checking our declarations on both C++ and C# side. We found following problems:
1. One parameter on C++ side was declared as a reference to a pointer to wchar_t instead of a pointer to wchar_t. We fixed it, but the exception was thrown again.
2. Calling convention was wrong. We used cdecl on C++ side, and specified stdcall on C# side. Again, we fixed it, but the problem remained.
3. We found out that the C++ side had an extra argument that we forgot to add to the C# side. We fixed it, and instead of our beloved System.NullReferenceException , the program would just jump several instructions forward, which would bring us to an endless loop.
4. The last argument of this function was a structure, containing two long and two int variables on C# side, and four int variables on C++ side. We switched the first two C++ variables to __int64 , and it finally worked.
The whole excersise took us between 2 and 3 hours.
Morals of the story?
1. Death-march projects suck big time. When people are under pressure they tend to forget too many "little details" and it comes back in most unexpected ways.
2. "Bridging" between technologies is where a lot of time is lost. If you have a big code base in some "legacy" technology, stick to that technology as long as you can.
3. Never think "I'll just make it work now, and do the right thing later". Later never comes.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Hmmm..... I disagree with "3. Never think "I'll just make it work now, and do the right thing later". Later never comes."
"Later" will come sooner then you expect. And in the end you will have to do "right" thing. So you will do the same job twice: "wrong" and "right" ways.
"We don't need a thinker. We need a doer. Someone who'll act without considering the consequences. "
Homer Simpson
|
|
|
|
|
I guess my attempts to write C# programs in "C++ ways" are totally wrong. However, I just can't resist Last week I came to an idea to derive a struct from IDisposable so that when I declare a variable within a using block, the object is destroyed and the memory is collected immideately, and not when the almighty GC decides to do it for me .
My first attempt looked like this:
struct C : IDisposable
{
public int clan;
public void Dispose()
{
Console.WriteLine("Disposing");
}
}
...
using (C s = new C())
{
s.clan = 1;
}
However, I got a compiler error:
error CS0131: The left-hand side of an assignment must be a variable, property or indexer
At first I was convinced it was a bug in the C# parser. After all, I did try to assign a value to a variable, and the error message is clearly wrong. However, before reporting this issue to Microsoft, I asked a question on a newsgroup[^] about this, and got my answer: When a variable is declared within the resource-acquisition part of the using block, it is read-only and therefore I got the (misleading) compiler error.
A workaround: declare the variable before the using block:
C s = new C();
using (s)
{
s.clan = 1;
}
More about the using statement can be found in Chapter 8.13 of C# Language specification[^]
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Believe it or not, I haven't read this wonderful book[^] before. Now I bought it, and mostly read it in a train during my daily job commute.
In short, this book explains why C++ is the way it is and how it grew up. Rather than trying to create a "pure" and "ideal" language, Dr Stroustrup decided to develop a tool that solves problems he has encountered in practice. He wanted "something" that:
1) Provides powerful abstraction mechanisms that make programming easier and more enjoyable (Simula)
2) Is as efficient as a general-purpose language can be and leaves no room for a lower-level language other than assembly (C).
My favorite quote so far:
I strongly felt then, as I still do, that there is no one right way of writing every program, and a language designer has no business trying to force programmers to use a particular style.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Finally, my article series on missing ISO standard features from VC++ 7.1 is completed. It covers:
1. Exception specifications.[^]
2. Keyword export[^]
3. Two-phase name lookup.[^]
I started writing these articles in San Diego 6 months ago, and finished them a couple of weeks ago in Boston area. Above all, it was a great learning experience. It always amazes me how when I start to write an article on a topic I think to know reasonably well, I discover that my knowledge is really limited, and I improve it during the process of writing.
Now I need to decide what article to write next. I have several good ideas, but given that I don't have much time, probably not all of them will end up as actual articles.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
yesterday evening, after having read your article about Exception specifications, i got back my old dursty "The C++ Language" (from B. S.) and what a surprise, i just found back that paragraph (that i may have read fastly but never really mentionned) talking about Exceptions Specifications. i was quite happy to see that this point was already proposed by Stroustrup and now adopted by the standard (even if it is not well inplemented by MS compilers, but that's another subject).
another thing i mentioned is that you certainly based your article on BJ's - at least - paragraph, because i find the code examples are very close to his... didn't you ?
anyway, i wanted to thank you here to point me out this point i totally forgot from when i read this book...
TOXCCT >>> GEII power [toxcct][VisualCalc 2.20][VisualCalc 3.0]
|
|
|
|
|
Thanks for the comments.
toxcct wrote: another thing i mentioned is that you certainly based your article on BJ's - at least - paragraph, because i find the code examples are very close to his... didn't you ?
You mean the piece of code that demonstrate what the specifications are equivalent to? Yes, of course, I took it from the BS book.
toxcct wrote: anyway, i wanted to thank you here to point me out this point i totally forgot from when i read this book...
You are welcome
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Here is how I usually check for memory leaks in my code. The concept is just a hacked method from a Chris Losinger's article[^].
I use Boost Test Library[^] as my unit-test framework, and at the beginning of init_unit_test_suite function I place the following code:
_CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG );
_CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDERR );
_CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG );
_CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDERR );
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG );
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
_CrtSetReportXXX functions cause memory leak reports to be dumped out to the stderr (in practice, the console window) as well as to the output window within VS IDE. CrtSetDbgFlag is there to make the report be displayed regardless of the place where the program terminates. Otherwise, I would need to manually call _CrtDumpMemoryLeaks(); at my program's exit points.
Also, at the beginning of the unit-test cpp file, after other #include s, I put this:
#include <crtdbg.h>
#ifdef _DEBUG
void* operator new(size_t nSize, const char * lpszFileName, int nLine)
{
return ::operator new(nSize, 1, lpszFileName, nLine);
}
#define DEBUG_NEW new(THIS_FILE, __LINE__)
#define MALLOC_DBG(x) _malloc_dbg(x, 1, THIS_FILE, __LINE__);
#define malloc(x) MALLOC_DBG(x)
#endif // _DEBUG
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
In the best-case scenario, there is no output at all However, if I have a memory leak in, say, mymodule.cpp the output would look like:
Running 2 test cases...
*** No errors detected
Detected memory leaks!
Dumping objects ->
{2455} normal block at 0x00A793E0, 512 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
Press any key to continue
This is helpful in a sense that it tells me I have a memory leak, but it does not tell me where the leak actually happens. To find this out, I add the same code (the bunch that goes at the beginning of the cpp file, not the _CrtXXX calls) at the beginning of the suspicious cpp file(s) (in the worst case scenario, to all my cpp files), and than run unit-tests again. The result:
Running 2 test cases...
*** No errors detected
Detected memory leaks!
Dumping objects ->
c:\myprojects\leakssample\mymodule.cpp(1303)
: {2455} normal block at 0x00A774B8, 512 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
Press any key to continue
Aha! What is at the line 1303 of mymodule.cpp?
char* leak = new char[512];
Bingo!
After I fix a memory leak, I just undo the changes from my source control system to keep the production code cleaner.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Here is a link to the "official wishlist"[^] for changes in the next version of the C++ Standard Library.
Items I really like:
- A threads library
- A socket library
- Explicit support for Unicode
- A way of manipulating files that a part of a directory structure
Items I don't like:
- some form of simple graphic/GUI library (possibly a simple interface to the simpler parts of larger libraries)
- Versions of the standard containers with virtual destructors
For others, I have mixed feelings. Generally they sound good, but maybe we should keep them out of the Standard library.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I found out that a small group of smart people (including Boehm and Alexandrescu) is lobbying for including threading support into the next C++ standard.[^].
This is interesting. So far, we have used threads either from C libraries (Win32 threads, pthreads) or from some C++ libraries built on top of the C ones (Boost Threads, ACE). Now, the proposal is not only to add a threads library to the Standard, but also to make C++ compilers thread-aware.
But what happens on systems where threads simply don't exist?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Simple, you have to target the hardware and select threading or non-threading libs.
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
What I mean is: now it is possible to make fully Standard compliant compiler (and libraries) even for platforms that don't support threading. After a threads library is added, is it going to be possible?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|