Boost

[Nick Baumbach]

Does anybody use Boost code, what is it.

I mean, it has to make things easier, but it does not looks like, since it
takes hours to compile.

[Öö Tiib]

On Friday, 17 January 2014 17:11:24 UTC+2, Nick Baumbach wrote:
> Does anybody use Boost code, what is it.

Boost is collection of about hundred of quite fine open source C++
libraries. Majority of C++ developers have at least tried some of
those.

> I mean, it has to make things easier, but it does not looks like, since it
> takes hours to compile.

Most of boost libraries are header only; you just #include files to use
them in your program. If particular boost library makes things easier or
not depends on if your program needs to do what it does or not.

There are only about dozen of boost libraries that have compiled binary
parts and handful that have optional compiled binary parts. If you don't
even know what boost is and if you need those libraries for anything
then what is the point of compiling them? Also I'm pretty sure that you
can find built binaries from net like with any other open source.

[Alf P. Steinbach]

You can use the header-only sub-libraries without building Boost.

However, the most useful of them are now part of the standard, e.g.
shared_ptr.


Cheers & hth.,

- Alf

[Victor Bazarov]

Plenty of people use Boost code. It does make things easier. If you
don't like it, don't use it. There is very little value in complaining
about something for which you don't have any use, or on which you don't
have any intention to spend any of your precious time.

Here is an analogy: it takes significant time to earn money to buy a car
and to learn to drive one. But once you buy it and start using it, you
often find that it does make your life easier. It's called "investment".

If you think that a few hours of compilation is not worth the return
that you might get from using Boost after you have prepared it for your
use, then don't spend those few hours. Life's too short.

V
--
I do not respond to top-posted replies, please don't ask

[Nick Baumbach]

How do I know whether I need it.

[Nick Baumbach]

n wrote:

> If you think that a few hours of compilation is not worth the return
> that you might get from using Boost after you have prepared it for your
> use, then don't spend those few hours. Life's too short.

Can't you read, how do one knows that Boosts code is needed. What can
Boost do, I can'd do simpler and ergo, faster.

More code added increase complexity, unnecessary.

[Drew Lawson]

In article <lbbjle$38q$2...@speranza.aioe.org>

Nick Baumbach <ni...@iwqoc.org> writes:
>n wrote:
>
>> If you think that a few hours of compilation is not worth the return
>> that you might get from using Boost after you have prepared it for your
>> use, then don't spend those few hours. Life's too short.
>
>Can't you read, how do one knows that Boosts code is needed. What can
>Boost do, I can'd do simpler and ergo, faster.

http://www.boost.org/doc/libs/1_55_0/

Start reading and see if anything there is useful to you.
We do not know what your projects are, so have no way of knowing
what you need.

>More code added increase complexity, unnecessary.

The flip-side is reinventing the wheel, wasted time, fixing the
same bugs that boost already worked through.

I don't use boost much, so I can't sell you on the idea.

--
Drew Lawson So risk all or don't risk anything
You can lose all the same

[Victor Bazarov]

I think the guiding principle here is "if you need to ask, you probably
have no use for it. Yet."

Here is the metaphor I think is applicable here. Can you dig a ditch
using your spade? Would an excavator help? Not really, if a ditch is
but a few feet long and a foot deep and the soil is loose and light.
You would only use an excavator if the amount of work warrants it. Of
course, if you already have an excavator on site, using it to move even
a bit of earth costs you almost nothing and can save some time, compared
to digging with a spade, even a mere few cubic feet of dirt.

Read about Boost, learn about the problems people solved using it. Some
here might tell you about it, but using Boost's online forum is probably
more effective. If you find that you can solve some problem with it,
then get it, invest some time learning it. Or don't.

[Nick Baumbach]

n wrote:

> Read about Boost, learn about the problems people solved using it. Some
> here might tell you about it, but using Boost's online forum is probably
> more effective. If you find that you can solve some problem with it,
> then get it, invest some time learning it. Or don't.

And now please answer the question. Only if you can, I did not asked for
noise.

[Victor Bazarov]

Your original post did not contain any questions. It only contained a
childish whine about the perceived difficulty of compiling Boost. Learn
to ask questions. Visit this page:
http://www.catb.org/~esr/faqs/smart-questions.html

As Drew Lawson write here

On 1/17/2014 10:59 AM, Drew Lawson wrote:
> [..]

> We do not know what your projects are, so have no way of knowing
> what you need.

consider telling us what it is you do, what problems you're trying to
solve, _before_ anyone could tell you to use some specific part of Boost
or to skip it altogether.

And now please ask your questions. Or don't.

[Jorgen Grahn]

I suspect that Stroustrup sums it up nicely:

http://www.stroustrup.com/bs_faq.html#boost

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Robert Wessel]

And just what part (or all) of Boost is going to require hours of
compilation time? Sounds like a troll to me...

[Paavo Helde]

Robert Wessel <robert...@yahoo.com> wrote in
news:ck3jd9hvrjo7eio0i...@4ax.com:

> And just what part (or all) of Boost is going to require hours of
> compilation time? Sounds like a troll to me...

Figuring out how to get the bjam (or b2 or whatever it is called nowadays)
compilation to work and then building all possible variants
(static/dynamic/debug/nodebug/32-bit/64-bit/static runtime/dynamic runtime
etc) of all existing compilable Boost libraries can indeed take hours on a
mediocre machine. Not that it's needed for anything, it's just the simplest
approach if someone has no idea what he wants.

Cheers
Paavo

[woodb...@gmail.com]

On Friday, January 17, 2014 9:11:24 AM UTC-6, Nick Baumbach wrote:
> Does anybody use Boost code, what is it.
>

I use the Boost Intrusive library.

> I mean, it has to make things easier, but it does not looks like, since it
> takes hours to compile.

I think parts of Boost, like the containers, are great.
Other parts of Boost are not so great.

Brian
Ebenezer Enterprises - Heavenly code.
http://webEbenezer.net

[Robert Wessel]

For grins, I just did a "bootstrap" / ".\b2" of a freshly downloaded
Boost 1.55.0 on an eight year old 2.8GHz dual core Pentium 4 (a
Pentium D), rotating disk, 4GB, WinXP, and running some other stuff as
well (so both cores were maxing out at times). I'm not sure how much
more mediocre we can practically get.

Wall clock was 53 minutes. And that's long by a bit, since I was away
from the PC when the bootstrap finished, but from the look of the time
stamps, about two minutes, and as I mentioned, I was using the machine
for other things as well. So let's call it 50 minutes on that
machine.

Admittedly MSVC is usually a faster compiler than GCC...

[woodb...@gmail.com]

On Friday, January 17, 2014 9:37:16 AM UTC-6, Alf P. Steinbach wrote:
>
> You can use the header-only sub-libraries without building Boost.
>
>
> However, the most useful of them are now part of the standard, e.g.
> shared_ptr.
>

I think std::array would be a better example. I still
don't find much need for shared_ptr.

Brian
Ebenezer Enterprises
http://webEbenezer.net

[Ian Collins]

woodb...@gmail.com wrote:
> On Friday, January 17, 2014 9:37:16 AM UTC-6, Alf P. Steinbach wrote:
>>
>> You can use the header-only sub-libraries without building Boost.
>>
>>
>> However, the most useful of them are now part of the standard, e.g.
>> shared_ptr.
>>
>
> I think std::array would be a better example. I still
> don't find much need for shared_ptr.

Maybe you don't but others certainly do!

--
Ian Collins

[Ian Collins]

On a more up to date machine with gcc:

time ./b2 -j 32

<stuff>

The Boost C++ Libraries were successfully built!

real 1m2.319s
user 27m57.961s
sys 1m49.214s

--
Ian Collins

[woodb...@gmail.com]

On Friday, January 17, 2014 6:09:45 PM UTC-6, Ian Collins wrote:
>
> Maybe you don't but others certainly do!
>

I think Mr. Stroustrup's comments on shared_ptr
are helpful.

At the 46 minutes and 43 second mark here:

http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Interactive-Panel-The-Importance-of-Being-Native

He says he wouldn't list shared_ptr in his top ten
C++ 2011 features. I agree.

I think it's a good idea to review/minimize your use
of unique_ptr and to be even more wary of shared_ptr.

Brian
Ebenezer Enteprises - So far G-d has helped us.
http://webEbenezer.net

[Nick Baumbach]

Robert Wessel oratorically vehemently insists

> And just what part (or all) of Boost is going to require hours of
> compilation time? Sounds like a troll to me...

Sir, you do not contribute! YOU seemingly are the troll here.

Or, alternatively, are fucking stupid. In any case, stop infesting this
thread with nonsense and leave!

[Nick Baumbach]

Ian Collins oratorically vehemently insists

> On a more up to date machine with gcc:
>
> time ./b2 -j 32
>
> <stuff>
>
> The Boost C++ Libraries were successfully built!
>
> real 1m2.319s user 27m57.961s sys 1m49.214s

Wow, -j 32 !! Say no more. Where did you find that 32 since at most I only
can find 16, as 2 threads per core. Actually thread core, not real core.
An i7 is still a 4 core, not sure how that threaded core is embedded into
the hardware.

Please elaborate

[Nick Baumbach]

Victor Bazarov wrote

>> And now please answer the question. Only if you can, I did not asked
>> for noise.
>
> Your original post did not contain any questions. It only contained a
> childish whine about the perceived difficulty of compiling Boost. Learn
> to ask questions. Visit this page:

Sir, you are violating the unwritten rules of usenet, insisting making
noise instead of relating to the issue in the post.

You are insignificant. Read the fucking subject line. Better yet, just
leave.

[Ian Collins]

Dual 8 core Xeon E5 and plenty of RAM.

--
Ian Collins

[Qu0ll]

"Nick Baumbach" wrote in message news:lbdef7$5av$9...@speranza.aioe.org...

> You are insignificant. Read the fucking subject line. Better yet, just
> leave.

The subject line is "Boost". That doesn't resemble a question as far as I
can tell. I know you referred to the "f!cking subject line" but I have no
idea what that is.

Did you read the article http://www.catb.org/~esr/faqs/smart-questions.html
suggested by Victor?

Clearly not because you still found it necessary to swear and make nasty
comments.

Are you really still expecting help???

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llS...@gmail.com
[Replace the "SixFour" with numbers to email me]

[Juha Nieminen]

Nick Baumbach <ni...@iwqoc.org> wrote:
> I mean, it has to make things easier, but it does not looks like, since it
> takes hours to compile.

It does not make things easier because it takes hours to compile?

What kind of sense does that even make?

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Drew Lawson]

In article <ck3jd9hvrjo7eio0i...@4ax.com>

Robert Wessel <robert...@yahoo.com> writes:

>And just what part (or all) of Boost is going to require hours of
>compilation time?

My previous job made use of Boost, and had a script to build it
all. Using that script, it did take hours of elapsed time to build.
Comments from others show that the script probably wasn't using the
best options.

Anyway, it was no particular problem. We just told new people (or
people with new machines) to start it before leaving for the day.


(FWIW, I think the OP is yet another usenet performance artist.)

--
|Drew Lawson | Of all the things I've lost |
| | I miss my mind the most |

[Scott Lurndal]

Many larger systems are available. Not too many years ago, I was running
-j384 compiles regularly on a 192-core shared memory system.

[Herman Viracocha]

Drew Lawson wrote:

> Anyway, it was no particular problem. We just told new people (or
> people with new machines) to start it before leaving for the day.
>
>
> (FWIW, I think the OP is yet another usenet performance artist.)

You agree with him that it takes hours then still call him "performance
artist".

What sort of performance artist are you?

[Herman Viracocha]

Juha Nieminen wrote:

> Nick Baumbach <ni...@iwqoc.org> wrote:
>> I mean, it has to make things easier, but it does not looks like, since
>> it takes hours to compile.
>
> It does not make things easier because it takes hours to compile?

No? Definitely is not easier. Are you sure you clearly understand "hours
to compile"?

[Robert Wessel]

On Mon, 20 Jan 2014 15:26:52 GMT, sc...@slp53.sl.home (Scott Lurndal)
wrote:

Although arraigning to build over a cluster would almost certainly be
far cheaper. OTOH, I've never looked at the internals of the Boost
build system, so I have no idea how hard it would be to get it to do
that.

[Robert Wessel]

Interesting just how similar the NNTP headers for Nick Baumbach's and
Herman Viracocha's posts are...

[Robert Wessel]

"Arraigning" to compiler over a cluster? Is that anything like being
sentenced to hard labor? Spell checkers are fun... *sigh*

[J. Clarke]

In article <0fbDu.28641$YS5....@fx02.iad>, sc...@slp53.sl.home says...

People tend to assume that the consumer processors are the high end and
ignore the existence of the Xeon and Opteron lines. Using off-the-shelf
parts from Amazon you can build a 64-core machine with a terabyte of
RAM. Not _cheap_ but doable.

[Walter Profile]

J. Clarke wrote:

>> >Wow, -j 32 !! Say no more. Where did you find that 32 since at most I
>> >only can find 16, as 2 threads per core. Actually thread core, not
>> >real core. An i7 is still a 4 core, not sure how that threaded core is
>> >embedded into the hardware.
>> >
>> >Please elaborate
>>
>> Many larger systems are available. Not too many years ago, I was
>> running -j384 compiles regularly on a 192-core shared memory system.
>
> People tend to assume that the consumer processors are the high end and
> ignore the existence of the Xeon and Opteron lines. Using off-the-shelf
> parts from Amazon you can build a 64-core machine with a terabyte of
> RAM.
> Not _cheap_ but doable.

What off-the-shelf from Amazon are you talking about. Are you sure what
distributed shared memory is all about?

You seemingly agree in something that is stupid. The most on usenet are
using what is outhere available. Thus for now a 4 core / 8 threads are is
th best buy.

Moreover, if the code is not properly granulated for shared memory
distribution systems, that -j384 makes no sense.

[Drew Lawson]

In article <lbjg4b$nsh$2...@speranza.aioe.org>

Having trouble reading?

I agree that it is possible (though apparently not necessary) for
Boost to take hours to build.

His repeated "you are noise and do not answer the question" song
and dance is, IMO, a lame act.

--
Drew Lawson | "But the senator, while insisting he was not
| intoxicated, could not explain his nudity."

[Bob Hammerman]

Drew Lawson wrote:

> I agree that it is possible (though apparently not necessary) for Boost
> to take hours to build.
>
> His repeated "you are noise and do not answer the question" song and
> dance is, IMO, a lame act.

Rather you agree but not know what you agree in. Total confusion.

[Bob Hammerman]

Not to forget that "cluster" has nothing to do with multicore and shared
memory

[Bob Hammerman]

What has this to do with the subject to discuss? You seems confused.

[Scott Lurndal]

The aforementioned 192-core shared ccNUMA memory system (1TB DRAM) was selling
for about USD100,000 in 2009. About the same as a simliarly sized cluster
(16 nodes).

The followon system, which was in design, had 1024 xeon cores instead
of 192 opteron cores; but the economy stepped in and aborted that plan.

[Scott Lurndal]

Walter Profile <wp...@fj3dee.org> writes:
>J. Clarke wrote:
>
>>> >Wow, -j 32 !! Say no more. Where did you find that 32 since at most I
>>> >only can find 16, as 2 threads per core. Actually thread core, not
>>> >real core. An i7 is still a 4 core, not sure how that threaded core is
>>> >embedded into the hardware.
>>> >
>>> >Please elaborate
>>>
>>> Many larger systems are available. Not too many years ago, I was
>>> running -j384 compiles regularly on a 192-core shared memory system.
>>
>> People tend to assume that the consumer processors are the high end and
>> ignore the existence of the Xeon and Opteron lines. Using off-the-shelf
>> parts from Amazon you can build a 64-core machine with a terabyte of
>> RAM.
>> Not _cheap_ but doable.
>
>What off-the-shelf from Amazon are you talking about. Are you sure what
>distributed shared memory is all about?

An eight-socket high-end xeon system can provide 64-cores and 1TB DRAM.

The motherboards, processors and memory can be purchased from Newegg,
Amazon and other on-line vendors.

>
>You seemingly agree in something that is stupid. The most on usenet are
>using what is outhere available. Thus for now a 4 core / 8 threads are is
>th best buy.

What does 'usenet' have to do with the availability of very large systems?

On what basis do you claim knowledge of "what most on usenet are using"?

>
>Moreover, if the code is not properly granulated for shared memory
>distribution systems, that -j384 makes no sense.

If you have one source file, then yes, the obvious is obvious. If you
have thousands of source files, well, then.... Try building oracle11i, or
glibc, or linux, or a custom hypervisor instead of hello world sometime.

scott

[Scott Lurndal]

dr...@furrfu.invalid (Drew Lawson) writes:
>In article <lbjg4b$nsh$2...@speranza.aioe.org>
> Herman Viracocha <he...@idioqm.org> writes:
>>Drew Lawson wrote:
>>
>>> Anyway, it was no particular problem. We just told new people (or
>>> people with new machines) to start it before leaving for the day.
>>>
>>>
>>> (FWIW, I think the OP is yet another usenet performance artist.)
>>
>>You agree with him that it takes hours then still call him "performance
>>artist".
>>
>>What sort of performance artist are you?
>
>Having trouble reading?

I think you missed the double entendre.

scott

[Jorgen Grahn]

Part of the point being: it's sometimes optimal to use more make
processes than the number of CPUs. (A coworker pointed that out to me
15 years ago or so.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Bob Hammerman]

Scott Lurndal wrote:

>>Moreover, if the code is not properly granulated for shared memory
>>distribution systems, that -j384 makes no sense.
>
> If you have one source file, then yes, the obvious is obvious. If you
> have thousands of source files, well, then.... Try building oracle11i,
> or glibc, or linux, or a custom hypervisor instead of hello world
> sometime.

Not sure at all, remember, shared memory, if the threads or processes are
interrelated, threads are, then they will wait in whatever queue for ready
data.

Back to the point. Are you implying that Boost is good only for high-ends
since it compiles faster. I don't need a 192 core for coding in C/C++.

It looks like no one knows why Boost would be good to anything.

[Victor Bazarov]

It's "good to" Usenet trolling, as your example clearly shows. ;-)

V
--
I do not respond to top-posted replies, please don't ask

[Bob Hammerman]

Scott Lurndal wrote:

>>Moreover, if the code is not properly granulated for shared memory
>>distribution systems, that -j384 makes no sense.
>
> If you have one source file, then yes, the obvious is obvious. If you
> have thousands of source files, well, then.... Try building oracle11i,
> or glibc, or linux, or a custom hypervisor instead of hello world
> sometime.

I did compiled linux kernel years ago all the time. It took merely a 10 min
on a i386 and similar.

[Ian Collins]

That's right. With adequate RAM, 2x the physical cores is about right
for C++ on most x86/64 processors.

--
Ian Collins

[J. Clarke]

In article <lbjk1b$49l$1...@speranza.aioe.org>, wp...@fj3dee.org says...

>
> J. Clarke wrote:
>
> >> >Wow, -j 32 !! Say no more. Where did you find that 32 since at most I
> >> >only can find 16, as 2 threads per core. Actually thread core, not
> >> >real core. An i7 is still a 4 core, not sure how that threaded core is
> >> >embedded into the hardware.
> >> >
> >> >Please elaborate
> >>
> >> Many larger systems are available. Not too many years ago, I was
> >> running -j384 compiles regularly on a 192-core shared memory system.
> >
> > People tend to assume that the consumer processors are the high end and
> > ignore the existence of the Xeon and Opteron lines. Using off-the-shelf
> > parts from Amazon you can build a 64-core machine with a terabyte of
> > RAM.
> > Not _cheap_ but doable.
>
> What off-the-shelf from Amazon are you talking about. Are you sure what
> distributed shared memory is all about?

Supermicro H8QG7 board, four AMD6274 processors, maxing out the RAM you
have to go outside of Amazon to get 32 sticks of Samsung M386B4G70BM0-
YK0. Power supply, case, etc I'll leave you to find on your own.

You're going to have about $50,000 sunk in the machine by the time it's
finished--like I said, it's not going to be cheap.

> You seemingly agree in something that is stupid. The most on usenet are
> using what is outhere available. Thus for now a 4 core / 8 threads are is
> th best buy.

It's only "stupid" to people who don't have a clue what hardware is
currently available or its limitations. If you can buy it off of Amazon
then it's "out here avaiable". That most of us can't afford it is a
separate issue.

> Moreover, if the code is not properly granulated for shared memory
> distribution systems, that -j384 makes no sense.

In that case any use of memory makes no sense because all multicore
processors use shared memory, whether the cores are on a single chip or
spread across four or more.

You seem to be stuck in the 32-bit era when addressing anything beyond 4
GB meant using smoke and mirrors. While NUMA is a worthwhile
performance booster in some cases, it is certainly not _necessary_ in
order to to gain improved compilation times vs using smaller amounts of
RAM.

[J. Clarke]

In article <lbjmnr$bi9$1...@speranza.aioe.org>, bob...@djea.org says...

If compilation time was a showstopper then Linux would not be good for
anything but "high ends"--it can take days to build, as anybody who has
set up a gentoo system knows.

What it's good for is avoiding reinventing the wheel. If you have a
tested library already available that provides the function that you
need with acceptable performance, why rewrite it?

[Bob Hammerman]

J. Clarke wrote:

> You seem to be stuck in the 32-bit era when addressing anything beyond 4
> GB meant using smoke and mirrors. While NUMA is a worthwhile
> performance booster in some cases, it is certainly not _necessary_ in
> order to to gain improved compilation times vs using smaller amounts of
> RAM.

Is about code granulation able to make use of the multicores. You looks
like an idiot not knowing his ass what he is talking about.

Then "out there" means you go out down town and buy something like that,
not crap on Amazon and such. I bet I did run code on super computers at a
time you were not even born.

Please leave this thread, you do not contribute in any way.

[Bob Hammerman]

J. Clarke wrote:

> What it's good for is avoiding reinventing the wheel. If you have a
> tested library already available that provides the function that you
> need with acceptable performance, why rewrite it?

I don't know, but going through reverse engineering other peoples craps is
more time demanding than going through own crap. Don't you know it, where
have you been?

You seems to be a new beginner in computing, having a big mouth.

[J. Clarke]

In article <lbk1c9$8sl$1...@speranza.aioe.org>, bob...@djea.org says...

>
> J. Clarke wrote:
>
> > You seem to be stuck in the 32-bit era when addressing anything beyond 4
> > GB meant using smoke and mirrors. While NUMA is a worthwhile
> > performance booster in some cases, it is certainly not _necessary_ in
> > order to to gain improved compilation times vs using smaller amounts of
> > RAM.
>
> Is about code granulation able to make use of the multicores.

If you would actually write sentences that contained subjects and verbs
you might actually learn how to communicate with others. You may be
trying to communicate something meaningful here but you have failed to
do so.

> You looks
> like an idiot not knowing his ass what he is talking about.

I will be plonking you after I finish commenting on your puerile post.

> Then "out there" means you go out down town and buy something like that,
> not crap on Amazon and such. I bet I did run code on super computers at a
> time you were not even born.

I see. So if it's not in stock in some "down town" store it does not
exist?

As for your "betting you did run code on super computers at time when I
was not even born", since one cannnot now and has never been able to "go
out down town and buy" a supercomputer, by your logic they are not "out
there" and thus you by your own logic could not possibly have used one.

> Please leave this thread, you do not contribute in any way.

<plonk>

[J. Clarke]

In article <lbk1ld$8sl$2...@speranza.aioe.org>, bob...@djea.org says...

>
> J. Clarke wrote:
>
> > What it's good for is avoiding reinventing the wheel. If you have a
> > tested library already available that provides the function that you
> > need with acceptable performance, why rewrite it?
>
> I don't know, but going through reverse engineering other peoples craps is
> more time demanding than going through own crap. Don't you know it, where
> have you been?

Why would you want to reverse engineer a stock library? Are you trying
to pirate it or something?

> You seems to be a new beginner in computing, having a big mouth.

Yep, <plonk> was the right decision.

[Juha Nieminen]

I'm sure that something like g++ takes quite a long time to compile.
However, that doesn't make it less useful.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Öö Tiib]

On Monday, 20 January 2014 23:37:32 UTC+2, J. Clarke wrote:

>
> In article <lbk1c9$8sl$1...@speranza.aioe.org>, bob...@djea.org says...

No. Such person does not exist so he can say nothing. So far it is just

Random Male Name <random letters@random letters.org>

See examples like Herman Viracocha, Bob Hammermann or Nick Baumbach.

> <plonk>

Good luck filling your killfile with random troll-generated names and addresses
and announcing it every time.

[Martijn Lievaart]

On Mon, 20 Jan 2014 20:41:17 +0000, Bob Hammerman wrote:

> J. Clarke wrote:
>
>> What it's good for is avoiding reinventing the wheel. If you have a
>> tested library already available that provides the function that you
>> need with acceptable performance, why rewrite it?
>
> I don't know, but going through reverse engineering other peoples craps
> is more time demanding than going through own crap. Don't you know it,
> where have you been?

Having just debugged a professional well respected open source library, I
can say:

- It's crap
- Debugging it took 1 day, writing this functionality would probably have
taken months, if not a year.

So your statement is not true.

M4

[Robert Wessel]

On Mon, 20 Jan 2014 17:08:48 GMT, sc...@slp53.sl.home (Scott Lurndal)

Although a cluster of smaller machines with the same number of cores
would almost certatinly have been a fair bit cheaper. Assuming we're
talking something like PCs where the prices of the low end systems are
substantially less per-MIPS than the big SMPs.

Still, there's no reason not use use all 192 cores for a build if you
have enough RAM and I/O, assuming you have the box already. But if
your application is big builds, a cluster is almost certainly going to
be considerably cheaper since (big) builds are mostly EP.

[Oscar Chesnutt]

J. Clarke wrote:

>> Please leave this thread, you do not contribute in any way.
>
> <plonk>

Indeed, this supposedly means that you gonna use a computer program
helping you not to read. Otherwise you just keep reading. You must be
terribly clever, like your friends.

We never got the answer to the Boost concern. Do I have to be stupid to
use that?

[Daniel]

On Friday, January 24, 2014 12:01:15 PM UTC-5, Oscar Chesnutt wrote:
>
> We never got the answer to the Boost concern. Do I have to be
> stupid to use that?

Not at all. Even if you are not stupid, you can still use it.
Hope that helps.

Daniel

[Jorgen Grahn]

Are you insulting people, nym-shifting and whatnot, and /still/ expect
people to discuss Boost with you? Seriously?

[Oscar Chesnutt]

Jorgen Grahn wrote:

>> We never got the answer to the Boost concern. Do I have to be stupid to
>> use that?
>
> Are you insulting people, nym-shifting and whatnot, and /still/ expect
> people to discuss Boost with you? Seriously?

What nym-shifting and what insulting, are you serious??

From what I read in this thread you and your likes are insulting by not
relating to the issues, calling people "trolls", "nym-shifters" and so on.

Plonk also is just another insult, otherwise if applied literary would
imply feeding a computer program or algorithm with a file, helping the
owner NOT TO READ in and usenet forum.

Are you going to debate semantics or talk about the issue indicated by the
subject line.

You and your "friends" are violating the unwritten rules of usenet. Take
care.

[Jorgen Grahn]

On Sat, 2014-01-25, Oscar Chesnutt wrote:
> Jorgen Grahn wrote:
>
>>> We never got the answer to the Boost concern. Do I have to be stupid to
>>> use that?
>>
>> Are you insulting people, nym-shifting and whatnot, and /still/ expect
>> people to discuss Boost with you? Seriously?
>
> What nym-shifting and what insulting, are you serious??

As far as I can tell, you are posting in this thread as (at least)
Nick Baumbach
Walter Profile
Bob Hammerman
Oscar Chesnutt
That's the definition of nym-shifting, ok?

If you stop doing that, I'm prepared to discuss Boost[1] -- it
doesn't have diplomatic immunity or anything, and we're allowed to
criticize or defend it.

/Jorgen

[1] Except I personally don't have any real experience,
so I can only comment on the barriers to adopting it --
like trying to read up on some library and giving up
when I don't understand anything after 20 minutes.

[J. Clarke]

In article <slrnle77a3.8...@frailea.sa.invalid>,
grahn...@snipabacken.se says...

And that's its real failing--like much else computer related the
documentation sucks bigtime.

[woodb...@gmail.com]

On Saturday, January 25, 2014 8:46:15 AM UTC-6, J. Clarke wrote:
> In article <slrnle77a3.8...@frailea.sa.invalid>,
>
> grahn...@snipabacken.se says...
> >
>

> > [1] Except I personally don't have any real experience,
> > so I can only comment on the barriers to adopting it --
> > like trying to read up on some library and giving up
> > when I don't understand anything after 20 minutes.
>
> And that's its real failing--like much else computer related the
> documentation sucks bigtime.

I could use some help with my documentation...
If you have some specific ideas on how to improve my
documentation please let me know. (And yes, the software
does support some of Boost.)

Brian
Ebenezer Enterprises -
“Ask and it will be given to you; seek and you will find;
knock and the door will be opened to you.' Matthew 7:7
http://webEbenezer.net

[Jorgen Grahn]

On Sat, 2014-01-25, J. Clarke wrote:
> In article <slrnle77a3.8...@frailea.sa.invalid>,
> grahn...@snipabacken.se says...

>> [1] Except I personally don't have any real experience,
>> so I can only comment on the barriers to adopting it --
>> like trying to read up on some library and giving up
>> when I don't understand anything after 20 minutes.
>
> And that's its real failing--like much else computer related the
> documentation sucks bigtime.

I don't believe that's true for the programming APIs I use.
- Sections 2, 3 and 7 of the Linux man pages (C, POSIX and Linux-
specific functions) are really well-written.
- for the "original" STL implementation, SGI's "Standard Template
Library Programmer's Guide" is excellent.

It seems to me the way [many] Boost libraries fail to document
themselves is that the actual /work/ the library does is hard to
explain. It's not primarily about writing skills.

/Jorgen

[Öö Tiib]

Then it may help if you try to be more specific what you mean.
See: http://www.boost.org/doc/libs/1_55_0/libs/libraries.htm
What percentage of listed libraries is so difficult to understand
like you describe? Can't be most of those. I also see that there
are things with rare specific usage or things that are obsolete
thanks to C++11. Rest of libraries still seem useful.

[Onoto Winnemucca]

Jorgen Grahn wrote:

> On Sat, 2014-01-25, Oscar Chesnutt wrote:
>> Jorgen Grahn wrote:
>>
>>>> We never got the answer to the Boost concern. Do I have to be stupid
>>>> to use that?
>>>
>>> Are you insulting people, nym-shifting and whatnot, and /still/ expect
>>> people to discuss Boost with you? Seriously?
>>
>> What nym-shifting and what insulting, are you serious??
>
> As far as I can tell, you are posting in this thread as (at least)
> Nick Baumbach Walter Profile Bob Hammerman Oscar Chesnutt
> That's the definition of nym-shifting, ok?
>
> If you stop doing that, I'm prepared to discuss Boost[1] -- it doesn't
> have diplomatic immunity or anything, and we're allowed to criticize or
> defend it.

Hi Jorgen

I only can see that those posters are using a public usenet access posting
server. Are you sure you can read headers or just enjoy making a smart ass
of yourself.

You must be a big magician otherwise, with remote-viewing capabilities and
so on. Am I those people too?

In any case, you disrupt the flow of this interesting discussion by
calling others names, trolls etc. I suggest you leave in silence.

Admittedly you are incapable in programming, much less to tell anything
about Boost. Just leave, yesterday.

[J. Clarke]

In article <b2ec515d-5e77-45a6...@googlegroups.com>,
oot...@hot.ee says...

I don't know what I was looking at earlier (or maybe it's just that I'm
well-rested at the moment) but what you linked is much improved over
whatever documentation I saw previously.

[Qu0ll]

"Onoto Winnemucca" wrote in message news:lc11vm$fmp$1...@speranza.aioe.org...

> Am I those people too?

LOL. Rhetorical Question of the Year.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llS...@gmail.com
[Replace the "SixFour" with numbers to email me]

[Jorgen Grahn]

On Sat, 2014-01-25, Onoto Winnemucca wrote:
> Jorgen Grahn wrote:
>
>> On Sat, 2014-01-25, Oscar Chesnutt wrote:
>>> Jorgen Grahn wrote:
>>>
>>>>> We never got the answer to the Boost concern. Do I have to be stupid
>>>>> to use that?
>>>>
>>>> Are you insulting people, nym-shifting and whatnot, and /still/ expect
>>>> people to discuss Boost with you? Seriously?
>>>
>>> What nym-shifting and what insulting, are you serious??
>>
>> As far as I can tell, you are posting in this thread as (at least)
>> Nick Baumbach Walter Profile Bob Hammerman Oscar Chesnutt
>> That's the definition of nym-shifting, ok?

...

>
> Hi Jorgen
>
> I only can see that those posters are using a public usenet access posting
> server. Are you sure you can read headers or just enjoy making a smart ass
> of yourself.
>
> You must be a big magician otherwise, with remote-viewing capabilities and
> so on. Am I those people too?

Yes, as far as I can tell you are -- your style shines through.
Please stop doing this. You're not five years old; it's silly, and if
you think about it, it doesn't help you or anyone else.

/Jorgen

[Jorgen Grahn]

On Sat, 2014-01-25, 嘱 Tiib wrote:
> On Saturday, 25 January 2014 18:57:08 UTC+2, Jorgen Grahn wrote:

...

>> It seems to me the way [many] Boost libraries fail to document
>> themselves is that the actual /work/ the library does is hard to
>> explain. It's not primarily about writing skills.
>
> Then it may help if you try to be more specific what you mean.
> See: http://www.boost.org/doc/libs/1_55_0/libs/libraries.htm
> What percentage of listed libraries is so difficult to understand
> like you describe?

I can't give you a percentage, but I note that I have Bjarne
Stroustrup on my side. See his FAQ.

> Can't be most of those. I also see that there
> are things with rare specific usage or things that are obsolete
> thanks to C++11. Rest of libraries still seem useful.

Oh, I don't claim they aren't /useful/. They probably are -- but
there are so many complications to get past!

I used to feel the same way about the STL, fifteen years ago or so.
Iterators, the begin--end idiom ... that was stuff that I needed to
think about for some weeks or months before I "got" it and could use
it. The difference being that's stuff that's useful daily, in any
program. I'd prefer not to spend that kind of effort on every Boost
library which might or might not be useful to me.

