|
BTW: That IS the user manual.
|
|
|
|
|
Thank you both for your help  I apologise if I came across as really rude in my original post, I only just realised as I re-read my original post.
Regards,
j.t.
j.t.
|
|
|
|
|
|
string pattern = @"((https?|ftp|gopher|telnet|file|notes|ms-help) //)|(\\\\))+[\w\d:#@%/;$()~_?\+-=\\\.&]*)"
Ahsan Ullah
Senior Software Engineer
MCTS 2.0
|
|
|
|
|
Thank you both for your answers and code  though I only have one problem now, where would I put that code you just gave me? Or, how would I use it?
Regards,
j.t.
j.t.
|
|
|
|
|
A simple example would be:
MatchCollection mathes = Regex.Matches(textContent, "(http://[\w\.\?\&]+\w)");
That would give you a collection of matches for (most of) the URLs in the text. Each match contains information about where in the string it was found and the actual URL that was found.
Now, you would use your mad google skillz to find a more advanced regular expression for matching an URL.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
you could also have a look at boost regex - it comes with some examples of parsing url's
'g'
|
|
|
|
|
I'm currently working on a c# project that need winsock in it. WebClient wasn't enought powerfull for my kind of application. So, I writed from scratch all the code to get all thing in my project with a custom webclient. Everything work fine, but I want to improve my code. One of my problem is a function that read byte from the recv function (recv is a c++ winsock function) and then send it to a stream to eventually get an array of byte (byte[]). If you take a closer look to my code, you will see that I copy twice the data. The first time, I make the convertion from byte* (IntPtr receiveBuff) to byte[] and then, I copy again those data to the stream with mem.Write(). I will like to only to it once. Doesn't any body know a better way to do this so I only have to make one copy of my data?
[DllImport("Ws2_32.dll")]
public static extern int recv(SOCKET s, byte* buf, int len, int flags);
public unsafe byte[] RecvAsBytes()
{
MemoryStream mem = new MemoryStream();
int receivedLen;
IntPtr receiveBuff = Marshal.AllocHGlobal(1024);
byte[] receiveBuff2 = new byte[1024];
while ((receivedLen = recv(socket, (byte*)receiveBuff, 1024, 0)) != 0)
{
Marshal.Copy(receiveBuff, receiveBuff2, 0, receivedLen);
mem.Write(receiveBuff2, 0, receivedLen);
}
Marshal.FreeHGlobal(receiveBuff);
return mem.ToArray();
}
|
|
|
|
|
Hi,
the way I usually transfer large amounts of data between a managed (C#) app and some unmanaged (C) code, is as follows:
1. have the managed code allocate a buffer of sufficient size; it could be a byte array in your case.
2. Use GCHandle class to first pin it down, then obtain a pointer to it.
3. Pass the pointer to the native code to get it read and/or written to.
4. Upon return, free the GCHandle and start using the buffer in the managed world.
In summary: no extra copies are made, and Marshal and MemoryStream classes are avoided.
Hope this helps.
|
|
|
|
|
It didn't help that much. Actually, I wasted more time trying to understand why I should use GCHandler instead of Marshal.AllocHGlobal, lol.
I finally figured out a much better way to do that. The only problem if it's problem is that I still use MemoryStream. The reason why I still use it is because I don't have any idea of the size of the received data. This function is used to receive both: html code and image data. The image size can be as large as 1Mb and my application is multithread. So think about that, allocating a 1Mb each time I want to receive data! I want to optimize my algo and make it as strong as I can, so it's a no no. There is still an another way to go with a pool of 1024 bit buffer and a stack, but this will need much more code and time to develop. Maybe one day... But for now, here is my improved code:
public unsafe byte[] RecvAsBytes()
{
MemoryStream mem = new MemoryStream();
int len;
byte[] buffer = new byte[1024];
fixed (byte* ptrBuffer = buffer)
{
while ((len = NativeImport.recv(socket, ptrBuffer, 1024, 0)) != 0)
mem.Write(buffer, 0, len);
}
return mem.ToArray();
}
|
|
|
|
|
Hi,
1.
your code contains two copy operations that add to the RAM footprint and the CPU load:
first you copy data from buffer to mem, then from mem to the final byte array.
(I checked with Reflector: MemoryStream.ToArray creates a whole new array and copies all the data)
2.
there is no need for a memory stream at all. You could:
- create a list of byte arrays;
- allocate a new byte[1024] array inside the while loop, and add these buffers to the a list;
- when that while loop finishes, add together all the sizes of the partial buffers, allocate a new byte[] of total size, then copy each partial buffer directly into the final buffer. You might use Array.Copy to do that, again inside a loop (I suggest a foreach).
Doing so eliminates half of the copy operations without costing more RAM footprint.
3.
Do you really need the possibly huge single byte array as a result? if not, you could forgo all copying. You might return the list of partial byte arrays, or an object that allows to enumerate the data. It all depends on the consumer of RecvAsBytes().
4.
If you really want the total byte array: if the data is originating from a web server, you may know the total size of the data beforehand; have a look at WebResponse.ContentLength; so you could allocate the final array at once, and fill it in your existing while loop.
5.
BTW: in that case you also can get a data stream directly (WebResponse.GetResponseStream). If your data is not coming from a WebResponse object, maybe you should consider modeling it after WebResponse.
6.
Your "fixed" statement and the GCHandle I suggested basically serve the same purpose; your solution is quite acceptable; the main difference is GCHandle does not require the "unsafe" switch, fixed does.
Cheers.
|
|
|
|
|
From what I understand, if a multi-threaded process runs on a single-processor CPU then the process will take advantage of "time-division multiplexing." Does time-division multiplexing offer any real performance advantages in this setup? Are there any specific use cases where this setup would have clear advantages and ROI over a single-threaded process?
|
|
|
|
|
The answer is: it depends (TM)
Using multithreading on a single CPU will provide a better "parallel" feel of your application, because the OS will try to assign CPU time to all threads as equally as possible (according to their priorities). But don't overdo it - using too many threads on a single CPU can yield to lots of costly context switches, which in turn will actually decrease performance of your app.
So use threads cautiously on a single CPU and do some profiling if you feel that it doesn't run as smoothly as you expected.
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Member 3919049 wrote: Does time-division multiplexing offer any real performance advantages in this setup?
No. It simply means that the CPU runs one thread at a time, and by switching threads often it appears as threads run simultaneously.
With a few threads there is little difference from running a single-threaded process. If you have a lot of threads the overhead of switching threads will be greater, leaving less CPU time for actual work.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Member 3919049 wrote: if a multi-threaded process runs on a single-processor CPU
Do you know anybody that still only has one single core?
Nick
----------------------------------
Be excellent to each other
|
|
|
|
|
Yes, many, many, many, many businesses and a ton of home users.
I just built my first multi-core machine THIS WEEK.
|
|
|
|
|
|
I know that, in general, threads run in the context of a process and share memory.
Processes run independently of each other and don't share memory.
Does .NET support the ability for different processes to share memory? It doesn't seem like this would be a very good architecture to implement but is there any use case where this would need to be done. If so then does .NET support this or provide workarounds to support this?
|
|
|
|
|
Windows provides a way to share memory between processes via memory-mapped files, which are treated in much the same way as on-disk files, except that they point to an area in memory instead of an area on disk. Currently in .NET there's no built-in way to use this feature, but there are various wrappers[^] available from third parties, and .NET 4.0 is slated to have a class, System.IO.UnmanagedMemoryAccessor, that will expose memory-mapped file functionality. None of these methods directly make objects from one process available to another, though - that's a much more complex issue, and if that's what you're looking for, it's best addressed by remoting, serialization, or similar architectures.
|
|
|
|
|
I have to write a C# source code with regular indentation.(See list1 for regular style indentation)
and get the same C# source code with S-style indentation.(See list2 for the S-style indentation.)
You may implement it as a console program. (a Windows Form program is ok)
Other requirements : classes should be reusable and scalable. The source code should be readable and concise. The program should be able to overcome exceptions and continue to run.
Scalability requirements : the program should be able to accept and transform C++ source code as well with minimum modification.
List1.cs: regular style indentation
using System;
class MyClass
{
static void Main()
{
Console.WriteLine("Hello World!");
}
}
List2.cs: Banner style indentation
using System;
class MyClass {
static void Main() {
Console.WriteLine("Hello World!");
}
}
Plz tell anyone..its urgent...Plz mail me the code : saurabh.a.pandey@gmail.com
Or contact me on 09948284132.
Thanks in advance.
Regards,
Saurabh
|
|
|
|
|
I wrote the source, it is available Here[^]
Just so you know, absolutely no one (else) will do this here. Learn how to code or pay someone else to do it. Don't exepct it done for free.
|
|
|
|
|
Plz tell everyone..its urgent: Do your own work or pay someone for it! 
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Hopefully you wll get what you need - a fail on the course.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Member for over a year and this is the first impression we get...  Trolling perhaps?
The need to optimize rises from a bad design.
My articles[ ^]
|
|
|
|
|
I love it when people type their home work in here, and just expect someone to do it for them. You're an idiot.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
