Also, every .NET application starts as a normal Win32 application and then calls into the .NET runtime library. The rest of the executable 'contents' is usually MIDL (an intermediate language for .NET), which is then interpreted by the .NET runtime.

In this case, there's nothing you need to do. If something goes wrong, it'll throw a C++ exception. Most likely causes will be that a new element can't be constructed, or that there is insufficient memory. But maybe this is not what you meant. You say you want error checking; why do you want error checking? What is that you want to accomplish? Perhaps the solution is different.

The most elegant approach is to use MapViewOfFile to only map a smaller piece of the file at any one time, one that does fit into your address space, and then shift the view by Unmap/Map-ing. In conjunction with this, a way to slightly extend the limit of what can fit in your address space is to set the /LARGEADDRESSAWARE compiler switch, which can be found under the properties. This tells the compiler that you are aware of that 32 bits pointer can use the full range of 0 - 2^32-1, rather than only half that range 2^31-1. With this, you might be able to reach up to ~3GB, depending on system configuration and your application. However, this only slightly shifts the available memory. Using the above approach, you map the piece of file that you want to use into your address space, and as soon as you are done with the current piece you map the next, etc.

Actually, NTFS is not at all that limited. It's just that the kernel32.dll API interface is limited to those path limits. From MSDN, CreateFile page: In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\\?\" to the path. For more information, see Naming Files, Paths, and Namespaces. By adding \\?\ you tell the kernel32 API to NOT do any parsing or processing on the path, and instead pass it directly on to the filesystem driver. From MSDN page on Naming Files, Paths, and Namespaces (Windows): For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. But not all functions can work with the extended paths, because some functions inherently need to do processing on the path.

Using DLL Export you can export your C/C++ variables and functions to make them available. However, you can not just export an entire class and use it in C#. The direct problem here is that you are accessing a member function (Test) without an instance of your test-class being created. Probably the best way to interface in a class based manner between C++ and C# is to use COM; that is, create a COM class in C++, export it, and then use the COM class in C#.

Use a passwords list; you can find them freely on the web.

You could also sort the list first, then duplicates would show up next to each other.

I always found it very refreshing to learn and know multiple programming languages. I've found that broadening my horizons that way can give me unique insights or alternative looks on coding, which can be helpful and enjoyable. I'd say it also makes communication easier with other programmers, as they might not be proficient in the same languages as you; a broader view of the coding landscape can help. Also, just because one knows multiple languages this doesn't prohibit you from mastering one. It can even help in this regard, as more knowledge is always welcome. That said, I do not believe that just because one only knows one language this means that they are more limited than those who know multiple. As has been noted in this topic by others, it's also very important to be able to tackle problems from multiple angles, regardless of the language. All in all, I'd argue that a change of scenery is a good thing, and that it can never hurt to broaden your view. It can also be a lot of fun to learn a new language, and you don't have to go as far as mastering it. My best programming experience, the most fun I ever had, was learning Common Lisp (I started in VB6 and C++). Has this made me a better programmer? I'd like to think so, if only because I better recognise the strengths and limits of the various languages and platforms out there.

Basically, it doesn't matter what you code, you can always choose to approach it from an OOP perspective. So, then it's just the question of what you want to create. I often create (small) tools, math-gimmicks like prime-number searches, and 'technical test projects' (to test out a specific API/environment/library for the purpose of learning). Others are more inclined to program games, or simulations, for instance. I think a pitfall in this case with creating a program in C++ is that it's all too tempting to use what you know in C and do it like that (though you'll have to consider for yourself if that applies). As soon as you have something you want to create, start thinking about the involved objects and their lifetime. Start simple, for your first project, and limit the complexity and amount of classes. Most of OOP is about dividing functionality and responsibility among classes and determining their lifetime, and modelling the interactions between them. A good strategy is to make each class responsible for exactly one thing and to use a 'black box' principle: other code/classes should only concern themselves with what the class does for them, and not 'how' it does it. A rule of the thumb related to this is that if you start writing code in class1 like class2->memberClass->someMethod() that something is wrong, because now class1 needs to know the rules of class2::memberClass, which violates that black box principle. Of course, this is only a guideline and not necessarily is wrong. Good luck

In addition to what Dave said: see http://msdn.microsoft.com/en-us/library/windows/desktop/aa390460(v=vs.85).aspx[^]

Rather than wring a backspace to the console, which I think can be problematic in certain situations, you could use the ReadKey(true) function:

if (Console.KeyAvailable)
{
// Flush the input buffer, suppressing output(echo) of the input
while (Console.KeyAvailble) Console.ReadKey(true);
// TODO: Print the index here, for instance something like
Console.WriteLine("At index {0}", index);
}

You are most likely right in your conclusion. I think the session 0 isolation prevents such interactions. A possible work-around is to have your Service start or interact with a non-service component that runs in the user session.

You should be aware that all solutions involving wcstombs and related depend on the locale and the typical encoding might not be what you call 'ascii'. Actually, what is called ASCII does not contain any Arabic characters whatsoever. Probably, you are referring to a specific codepage that uses ASCII + some Arabic characters? In that case, it's probably a good idea to set the proper locale before conversion (see Richard MacCutchans post for info), so you get the correct codepage and not, as you probably get with the code given so far, UTF-8 encoding, which means that the text file will contain multiple bytes per character. For instance, see http://stackoverflow.com/questions/2190190/wcstombs-character-encoding[^]. Probably something like setlocale( LC_ALL, "ar.1256" ); will do what you need; it should set the codepage to windows 1256 (which is used for arabic) and use the (generic) Arabic locale. Locales and encoding are a quite complicated issue, so you should be careful and precise when using them. Also, by C++ definition the locale employ system-dependent strings for locale, so if should cater to the platform you are coding for.

A quick search delivered this: http://msdn.microsoft.com/en-us/library/windows/apps/br207308.aspx[^] Might be promising? But, as I said in my previous post, I do not have experience with Win RT apps myself and do not have a clear answer for you. Best regards, Richard

If you use a DLL, that DLL is loaded into your WinRT process space and shares the same security context as the WinRT apps. In other words, you cannot 'escape the sandbox' via a DLL. Unfortunately, I have no experience with programming WinRT, so I can not present you with a solution, only an answer as to why this will not work.

Hey there, Interesting project you have here :) Must be a lot of fun to work on. I see this post was from a week back, so likely you have already figured this out for yourself, but for what it's worth I'll reply. I added a few remarks/comments to your code; I'm not going to nitpick on the finer details, as most of the code looks good! I did notice that you are using the Select Case in an odd way and it's probably best to just make an If-Then-ElseIf statement of it.

Jose Sallamanca wrote:

Anyway, the thing is working, and sending packets only on initial press or release of key(s). The one glitch I've so far detected is that when releasing all the keys, which should send the "z" character and stop the car, the same character that was previously sent is re-sent, rather than the 'stop' character "z".
 
So here's the code, VB 2008:

Private Sub Tmr_Tick(ByVal sender As Object, ByVal e As System.EventArgs) Handles Tmr.Tick
Tmr.Stop()
' You don't need to stop the timer and then restart it. Just let it continue running (or did you find a specific need to restart it?)
 
If Not controlChoice = controlChoicePrev Then
 
'UDP_______________________________________________________

' I see here that you are constantly (every timer tick!) rebinding the udpClient to the target. Luckily, it's UDP so this is not disastrous, but it is
' a bit unnecessary. It's probably a better idea to relocate the GLOIP = .. GLOINTPORT = .. udpClient.Connect(..) to your Form1_Load event handler.
' Also, see my comment 1) at the end for a cautionary tip, which applies when you are running a 32 bits program under 64 bits windows.

' === BLOCK 1 ===
Try
' ------- START of the MOVE (when moved, enclose both in Try-Catch and handle the errors appropriately) -------
GLOIP = IPAddress.Parse("192.168.1.177")
GLOINTPORT = 8888
udpClient.Connect(GLOIP, GLOINTPORT)
' ------- END of the MOVE -------
bytCommand = Encoding.ASCII.GetBytes(cc)
udpClient.Send(bytCommand, bytCommand.Length)
 
Catch ex As Exception
Console.WriteLine(ex.Message)
 
End Try
 
'UDP_______________________________________________________

    End If

' === END BLOCK 1 ===
' === BLOCK 2 ===
If GetAsyncKeyState(Keys.Up) Or

That really depends on how the threads communicate. Does the data reception thread send the data to the GUI thread, or does the GUI poll the data thread. Also important: where and how is the data stored. The biggest issues I foresee are that your data thread could become too fast for the GUI thread and the latter starts lagging behind, or when the GUI thread locks some resource that this could cause the data thread to hang on the lock too much to keep up with the increased data.

Actually, the printed value depends on how the character values (value of ch) is interpreted as a character. For instance, when using Windows console the following mapping (typically) is used: http://en.wikipedia.org/wiki/Code_page_850[^] EDIT: That table only contains the top half (symbol half) of the story. For the lower part, refer to any ASCII documentation, for instance: http://en.wikipedia.org/wiki/ASCII#ASCII_printable_characters[^]

I don't believe C# is much more complicated with this; I think the real difference is that you'd typically let the overloaded operators be member functions in C++ and C# wants them to be static functions. So if you rewrite your C++ code to the static overloading, then you're already having the same code in C# and C++.

Dear Mike, I realise this is a late answer, so maybe you've already figured this out. But maybe it's still worth something, so here goes: I think the short answer is that Yield is absolutely genius. The 'classic' way as you put it actually is the same implementation over and over again, where only the return value varies. What yield does for you is that it allows you to construct an IEnumerable directly from a function (using Yield statements), such that every time MoveNext() is called, the function takes off where it left off until the next Yield statement. So, yes, you can just use yield whenever you want :) I think the only possible issue with it is that it's probably slower than a proper custom ('classic') implementation, so if you have A LOT of elements AND you notice a performance bottleneck in enumeration THEN you might consider getting your hands dirty. Best regards, Richard