Perhaps there should be "for dummies" Boost interfaces which are
simpler and cover what 99% of us need to do. Then if we max our those
interfaces we can turn to the "real" ones.

[Alf P. Steinbach]

* Onoto Winnemucca a.k.a. user.speranza.aioe.org:

>
> Am I those people too?

To the casual reader:

The above was posted in reply to Jorgen Grahn's reply to Oscar Chesnutt
a.k.a. user.speranza.aioe.org, and looking at the article references all
the way up to the start of the thread, every second article is by
user.speranza.aioe.org, posting under various fictitious names.

So, we're dealing with a childish troll.

May be relevant, or not:

<url: https://www.google.com/search?q=Michael+"Snit"+Glasser>


Cheers & hth.,

- Alf

[Onoto Winnemucca]

Another smart-ass wannabe. I am you too. I am your clone. I have your eyes.

Have you a reading disability, not seeing they are completely different
users, different user-agents and other things, posting through aioe.org
public server? There are millions of them.

More likely you are just stupid, or convincingly try to mimic one.

[Onoto Winnemucca]

Jorgen Grahn wrote:

>> You must be a big magician otherwise, with remote-viewing capabilities
>> and so on. Am I those people too?
>
> Yes, as far as I can tell you are -- your style shines through. Please
> stop doing this. You're not five years old; it's silly, and if you
> think about it, it doesn't help you or anyone else.

You looks like an idiot. I must be you too.

Sincerely, me.

[Onoto Winnemucca]

Jorgen Grahn wrote:

>> Then it may help if you try to be more specific what you mean. See:
>> http://www.boost.org/doc/libs/1_55_0/libs/libraries.htm What percentage
>> of listed libraries is so difficult to understand like you describe?
>
> I can't give you a percentage, but I note that I have Bjarne Stroustrup
> on my side. See his FAQ.

I am convinced then. Who else do you know, Bill Gates, Linus Torvalds?

[Öö Tiib]

On Sunday, 26 January 2014 02:21:00 UTC+2, Jorgen Grahn wrote:

> On Sat, 2014-01-25, Öö Tiib wrote:
>
> > Then it may help if you try to be more specific what you mean.
> > See: http://www.boost.org/doc/libs/1_55_0/libs/libraries.htm
> > What percentage of listed libraries is so difficult to understand
> > like you describe?
>
> I can't give you a percentage, but I note that I have Bjarne
> Stroustrup on my side. See his FAQ.

Stroustrup does say that some of it is too coupled and some of
it is too complex but it is bad idea to reinvent wheel if that is
already in boost (or in C++11).

> > Can't be most of those. I also see that there
> > are things with rare specific usage or things that are obsolete
> > thanks to C++11. Rest of libraries still seem useful.
>
> Oh, I don't claim they aren't /useful/. They probably are -- but
> there are so many complications to get past!

The complications arise from attempt to address boost as a whole.
It is *not* a whole. It is a lot of different purpose libraries. It is net
total 15 millions lines of code. So one approaching it *must* put on
heavy filters.

> I used to feel the same way about the STL, fifteen years ago or so.
> Iterators, the begin--end idiom ... that was stuff that I needed to
> think about for some weeks or months before I "got" it and could use
> it. The difference being that's stuff that's useful daily, in any
> program. I'd prefer not to spend that kind of effort on every Boost
> library which might or might not be useful to me.

Such major effort is likely overkill. Learn about a library in boost when
you need something like that. If it looks like overly complex then
look for alternatives.

> Perhaps there should be "for dummies" Boost interfaces which are
> simpler and cover what 99% of us need to do. Then if we max our those
> interfaces we can turn to the "real" ones.

When there is big amount of things from different authors for various
purposes then that can not be likely made uniform, simple and easy to
access for dummies.

[woodb...@gmail.com]

On Sunday, January 26, 2014 8:59:49 AM UTC-6, Öö Tiib wrote:
> On Sunday, 26 January 2014 02:21:00 UTC+2, Jorgen Grahn wrote:
> >
>
> > I can't give you a percentage, but I note that I have Bjarne
> > Stroustrup on my side. See his FAQ.
>
> Stroustrup does say that some of it is too coupled and some of
> it is too complex but it is bad idea to reinvent wheel if that is
> already in boost (or in C++11).

Hmm. There's also case where two approaches cover same
area, but they do so through different means. For
example, the serialization library in Boost uses C++
compiler based code generation and the C++ Middleware
Writer (CMW) is an external code generator.

If I took too literally your advice, I wouldn't have
developed CMW and imo C++ wouldn't have advantage over
other languages that CMW provides. CMW provides
automation of serialization like C# and Java, but
it goes beyond that in terms of being an on line
code generator.

>
> > > Can't be most of those. I also see that there
> > > are things with rare specific usage or things that are obsolete
> > > thanks to C++11. Rest of libraries still seem useful.
> >
>
> > Oh, I don't claim they aren't /useful/. They probably are -- but
> > there are so many complications to get past!
>
> The complications arise from attempt to address boost as a whole.
> It is *not* a whole. It is a lot of different purpose libraries. It is net
> total 15 millions lines of code. So one approaching it *must* put on
> heavy filters.

Yes.

>
> > I used to feel the same way about the STL, fifteen years ago or so.
> > Iterators, the begin--end idiom ... that was stuff that I needed to
> > think about for some weeks or months before I "got" it and could use
> > it. The difference being that's stuff that's useful daily, in any
> > program. I'd prefer not to spend that kind of effort on every Boost
> > library which might or might not be useful to me.
>
> Such major effort is likely overkill. Learn about a library in boost when
> you need something like that. If it looks like overly complex then
> look for alternatives.

I have spent some days getting acquainted with a Boost
library only to eventually find what I considered to
be a serious flaw. This can happen with any library
regardless of it being in Boost or not.

>
> > Perhaps there should be "for dummies" Boost interfaces which are
> > simpler and cover what 99% of us need to do. Then if we max our those
> > interfaces we can turn to the "real" ones.
>
> When there is big amount of things from different authors for various
> purposes then that can not be likely made uniform, simple and easy to
> access for dummies.

"A fool with a plan can outsmart a genius with no plan."
T. Boone Pickens

Some of Boost is genius with no plan... Frankenstein.


Brian
Ebenezer Enterprises - "Where there is no revelation,
people cast off restraint; but blessed is the one who
heeds wisdom's instruction." Proverbs 29:18

http://webEbenezer.net

[Öö Tiib]

On Sunday, 26 January 2014 17:57:02 UTC+2, woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 8:59:49 AM UTC-6, Öö Tiib wrote:
> > On Sunday, 26 January 2014 02:21:00 UTC+2, Jorgen Grahn wrote:
> > >
> > > I can't give you a percentage, but I note that I have Bjarne
> > > Stroustrup on my side. See his FAQ.
> >
> > Stroustrup does say that some of it is too coupled and some of
> > it is too complex but it is bad idea to reinvent wheel if that is
> > already in boost (or in C++11).
>
> Hmm. There's also case where two approaches cover same
> area, but they do so through different means.

Yes. We can always try to do same thing differently.
There's always some yet another way. However no one
has time to try all ways out.

> If I took too literally your advice, I wouldn't have
> developed CMW and imo C++ wouldn't have advantage over
> other languages that CMW provides. CMW provides
> automation of serialization like C# and Java, but
> it goes beyond that in terms of being an on line
> code generator.

Who knows? It may be that if you had taken my advice
literally then may be you would have developed some
other tool to some less or more full market that is less
or more outstanding from crowd. That we can never
tell.

About Java, C# or Python ... we often need to interoperate
with programs written in other languages indeed, but that
is not what your CMW helps with?

> I have spent some days getting acquainted with a Boost
> library only to eventually find what I considered to
> be a serious flaw. This can happen with any library
> regardless of it being in Boost or not.

More people look and try and use boost. So the defects
will be found and eventually repaired. That is one of the
strengths of boost.

[woodb...@gmail.com]

On Sunday, January 26, 2014 11:08:07 AM UTC-6, Öö Tiib wrote:
> On Sunday, 26 January 2014 17:57:02 UTC+2, woodb...@gmail.com wrote:
>
> > On Sunday, January 26, 2014 8:59:49 AM UTC-6, Öö Tiib wrote:
> >
>
> > Hmm. There's also case where two approaches cover same
> > area, but they do so through different means.
>
> Yes. We can always try to do same thing differently.
> There's always some yet another way. However no one
> has time to try all ways out.
>

"Unless the L-rd builds the house, they labor in
vain who build it. Unless the L-rd guards the city,
the watchman waketh but in vain.' Psalms 127:1

