comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Boost - 16 messages, 7 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
* What is the disadvantage with C++ in Embedded systems? - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/d2c6dd66860beb15?hl=en
* goto label inside of if statement - 7 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
* Link object files from VC++ and GCC? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/d605f2ea0db15eb9?hl=en
* C++ is hard (Google game) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/dac6864900693dc7?hl=en
==============================================================================
TOPIC: Boost
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
== 1 of 16 ==
Date: Sat, Jan 25 2014 9:25 am
From: Öö Tiib
On Saturday, 25 January 2014 18:57:08 UTC+2, Jorgen Grahn wrote:
> On Sat, 2014-01-25, J. Clarke wrote:
> > In article <slrnle77a3.81f.grahn+nntp@frailea.sa.invalid>,
> > grahn+nntp@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.
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.
== 2 of 16 ==
Date: Sat, Jan 25 2014 11:06 am
From: 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.
== 3 of 16 ==
Date: Sat, Jan 25 2014 3:07 pm
From: "J. Clarke"
In article <b2ec515d-5e77-45a6-9f9a-73d59be8278e@googlegroups.com>,
ootiib@hot.ee says...
>
> On Saturday, 25 January 2014 18:57:08 UTC+2, Jorgen Grahn wrote:
> > On Sat, 2014-01-25, J. Clarke wrote:
> > > In article <slrnle77a3.81f.grahn+nntp@frailea.sa.invalid>,
> > > grahn+nntp@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.
>
> 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.
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.
== 4 of 16 ==
Date: Sat, Jan 25 2014 3:30 pm
From: "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)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me]
== 5 of 16 ==
Date: Sat, Jan 25 2014 3:58 pm
From: 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 <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 6 of 16 ==
Date: Sat, Jan 25 2014 4:21 pm
From: 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.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 7 of 16 ==
Date: Sun, Jan 26 2014 1:02 am
From: "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
== 8 of 16 ==
Date: Sun, Jan 26 2014 1:34 am
From: Onoto Winnemucca
Alf P. Steinbach wrote:
> * 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>
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.
== 9 of 16 ==
Date: Sun, Jan 26 2014 1:41 am
From: 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.
== 10 of 16 ==
Date: Sun, Jan 26 2014 1:47 am
From: 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?
== 11 of 16 ==
Date: Sun, Jan 26 2014 6:59 am
From: Öö 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.
== 12 of 16 ==
Date: Sun, Jan 26 2014 7:57 am
From: woodbrian77@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
== 13 of 16 ==
Date: Sun, Jan 26 2014 9:08 am
From: Öö 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.
== 14 of 16 ==
Date: Sun, Jan 26 2014 9:51 am
From: woodbrian77@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
== 15 of 16 ==
Date: Sun, Jan 26 2014 10:14 am
From: woodbrian77@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.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 16 of 16 ==
Date: Sun, Jan 26 2014 11:00 am
From: Öö 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.
==============================================================================
TOPIC: What is the disadvantage with C++ in Embedded systems?
http://groups.google.com/group/comp.lang.c++/t/d2c6dd66860beb15?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 25 2014 9:32 am
From: Öö Tiib
On Saturday, 25 January 2014 19:05:05 UTC+2, Jorgen Grahn wrote:
> On Sat, 2014-01-25, deepadivakaruni@gmail.com wrote:
> > And also the
> > many keywords are used to perform only one application.
>
> I don't understand that sentence.
Me neither.
> Also, to which posting are you
> responding? Is it some posting from the 1990s, resurrected by the
> broken Google interface?
deepadivakaruni is responding to 11 years old thread.
==============================================================================
TOPIC: goto label inside of if statement
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
==============================================================================
== 1 of 7 ==
Date: Sat, Jan 25 2014 11:17 am
From: Mr Flibble
On 25/01/2014 08:55, Stuart wrote:
> On 1/23/2014, W Karas wrote:
>>> What't the better alternative when you have to break out of an outer
>>> block, or a block that's not the body of a switch or loop?
>
> on 01/24/14, Victor Bazarov wrote:
>> Throw an exception.
>
> -1
>
> Using an exception for "normal" control flow is IMHO a bad design
> choice. My wife had to struggle with a real ugly piece of code for over
> two weeks where an exception was used to indicate that some algorithm
> had to be invoked with different parameters. Really yuk.
>
> I have to admit that using exceptions is tempting, but it makes the
> intended control flow harder to "read": If you see the code that throws
> the exception it is harder for you to figure out what will be the next
> statement because the exception might propagate through multiple levels
> on the stack. A plain old return-statement tells you exactly what the
> next statement will be.
Utter bullshit mate. Propagating error codes down a call stack and
checking error codes with if statements is far more difficult to grok
than exceptions.
Invalid parameters is a classic example of a 'std::domain_error' type of
exception.
Like it or not you are already using exceptions as 'new' can throw a
'std::bad_alloc' exception.
/Flibble
== 2 of 7 ==
Date: Sat, Jan 25 2014 2:59 pm
From: Tobias Müller
Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
> Like it or not you are already using exceptions as 'new' can throw a
> 'std::bad_alloc' exception.
Except 'new (nothrow)'.
Tobi
== 3 of 7 ==
Date: Sat, Jan 25 2014 4:36 pm
From: Mr Flibble
On 25/01/2014 22:59, Tobias Müller wrote:
> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>> Like it or not you are already using exceptions as 'new' can throw a
>> 'std::bad_alloc' exception.
>
> Except 'new (nothrow)'.
Which means checking for null pointers with if statements all over your
code and trying to decide what to do all over your code.
/Flibble
== 4 of 7 ==
Date: Sun, Jan 26 2014 1:51 am
From: Tobias Müller
Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
> On 25/01/2014 22:59, Tobias Müller wrote:
>> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>>> Like it or not you are already using exceptions as 'new' can throw a
>>> 'std::bad_alloc' exception.
>>
>> Except 'new (nothrow)'.
>
> Which means checking for null pointers with if statements all over your
> code and trying to decide what to do all over your code.
That's what propagation of error codes/error values means. It's tedious but
certainly possible.
Tobi
== 5 of 7 ==
Date: Sun, Jan 26 2014 8:03 am
From: Mr Flibble
On 26/01/2014 09:51, Tobias Müller wrote:
> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>> On 25/01/2014 22:59, Tobias Müller wrote:
>>> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>>>> Like it or not you are already using exceptions as 'new' can throw a
>>>> 'std::bad_alloc' exception.
>>>
>>> Except 'new (nothrow)'.
>>
>> Which means checking for null pointers with if statements all over your
>> code and trying to decide what to do all over your code.
>
> That's what propagation of error codes/error values means. It's tedious but
> certainly possible.
It is also possible for a person to be insane.
/Flibble
== 6 of 7 ==
Date: Sun, Jan 26 2014 11:13 am
From: Jax
Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote in
news:3dqdne8xsb8OxXnPnZ2dnUVZ8kadnZ2d@giganews.com:
> On 25/01/2014 22:59, Tobias Müller wrote:
>> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>>> Like it or not you are already using exceptions as 'new' can throw a
>>> 'std::bad_alloc' exception.
>>
>> Except 'new (nothrow)'.
>
> Which means checking for null pointers with if statements all over your
> code and trying to decide what to do all over your code.
>
> /Flibble
Flibble I am very new to C++ and would like to get your recommendation. Do
you mean that GOTO shouldn't ever be used or is it okay in certain
circumstances?
--
Jax :)
== 7 of 7 ==
Date: Sun, Jan 26 2014 12:11 pm
From: Mr Flibble
On 26/01/2014 19:13, Jax wrote:
> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote in
> news:3dqdne8xsb8OxXnPnZ2dnUVZ8kadnZ2d@giganews.com:
>
>> On 25/01/2014 22:59, Tobias Müller wrote:
>>> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>>>> Like it or not you are already using exceptions as 'new' can throw a
>>>> 'std::bad_alloc' exception.
>>>
>>> Except 'new (nothrow)'.
>>
>> Which means checking for null pointers with if statements all over your
>> code and trying to decide what to do all over your code.
>>
>> /Flibble
>
> Flibble I am very new to C++ and would like to get your recommendation. Do
> you mean that GOTO shouldn't ever be used or is it okay in certain
> circumstances?
'goto' should only be used to break out of nested loops.
/Flibble
==============================================================================
TOPIC: Link object files from VC++ and GCC?
http://groups.google.com/group/comp.lang.c++/t/d605f2ea0db15eb9?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 25 2014 2:30 pm
From: "Rick C. Hodgin"
On Saturday, January 25, 2014 12:01:43 PM UTC-5, Öö Tiib wrote:
> On Friday, 24 January 2014 15:49:53 UTC+2, Rick C. Hodgin wrote:
> > On Friday, January 24, 2014 3:34:26 AM UTC-5, Hans-Peter wrote:
> > > Changing the strings to fixed size will do the job:
> > > #pragma data_seg()
> > > char list[3][6] = {
> > > { "one" },
> > > { "two" },
> > > { "three"}
> > > };
> > > BTW the compiler will throw an error if you set the array dimensions too
> > > small.
> >
> > Hans-Peter, thank you for your response. I had considered using the [6]
> > add-on. The actual implementation is about 100 lines, which are source
> > code lines from another computer language. The lines vary in length from
> > a few characters up to over 80, the average probably being 15. I had
> > decided against using the [85] so as to not waste memory.
>
> So it is 8500 characters that you want to be mutable. You likely get
> better memory usage AND better performance with array (or 'std::array')
> of 'std::string's, but 8k of data are usually not worth of tinkering
> unless you have hundreds of such.
I have constraints on my design. I am currently writing a compiler that
takes some aspects of C and C++, but I will not support std::array or
std::string. As such, I am looking at some more fundamental approaches
to processing data as I intend eventually to compile my C code in my own
language.
My pursuit here to have the char* list[] array point to a list of read-write
values, instead of read-only values, also looks to that future of my compiler
design.
Best regards,
Rick C. Hodgin
==============================================================================
TOPIC: C++ is hard (Google game)
http://groups.google.com/group/comp.lang.c++/t/dac6864900693dc7?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Jan 26 2014 12:12 pm
From: Mr Flibble
Google: "Why is [language] so..."
Javascript: popular
Java: popular
Python: popular
Perl: ugly
R: slow
Ruby: slow
Fortran: fast
C++: hard
/Flibble
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment