systems we can find, and
using that as a reference regarding how to organize features like
paths, file references, forks, or whatever else? It might help us to
back out of the code and re-examine the problem domain regardless of
the current state
On Wednesday, March 19, 2003, at 04:50 PM, Greg Colvin wrote:
Without runtime library support it will be difficult to do, but not
impossible --
the Oracle runtime has platform-specific code for capturing the stack
trace on all
the of the many platforms we support. I can't post the code, but
cou
I'd say it's primarily the 80-column terminal limit that is the
reasoning for this. I personally only go to 79 columns so that when I
work on a terminal and I type that 80th line the insertion pointer
doesn't wrap.
Aside from that, on my current monitor (1152 pixels wide), I can get 2
CodeWar
On Tuesday, March 4, 2003, at 05:36 PM, Andrei Alexandrescu wrote:
"Brian Gray" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
I can see how vector might benefit from conversion to
vector, but we're talking about contiguous memory here. Very
subject to raw objec
On Tuesday, March 4, 2003, at 12:24 PM, Larry Evans wrote:
Brian Gray wrote:
A raw memory buffer is a good idea. I've rolled my own on a couple
of occasions, but never tried to mimic the style of the STL. That
approach opens up a couple issues:
Since we don't know what's store
On Tuesday, March 4, 2003, at 03:12 AM, Aashit Soni wrote:
Do we have singleton class?
if we dont have that and think to have it - i'd designed one simple
_singleton<> that works good to make parameter class singleton..
I've done much work with singletons, and I've come around to the
opinion tha
A raw memory buffer is a good idea. I've rolled my own on a couple of
occasions, but never tried to mimic the style of the STL. That
approach opens up a couple issues:
Since we don't know what's stored in the memory buffer (image/audio
data, chars from an input stream, serialized structs, etc
On Thursday, February 27, 2003, at 09:15 AM, David Abrahams wrote:
"Sam Partington" <[EMAIL PROTECTED]> writes:
Could it not just be called shared. After all it is merely a more
general
term of shared_ptr. And the type of the resource kind of makes it
implicit.
std::auto_ptr is a non-shared re
On Friday, February 14, 2003, at 09:12 AM, Peter Dimov wrote:
Brian Gray wrote:
At the very end of it, network programmers should be using a
callback-driven interface and not have to worry about multiplexing at
all, but I agree that for now a third layer should be deferred until
the basic
On Friday, February 14, 2003, at 08:38 AM, Jeff Garland wrote:
So in summary, I think we should focus the Boost.Socket effort
on what is currently described as 'level 1 - OS platform layer'
and 'level 2 - basic connectivity layer' leaving multiplexing
for later. I'm sure this will be controversia
On Thursday, February 13, 2003, at 12:08 PM, Jason House wrote:
* How easy will support for SCTP be to work into the boost socket
library? ... and how easy would the interface be to use?
I looked at the docs on www.sctp.de and downloaded the source, and the
fatal flaw seems to be what I found
On Wednesday, February 12, 2003, at 03:11 PM, Jason House wrote:
Once I heard there was a generic socket library in development, I
thought I'd add
a quick feature request. I would like to see the ability to have
multiple
streams through the same socket.
This is pseudo-doable over TCP, by enco
f necessary could install
Linux on one of my PCs.
Whoever is organizing the Boost Sockets effort, feel free to contact me
personally, and we can talk about what needs getting done.
-- Brian Gray
-- [EMAIL PROTECTED]
___
Unsubscribe & other changes: h
13 matches
Mail list logo