> > If I took too literally your advice, I wouldn't have
> > developed CMW and imo C++ wouldn't have advantage over
> > other languages that CMW provides. CMW provides
> > automation of serialization like C# and Java, but
> > it goes beyond that in terms of being an on line
> > code generator.
>
> Who knows? It may be that if you had taken my advice
> literally then may be you would have developed some
> other tool to some less or more full market that is less
> or more outstanding from crowd. That we can never
> tell.
>
> About Java, C# or Python ... we often need to interoperate
> with programs written in other languages indeed, but that
> is not what your CMW helps with?
>

Other serialization libraries are also focused on C++.
Corba takes language neutral approach. Is it thriving?
I tend to think it is stagnant and dying.

My approach is to focus first on C++. After dust
settles, I hope to provide support for one or two other
languages. C++ is most important language for services,
so good place to start.

> > I have spent some days getting acquainted with a Boost
> > library only to eventually find what I considered to
> > be a serious flaw. This can happen with any library
> > regardless of it being in Boost or not.
>
> More people look and try and use boost. So the defects
> will be found and eventually repaired. That is one of the
> strengths of boost.

Don't hold your breath if you have requests for some
libraries. The maintenance can be very thin.


Brian
Ebenezer Enterprises
http://webEbenezer.net

[woodb...@gmail.com]

On Sunday, January 26, 2014 11:51:49 AM UTC-6, woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 11:08:07 AM UTC-6, Öö Tiib wrote:
>
> > About Java, C# or Python ... we often need to interoperate
> > with programs written in other languages indeed, but that
> > is not what your CMW helps with?
>
>
> Other serialization libraries are also focused on C++.
> Corba takes language neutral approach. Is it thriving?
> I tend to think it is stagnant and dying.
>
> My approach is to focus first on C++. After dust
> settles, I hope to provide support for one or two other
> languages. C++ is most important language for services,
> so good place to start.
>

I looked into Java a number of years ago and found
it's requirement for a class to be in only one file
to be antithetical to code generation.

So I would guess the second language we'll support
will be either C# or Python.

[Öö Tiib]

On Sunday, 26 January 2014 19:51:49 UTC+2, woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 11:08:07 AM UTC-6, Öö Tiib wrote:
> > About Java, C# or Python ... we often need to interoperate
> > with programs written in other languages indeed, but that
> > is not what your CMW helps with?
>
> Other serialization libraries are also focused on C++.
> Corba takes language neutral approach. Is it thriving?
> I tend to think it is stagnant and dying.

If someone asks for C++ solution for serialization then he
gets lot of answers like protocol buffers, jsoncpp,
codesynthesis xsd, tinyxml, boost serialize, and so
on. Like you see all are capable to serialize into language
neutral formats. Other languages have same or
different tools for serialization since what matters is
the format.

> My approach is to focus first on C++. After dust
> settles, I hope to provide support for one or two other
> languages. C++ is most important language for services,
> so good place to start.

Lot of network services are not written in C++. I trust majority.

> > More people look and try and use boost. So the defects
> > will be found and eventually repaired. That is one of the
> > strengths of boost.
>
> Don't hold your breath if you have requests for some
> libraries. The maintenance can be very thin.

I speak of experience. Boost tends to have lower amount of
defects than other C++ libraries. If there is a defect then it is
usually fixed soon and also workaround is found. Anyway if
it looks too complex for me to fix it myself then I avoid it.

[woodb...@gmail.com]

On Sunday, January 26, 2014 1:00:37 PM UTC-6, Öö Tiib wrote:
> On Sunday, 26 January 2014 19:51:49 UTC+2, woodb...@gmail.com wrote:
>
> > Other serialization libraries are also focused on C++.
> > Corba takes language neutral approach. Is it thriving?
> > I tend to think it is stagnant and dying.
>
> If someone asks for C++ solution for serialization then he
> gets lot of answers like protocol buffers, jsoncpp,
> codesynthesis xsd, tinyxml, boost serialize, and so

The C++ Middleware Writer has support for serializing
some of Boost. G-d willing we'll add support for other
types in the future including more of Boost. It will
depend on the needs of users.

> on. Like you see all are capable to serialize into language
> neutral formats. Other languages have same or
> different tools for serialization since what matters is
> the format.
>

I'm talking about binary serialization here.

> > My approach is to focus first on C++. After dust
> > settles, I hope to provide support for one or two other
> > languages. C++ is most important language for services,
> > so good place to start.
>
> Lot of network services are not written in C++.
>

Do you disagree with my claim that C++ is most important
language for services?

>
> > Don't hold your breath if you have requests for some
> > libraries. The maintenance can be very thin.
>
> I speak of experience. Boost tends to have lower amount of
> defects than other C++ libraries. If there is a defect then it is
> usually fixed soon and also workaround is found.

Some of Boost is as you describe. Other parts don't
get much love.

[Ian Collins]

woodb...@gmail.com wrote:

> On Sunday, January 26, 2014 1:00:37 PM UTC-6, 嘱 Tiib wrote:
>
>>> My approach is to focus first on C++. After dust
>>> settles, I hope to provide support for one or two other
>>> languages. C++ is most important language for services,
>>> so good place to start.
>>
>> Lot of network services are not written in C++.
>>
>
> Do you disagree with my claim that C++ is most important
> language for services?

While C++ is an important language for services, it has to inter-operate
with servers and clients written in other languages. This is why most
serialisation formats in common use today (SOAP, XML-RPC, JSON) are
textual or binary extensions of them (BSON).

--
Ian Collins

[Öö Tiib]

On Sunday, 26 January 2014 23:27:36 UTC+2, woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 1:00:37 PM UTC-6, Öö Tiib wrote:
> > On Sunday, 26 January 2014 19:51:49 UTC+2, woodb...@gmail.com wrote:
> >
> > > Other serialization libraries are also focused on C++.
> > > Corba takes language neutral approach. Is it thriving?
> > > I tend to think it is stagnant and dying.
> >
> > If someone asks for C++ solution for serialization then he
> > gets lot of answers like protocol buffers, jsoncpp,
> > codesynthesis xsd, tinyxml, boost serialize, and so

> > on. Like you see all are capable to serialize into language
> > neutral formats. Other languages have same or
> > different tools for serialization since what matters is
> > the format.
>
> I'm talking about binary serialization here.

The binary formats are less used than text formats when traffic
is small enough. There are plenty of binary formats and most
have C++ or C serialization/deserialization available. Protocol
Buffers have language neutral binary format from above.

Boost Serialization binary format may have differences between
versions of library and it is C++ only. However it may be useful
for usage within single application.

> > > My approach is to focus first on C++. After dust
> > > settles, I hope to provide support for one or two other
> > > languages. C++ is most important language for services,
> > > so good place to start.
> >
> > Lot of network services are not written in C++.
> >
>
> Do you disagree with my claim that C++ is most important
> language for services?

No. Claiming what is more or less important programming language
misses the point about importance of formats. I was saying that
there are lot of services that are not written in C++. These are
important too and the programs need to interoperate so need to
use common format.

> > I speak of experience. Boost tends to have lower amount of
> > defects than other C++ libraries. If there is a defect then it is
> > usually fixed soon and also workaround is found.
>
> Some of Boost is as you describe. Other parts don't
> get much love.

Most of the libraries in Boost seem to be made with love.

[woodb...@gmail.com]

On Sunday, January 26, 2014 3:34:18 PM UTC-6, Ian Collins wrote:

> woodb...@gmail.com wrote:
> >
> > Do you disagree with my claim that C++ is most important
> > language for services?
>
> While C++ is an important language for services, it has to inter-operate
> with servers and clients written in other languages.

If you had said --

it sometimes has to inter-operate

I'd agree. I know of a few companies that write C++
programs that communicate with each other. That's
not exactly unheard of.

And as I said I'm open to working on adding support
for another language, but I don't think that language
will be Java. Python or C# is more likely.

> This is why most
> serialisation formats in common use today (SOAP, XML-RPC, JSON) are
> textual or binary extensions of them (BSON).
>

I think scientific apps and games often use binary serialization.

I believe the quality of my software is good and believe
that thinking about the software/service through another
project's eyes will help me to improve the software service.

[Ian Collins]

woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 3:34:18 PM UTC-6, Ian Collins wrote:
>> woodb...@gmail.com wrote:
>>>
>>> Do you disagree with my claim that C++ is most important
>>> language for services?
>>
>> While C++ is an important language for services, it has to inter-operate
>> with servers and clients written in other languages.
>
> If you had said --
>
> it sometimes has to inter-operate
>
> I'd agree. I know of a few companies that write C++
> programs that communicate with each other. That's
> not exactly unheard of.

Probably the most common type of "service" these days is the web
service. Web services almost exclusively use SOAP. If you are going to
write the back ends for web pages in C++, you will probably have to use
JSON to communicate with the client JavaScript.

