|
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.
|
|
|
|
|
Nemanja Trifunovic wrote:
now it is possible to make fully Standard compliant compiler (and libraries) even for platforms that don't support threading.
Yes. It's possible to implement a user-mode threading library - that's all that the pthread library is for Unix/Linux. The threading is supported fully within the user process; the OS doesn't even know (or care) they exist.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
The problem exist even today, not all platforms support files and directories, and yet std::fstream and std::fopen exist in the standard.
|
|
|
|
|
Maybe I'm not understanding everything, but what's the gain for moving thread processing out of the OS domain, and bring it into the language specification of C++?
I've been using CreateThread() with its associated set of API's and it's been working fine that way. What's to be gained by having a C++ 'pthread' when using CreateThread() returns a pointer to the newly created thread anyway.
I must definitely be missing out on something.
William
Fortes in fide et opere!
|
|
|
|
|
CreateThread (or better, __beginthreadex) and pthreads are the "C" way of doing things, and as many other C constructs they are not particulary safe and easy to use. Have you tried Boost threads for instance? That's the C++ way of dealing with threads.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I admit I was not exactly a fan of Simon Robinson[^]. A couple of years ago, I bought his book Professional C#[^] and found out that a more appropriate title would be "C# for total beginners who have too much time to spend on such a simple language as C#". I paid $60.00 for the book and still feel I wasted the money. I really learned C# from C# Language specificatin[^].
However, I recently run into a great offer from Amazon for Robinson's other book Advanced .NET Programming[^]. A used copy was offered for less than $6.00, so I bought it mostly for its low price. The book turned ot to be great: covers the topics I am really interested in, easy to read, practical and useful. A real refreshment among all those .NET books that describe the same basic things.
Good job, Dr Robinson.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I like to program under Unix-like environments. It is fun, and development tools are powerful, flexible and (many of them) free. Also, Unix command line shells are much better than the one that comes with Windows. What I don't like, though, is wasting time on configuring Unix-like operating systems and rebooting between them and Windows. Therefore, I use Unix emulators on Windows.
On my work machine, I have installed Windows Services for Unix (SFU)[^]. It works great with Windows, and it comes with many great tools. Even more utilities can be downloaded from the Interix website[^]. One thing that can't be downloaded for free is X server.
On my home machine, I have installed Cygwin[^], a Linux-like environment for Windows. It comes with many more utilities than SFU (including X), but it can be a little buggy, and the installation proces is awkward. Also, it is slower.
So far, I like both and still haven't decided which one to install on my laptop.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Have you heard of static classes, coming in C# 2.0 (Whidbey)? These are classes which are not intended to be instantiated. They can contain only static members. Ie:
static class Algorithms
{
public static void swap<T>(ref T left, ref T right)
{
T temp = left;
left = right;
right = temp;
}
public static T max<T> (T left, T right) where T : IComparable
{
if (left.CompareTo(right) > 0)
return left;
else
return right;
}
}
Wait a minute! Classes are supposed to be patterns from which objects are instantiated. If you can't instantiate an object from a class, well it is not a class, is it? Why not simply allow non-member methods and group them in namespaces?
I can think of only one reason: marketing. It simply does not look "OO" enough. Although static members of static classes are for all practical purposes non-member methods (with an extra inconvenience that the class' name must be typed each time you invoke them), by keeping them in "static classes" the ilusion of "pure OO" is better preserved.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I rarely take part in Soapbox forum discussions, and generally find them boring. However, this rant was really great - a sort of Declaration of Independence from STL - style programming:
Forofobia[^]
Peterchen[^] seems to be pretty angry with the trend in modern C++ to replace loops with STL-like algorithms. He says, among other things:
Look the framework we have to build to minimise (not remove, just "minimise") writing loops:
iterators. const. unidirectional. bidirectional. reverse iterators. const or not. iterator adaptor. functors. binders. composers. bind. function. lambda library. anything I forgot? most likely. We need to templatize like hell, bending the compiler to a point where we are happy it makes it through our code alive - and when not, we don't dare ask for sensible error messages. To avoid what?
...
It's a loop, for god's sake. It's not a bear trap, it's not the infamous goto-spaghetti mess, it's not a terrorist nuke we have to keep out of our code whatever sacrifice of sanity is necessary.
What can go wrong in a loop?
- you forget to increment
- you are off by one
- you invalidate the container or the iterator
The first requires some discipline, the second some basic calculus training, and the third heaven forbid thinking! whoo!
...
Resolution: From now on I'll call all algorithm aficionados loopophobics. Yes, Scott Myers, this includes you.
Some of the comments from the fellow programmers:
after a certain point, trying to turn C++ into Haskell just creates confusion for anyone unfortunate enough to have to maintain the code.
...
for loops are way too readable, the whole purpose of STL and especially Boost is to enable the production of completely unreadable code that will utterly confuse the slack-jawed imbecile who only knows C# and is asked to maintain my C++ code.
...
This seems to be complexity for complexity's sake, or possibly just to distance itself from anything obvious non-STL
...
Peterchen mentioned Meyers probably because of his article STL Algorithms vs Hand-Written Loops[^] in which he generally favors the use of algorithms rather than loops.
However, I would agree with Meyers' conclusion on this matter:
In the ongoing tussle between algorithm calls and hand-written loops, the bottom line on code clarity is that it all depends on what you need to do inside the loop. If you need to do something an algorithm already does, or if you need to do something very similar to what an algorithm does, the algorithm call is clearer. If you need a loop that does something fairly simple, but would require a confusing tangle of binders and adapters or would require a separate functor class if you were to use an algorithm, you’re probably better off just writing the loop. Finally, if you need to do something fairly long and complex inside the loop, the scales tilt back toward algorithms, because long, complex computations should generally be moved into separate functions, anyway. Once you’ve moved the loop body into a separate function, you can almost certainly find a way to pass that function to an algorithm (often for_each) such that the resulting code is direct and straightforward
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
I am aware of at least three bad attempts to fix C++: Java, C# and D. Some would argue that Managed C++ (C++/CLI) is one of these attempts as well, but I just view it as a set of extensions to C++, not a new programming language.
Now, I found Heron[^], and so far I like what I see.
The main problem with Heron is that it is just another one-man project, and it has close to zero chances of ever becoming mainstram. So far the author has released a Heron front end that converts Heron to C++, an editor, and some (pretty poor and incomplete) documentation.
Having said all of that I really like the philosophy of Heron and most of its features:
- No backward compability with C and all the problems that come with it.
- No virtual functions; polymorphism is achieved through interfaces
- All fields are private
- Support for value semantics, real destructors and deterministic finalization
- No built-in garbage collector
- Rich support for meta-programming
- Support for AOP and design-by contract.
It is a pitty that Microsoft decided to copy Java when they designed C#. Something like Heron would be a much better solution, IMHO.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Thanks for the positive comments and support.
I quite understand your scepticism but I am very confident Heron will become mainstream. There has been a steadily increasing amount of interest in it. There have been a lot of preliminary benchmarks of earlier versions of Heron outperforming C++ when dealing with objects.
The documentation is a bit of a mess because I am now working hard on making a Heron to C translator (essentially a compiler). It is a challenge keeping everything up to date simultaneously.
As far as being a one-man show, many succesful languages fall into that category.
I encourage you to consider joining the Heron mailing list, which is very low-traffic, to keep abreast of new developments at http://lists.sourceforge.net/lists/listinfo/heron-misc
Christopher Diggins
http://www.heron-language.com
|
|
|
|
|
Thank you for commenting my post. I will certanly keep an eye on Heron, and maybe even write an article about it for Code Project some day.
cdiggins wrote:
I am very confident Heron will become mainstream
That would be great. However, the computing world is moving towards "managed environments" (JVM and CLI), and Heron's object model (although technicaly superior, IMHO) does not seem to fit into it very well. Do you think it would be possible to make "Managed extensions for Heron" and how it would impact the language?
Thanks.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|