> And as I said I'm open to working on adding support
> for another language, but I don't think that language
> will be Java. Python or C# is more likely.
>
>> This is why most
>> serialisation formats in common use today (SOAP, XML-RPC, JSON) are
>> textual or binary extensions of them (BSON).
>
> I think scientific apps and games often use binary serialization.
>
> I believe the quality of my software is good and believe
> that thinking about the software/service through another
> project's eyes will help me to improve the software service.

By using a proprietary binary format, you are restricting yourself to a
narrow range of applications. The easiest way to support other
languages is to use a well known on wire format.

--
Ian Collins

[woodb...@gmail.com]

On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:
> woodb...@gmail.com wrote:
>
>
> Probably the most common type of "service" these days is the web
> service. Web services almost exclusively use SOAP. If you are going to
> write the back ends for web pages in C++, you will probably have to use
> JSON to communicate with the client JavaScript.
>

>
> >

> By using a proprietary binary format, you are restricting yourself to a
> narrow range of applications. The easiest way to support other
> languages is to use a well known on wire format.
>

Maybe. Currently I'm doing byte-level marshalling, but am
thinking about switching to bit-level marshalling. In that
case a boolean would be marshalled as one bit rather than
taking a whole byte.

I'm aware of HDF, netCDF and ASN 1. Do any of them
support bit-level marshalling? Do any of the standards
have support for polymorphism?

I marshall string lengths as variable length integers. Do
any of the standards require fixed length integers for string
lengths? I don't think I want that so am asking to find out
what standards to avoid.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Ian Collins]

woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:
>> woodb...@gmail.com wrote:
>>
>>
>> Probably the most common type of "service" these days is the web
>> service. Web services almost exclusively use SOAP. If you are going to
>> write the back ends for web pages in C++, you will probably have to use
>> JSON to communicate with the client JavaScript.
>>
>> By using a proprietary binary format, you are restricting yourself to a
>> narrow range of applications. The easiest way to support other
>> languages is to use a well known on wire format.
>>
>
> Maybe. Currently I'm doing byte-level marshalling, but am
> thinking about switching to bit-level marshalling. In that
> case a boolean would be marshalled as one bit rather than
> taking a whole byte.

Um, why? Surely the extra overhead would outweigh transmission time
savings?

> I'm aware of HDF, netCDF and ASN 1. Do any of them
> support bit-level marshalling? Do any of the standards
> have support for polymorphism?

ASN.1 is awfully complex and out of favour these says. I'm not familiar
with the others.

It looks like you set out to serialise the object model rather than
simply serialising data. Isn't that tying things too tightly to C++?

> I marshall string lengths as variable length integers. Do
> any of the standards require fixed length integers for string
> lengths? I don't think I want that so am asking to find out
> what standards to avoid.

Most interchange standards currently in vogue value simplicity over
minimising the payload size.

--
Ian Collins

[Jorgen Grahn]

On Mon, 2014-01-27, woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:

...

>> By using a proprietary binary format, you are restricting yourself to a
>> narrow range of applications. The easiest way to support other
>> languages is to use a well known on wire format.
>>
>
> Maybe. Currently I'm doing byte-level marshalling, but am
> thinking about switching to bit-level marshalling. In that
> case a boolean would be marshalled as one bit rather than
> taking a whole byte.
>
> I'm aware of HDF, netCDF and ASN 1. Do any of them
> support bit-level marshalling?

ASN.1 with the PER (packed encoding rules) does. But PER is also the
one you need expert help to generate a parser for ... I used it
2000--2001 with some telecom protocol (RANAP?) and it wasn't much fun
...

Personally I suspect a (possibly gzipped) text stream is good enough
almost all the time.

[woodb...@gmail.com]

On Monday, January 27, 2014 5:55:11 AM UTC-6, Jorgen Grahn wrote:
> On Mon, 2014-01-27, woodb...@gmail.com wrote:
>
> > I'm aware of HDF, netCDF and ASN 1. Do any of them
> > support bit-level marshalling?
>
> ASN.1 with the PER (packed encoding rules) does. But PER is also the
> one you need expert help to generate a parser for ... I used it
> 2000--2001 with some telecom protocol (RANAP?) and it wasn't much fu

> ...

Thanks and thanks to Ian for his comment on ASN.1. I think I'll
steer clear of that.

>
> Personally I suspect a (possibly gzipped) text stream is good enough
> almost all the time.
>

I think those working on scientific apps would disagree.
The serialization of their data is faster with binary and
there's probably no need for an additional compression step.

[Jorgen Grahn]

On Tue, 2014-01-28, woodb...@gmail.com wrote:
...

>> Personally I suspect a (possibly gzipped) text stream is good enough
>> almost all the time.
>>
>
> I think those working on scientific apps would disagree.
> The serialization of their data is faster with binary and
> there's probably no need for an additional compression step.

Quite possible for some kinds of scientific apps -- I think my "almost
all the time" gets me off that particular hook!

[woodb...@gmail.com]

On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:
> woodb...@gmail.com wrote:
>
> > If you had said --
> >
> > it sometimes has to inter-operate
> >
>
> > I'd agree. I know of a few companies that write C++
> > programs that communicate with each other. That's
> > not exactly unheard of.
>
> Probably the most common type of "service" these days is the web
> service. Web services almost exclusively use SOAP. If you are going to
> write the back ends for web pages in C++, you will probably have to use
> JSON to communicate with the client JavaScript.

I've been reading about JSON some. The following is
maybe due to some misunderstanding, but it seems
JSON can only deal with user defined objects.

I have a message template (not a C++ template) that
looks like this:

@out (::cmw::marshalling_integer, const char*)

(A function is generated based on that.)

IIuc, with JSON, I'd have to create a class that has
those two types in it and then marshal an instance of
that type. I like not having to do that as there's
no need currently for such a class. Those two pieces
of data are from the command line and I just forward
them to the marshalling function without having to
create an object that's only use would be marshalling
it's data members. I will admit it wouldn't take long
to construct such an object, but there's a wrinkle.
If the class were:

class front_tier_type
{
cmw::marshalling_integer account_number;
char* path;
};

That class won't work for me in my middle tier where
it doesn't hurt to store the data from the path variable
in a std::string. I have to store it somewhere in the
middle tier so I choose to put it in a std::string.

Constructing a front_tier_type would be fast, but if
I changed it to have a std:string instead of a char*
it gets more expensive. I don't want to have to pay
for that in the front tier. So iiuc, JSON based
approach would have one class on sending side and
another on the receiving side. The other approach I
described is also different on the sending and receiving
ends, but is more efficient.

If there were more than two pieces of data, constructing
an object becomes more of a waste.

The C++ route seems to offer more flexibility than
the JSON approach.

>
>
> > And as I said I'm open to working on adding support
> > for another language, but I don't think that language
> > will be Java. Python or C# is more likely.
> >
>

> > I think scientific apps and games often use binary serialization.
> >

> By using a proprietary binary format,

The format isn't a secret.

> you are restricting yourself to a
> narrow range of applications. The easiest way to support other
> languages is to use a well known on wire format.

I may go back to this angle.

[Ian Collins]

woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:
>> woodb...@gmail.com wrote:
>>
>>> If you had said --
>>>
>>> it sometimes has to inter-operate
>>>
>>> I'd agree. I know of a few companies that write C++
>>> programs that communicate with each other. That's
>>> not exactly unheard of.
>>
>> Probably the most common type of "service" these days is the web
>> service. Web services almost exclusively use SOAP. If you are going to
>> write the back ends for web pages in C++, you will probably have to use
>> JSON to communicate with the client JavaScript.
>
> I've been reading about JSON some. The following is
> maybe due to some misunderstanding, but it seems
> JSON can only deal with user defined objects.

It depends on how you use JSON and your chosen library. I would write
something like:

json::Object blob;
blob["number"] = accountNumber;
blob["name"] = accountName;

std::cout << blob;

<snip>

> Constructing a front_tier_type would be fast, but if
> I changed it to have a std:string instead of a char*
> it gets more expensive. I don't want to have to pay
> for that in the front tier. So iiuc, JSON based
> approach would have one class on sending side and
> another on the receiving side. The other approach I
> described is also different on the sending and receiving
> ends, but is more efficient.
>
> If there were more than two pieces of data, constructing
> an object becomes more of a waste.
>
> The C++ route seems to offer more flexibility than
> the JSON approach.

In cases where speed of serialisation isn't critical (most cases I'd
suggest), the flexibility and interoperability of text on the wire wins out.

I often use all or part of the received JSON object directly in the
sever code, so it never gets converted to something else. I guess this
habit comes form having written a lot of JavaScript.

>>> And as I said I'm open to working on adding support
>>> for another language, but I don't think that language
>>> will be Java. Python or C# is more likely.
>>>
>>
>>> I think scientific apps and games often use binary serialization.
>
>> By using a proprietary binary format,
>
> The format isn't a secret.

But you's have to convince others to adopt it.

--
Ian Collins

[woodb...@gmail.com]

On Wednesday, January 29, 2014 6:32:30 PM UTC-6, Ian Collins wrote:
> woodb...@gmail.com wrote:
>
> > On Sunday, January 26, 2014 4:56:28 PM UTC-6, Ian Collins wrote:
>
> >> Probably the most common type of "service" these days is the web
>
> >> service. Web services almost exclusively use SOAP. If you are going to
>
> >> write the back ends for web pages in C++, you will probably have to use
>
> >> JSON to communicate with the client JavaScript.
>
> >
>
> > I've been reading about JSON some. The following is
> > maybe due to some misunderstanding, but it seems
> > JSON can only deal with user defined objects.
>
> It depends on how you use JSON and your chosen library. I would write
> something like:
>
> json::Object blob;
> blob["number"] = accountNumber;
> blob["name"] = accountName;
>
> std::cout << blob;
>

That kind of helps, but the indices ("number" and "name")
are a problem. I don't have a means of getting that
information from a user like I do if they provide a header
file with data member names.

Let me change the messsage template a little

@out (int, const char*)

The generated function for that will have a1 and a2
for the names of the arguments. So

json::Object blob;
blob["a1"] = a1;
blob["a2"] = a2;

That doesn't work for me on the receiving side where
I have a user defined type.

>
>
> > The C++ route seems to offer more flexibility than
> > the JSON approach.
>
> In cases where speed of serialisation isn't critical (most cases I'd
> suggest), the flexibility and interoperability of text on the wire wins out.
>

Well where speed is critical, there's a good chance they'll
be using C++ so that much is promising from my perspective.

> I often use all or part of the received JSON object directly in the
> sever code, so it never gets converted to something else. I guess this
> habit comes form having written a lot of JavaScript.
>

I recall your saying something like that previously. I'd like
to know how accessing a JSON object compares to accessing a C++
object. Is it a lot slower? I recall Juha talking about
something that may have been similar with Objective C.

[Ian Collins]

Given a JSON object is a C++ object, the access will depend on the
complexity of the object. My library is designed for programmer
convenience first, efficiency a close second. I wanted to support
arbitrary nesting, such as

json::Object blob;

blob["one"]["two"]["three"]["four"] << 1 << 2 << "hello";

which creates this object:

{"one":{"two":{"three":{"four":[1,2,"hello"]}}}}

This requires a degree of indirection than a more basic implementation
would.

If I want to use an internal C++ object, I code generate (usually from
an Open Office document) to/from JSON methods for the object's data.

--
Ian Collins

[woodb...@gmail.com]

On Monday, January 27, 2014 5:55:11 AM UTC-6, Jorgen Grahn wrote:
>

> Personally I suspect a (possibly gzipped) text stream is good enough
> almost all the time.
>

What about streaming video?

[Dombo]

Op 26-Jan-14 23:46, woodb...@gmail.com schreef:

> On Sunday, January 26, 2014 3:34:18 PM UTC-6, Ian Collins wrote:
>> woodb...@gmail.com wrote:
>>>
>>> Do you disagree with my claim that C++ is most important
>>> language for services?
>>
>> While C++ is an important language for services, it has to inter-operate
>> with servers and clients written in other languages.
>
> If you had said --
>
> it sometimes has to inter-operate
>
> I'd agree. I know of a few companies that write C++
> programs that communicate with each other. That's
> not exactly unheard of.
>
> And as I said I'm open to working on adding support
> for another language, but I don't think that language
> will be Java. Python or C# is more likely.

When communicating with a web server chances are it is written in Java.
Python has its own serialization facilities as does .NET, as does Java.
Focusing on one or a very few languages puts your solution at a
disadvantage compared to the more established alternatives. If you want
people to convince to use your solution over the well known, proven,
well supported and industry standard solutions (SOAP, JSON, BSON...etc),
you have to provide some compelling reason, i.e. a unique selling point,
which as of yet I haven't seen in spite of your frequent postings
promoting your library. I think you need to do a bit more market
research before investing in reinventing the wheel.

[woodb...@gmail.com]

I'm pioneering on line code generation. These people
http://springfuse.com

are also working on on line code generation, but
they use Java. Most of what they say in terms of
marketing their service is also true of the C++
Middleware Writer.

10 years ago there was some doubt about the
path, but I don't think there's any doubt today.
On line code generation is here to stay.

Brian
Ebenezer Enterprises - "Imitation is the sincerest
form of flattery."
http://webEbenezer.net

[Dombo]

Op 01-Feb-14 17:16, woodb...@gmail.com schreef:

> On Saturday, February 1, 2014 8:02:27 AM UTC-6, Dombo wrote:
>> Op 26-Jan-14 23:46, woodb...@gmail.com schreef:
>>
>>> On Sunday, January 26, 2014 3:34:18 PM UTC-6, Ian Collins wrote:
>>
>>>> woodb...@gmail.com wrote:
>>
>>> And as I said I'm open to working on adding support
>>> for another language, but I don't think that language
>>> will be Java. Python or C# is more likely.
>>
>> When communicating with a web server chances are it is written in Java.
>> Python has its own serialization facilities as does .NET, as does Java.
>> Focusing on one or a very few languages puts your solution at a
>> disadvantage compared to the more established alternatives. If you want
>> people to convince to use your solution over the well known, proven,
>> well supported and industry standard solutions (SOAP, JSON, BSON...etc),
>> you have to provide some compelling reason, i.e. a unique selling point,
>> which as of yet I haven't seen in spite of your frequent postings
>> promoting your library. I think you need to do a bit more market
>> research before investing in reinventing the wheel.
>
> I'm pioneering on line code generation. These people
> http://springfuse.com are also working on on line code
> generation, but they use Java.

I'd hardly call that pioneering.

> Most of what they say in terms of
> marketing their service is also true of the C++
> Middleware Writer.

Springfuse makes rather generic claims, the kind of marketing speak one
expects for just about any software development tool. And above all it
still not answers the questions how your product differentiates itself
from competing, well established, solutions.

> 10 years ago there was some doubt about the
> path, but I don't think there's any doubt today.
> On line code generation is here to stay.

Ask yourself what is the benefit of online code generation for the
client. If it is the only option for code generation it would be a
considered to be a serious disadvantage by many because:
1. It undesirable to make your build process dependant on some external
service not under your own control;
2. But more importantly...what if the company that provides the online
service goes out of business or just decides to pull the plug?

[Jorgen Grahn]

No. But it seems to me that's a different problem compared to the
ones discussed so far.

[woodb...@gmail.com]

On Saturday, February 1, 2014 10:52:21 AM UTC-6, Dombo wrote:
> Op 01-Feb-14 17:16, woodb...@gmail.com schreef:
>
> > On Saturday, February 1, 2014 8:02:27 AM UTC-6, Dombo wrote:
>
> >>
> I'd hardly call that pioneering.
>
>
> > Most of what they say in terms of
> > marketing their service is also true of the C++
> > Middleware Writer.
>

> Springfuse makes rather generic claims, the kind of marketing speak one
> expects for just about any software development tool. And above all it
> still not answers the questions how your product differentiates itself
> from competing, well established, solutions.
>

There are more specifics here

http://webEbenezer.net/comparison.html

.


>
> > 10 years ago there was some doubt about the
> > path, but I don't think there's any doubt today.
> > On line code generation is here to stay.
>
>
> Ask yourself what is the benefit of online code generation for the
> client.

Longevity is an important factor. Users need
tools that will outlast their projects. Unlike
most of our competitors, we have a business model
that's based on on line code generation. "A fool

with a plan can outsmart a genius with no plan."
T. Boone Pickens

I get the feeling some are surprised by how a
small company like Ebenezer Enterprises is
able to outsmart bigger comptetitors.
Recall the story of David against Goliath.
David, using a new technology, took down
the more established Goliath. Is on line
code generation the new slingshot?

> If it is the only option for code generation it would be a
> considered to be a serious disadvantage by many because:
> 1. It undesirable to make your build process dependant on some external
> service not under your own control;
> 2. But more importantly...what if the company that provides the online
> service goes out of business or just decides to pull the plug?

Sorry if you don't like it, but this is the
way things are headed. Ebenezer Enterprises
is in better shape today than ever. This is
from our website:

I'm willing to donate 15 hours/week for six months
to a project that uses the C++ Middleware Writer.

Also I'll pay $500 and give a $1,000 investment in
Ebenezer Enterprises to someone who helps me find
someone interested in this. I'll pay the $500
after working for four months on the project.
Ebenezer Enteprises works to reward investments to
3 times their original amount. So the investment
would result in between $0 and $3,000, depending
on how things go for the company.

----------------------------------------------

We make that offer to help people overcome fears
they may have about working with a small company
to provide a service. We'll hold your hand and
help you build the software you want to build.