Le 08/05/2015 23:10, Georg Baum a écrit :
I have many places like in the patch below. Is there a reason why I
should keep the auto_ptr instead of a naked pointer? What is it good for?
Usually it is used for exception safety: If you use a raw pointer, you need
to delete it in the catch clause, e
On 09/05/2015 11:37, Jean-Marc Lasgouttes wrote:
Le 09/05/2015 09:18, Abdelrazak Younes a écrit :
On 08/05/2015 22:13, Jean-Marc Lasgouttes wrote:
With C++11, auto_ptr is deprecated and we get warnings.
I am trying to see how we can get rid of it. unique_ptr is new to
C++11, so I'd rather avoi
Le 09/05/2015 09:18, Abdelrazak Younes a écrit :
On 08/05/2015 22:13, Jean-Marc Lasgouttes wrote:
With C++11, auto_ptr is deprecated and we get warnings.
I am trying to see how we can get rid of it. unique_ptr is new to
C++11, so I'd rather avoid that.
Why that?
unique_ptr is supported since
On 08/05/2015 22:13, Jean-Marc Lasgouttes wrote:
With C++11, auto_ptr is deprecated and we get warnings.
I am trying to see how we can get rid of it. unique_ptr is new to
C++11, so I'd rather avoid that.
Why that?
unique_ptr is supported since gcc 4.4 released in 2009:
https://gcc.gnu.org/gc
Jean-Marc Lasgouttes wrote:
> With C++11, auto_ptr is deprecated and we get warnings.
>
> I am trying to see how we can get rid of it. unique_ptr is new to C++11,
> so I'd rather avoid that.
Why not use unique_ptr fpr C++11 and auto_ptr else? The difference is in the
copying semantics, which do
With C++11, auto_ptr is deprecated and we get warnings.
I am trying to see how we can get rid of it. unique_ptr is new to C++11,
so I'd rather avoid that.
I have many places like in the patch below. Is there a reason why I
should keep the auto_ptr instead of a naked pointer? What is it good f
On Sat, Apr 25, 2015 at 3:42 PM, Vincent van Ravesteijn wrote:
> Scott Kostyshak schreef op 22-4-2015 om 3:37:
>
> In many cases variables are defined const because they are not going to be
> changed. This does not mean that it was not allowed to be changed by design.
>
> In this case, I would ju
Scott Kostyshak schreef op 22-4-2015 om 3:37:
My question is in regards to the patch I propose for #6173:
http://www.lyx.org/trac/attachment/ticket/6173/0001-Update-previews-when-going-to-a-bookmark-6173.patch
I move the definition of cur up because I need it before the return. I
then need to pa
My question is in regards to the patch I propose for #6173:
http://www.lyx.org/trac/attachment/ticket/6173/0001-Update-previews-when-going-to-a-bookmark-6173.patch
I move the definition of cur up because I need it before the return. I
then need to pass it to notifyCursorLeavesOrEnters(), which req
> There is no need for the cast in C (as the conversion is automatic),
I have not checked C99 standard on this issue, but C has improved on
such things and may no longer allow this dangerous implicit
conversion.
> and there is no need for malloc in C++ (as there's 'new' etc).
Right. Poeple still
On Fri, Apr 07, 2006 at 08:42:45PM -0500, Bo Peng wrote:
> > commandLine = malloc (commandLineLength);
>
> commandLine = (char*)malloc (commandLineLength);
>
> Usually (to be safe, and is the case for any other type),
>
> commandLine = (char*)malloc (commandLineLength*sizeof(char));
There i
Bo Peng wrote:
commandLine = malloc (commandLineLength);
commandLine = (char*)malloc (commandLineLength);
Many thanks for this. I works and I can now start MSYS.
regards Uwe
On Sat, Apr 08, 2006 at 03:39:40AM +0200, Uwe Stöhr wrote:
> Could anybody help me with a little C-Problem. Attached is a small
> sourcecode that I have to compile. G++ tells me:
>
> D:\LyXSVN>g++ createprocess.c -o CreateProcess.exe
> createprocess.c: In function `int main(int, char**)':
> crea
> commandLine = malloc (commandLineLength);
commandLine = (char*)malloc (commandLineLength);
Usually (to be safe, and is the case for any other type),
commandLine = (char*)malloc (commandLineLength*sizeof(char));
Bo
Could anybody help me with a little C-Problem. Attached is a small
sourcecode that I have to compile. G++ tells me:
D:\LyXSVN>g++ createprocess.c -o CreateProcess.exe
createprocess.c: In function `int main(int, char**)':
createprocess.c:25: error: invalid conversion from `void*' to `char*'
Any
On Sun, Jun 05, 2005 at 09:41:26PM +0100, Angus Leeming wrote:
> I feel like a bit of an idiot asking this, but what's the C++ way to insert
> some data into an existing file?
Write a new one. It's about the only way that has certain guarantees to
work without sacrificing black roosters.
Andre'
Lars Gullik Bjønnes wrote:
| I feel like a bit of an idiot asking this, but what's the C++ way to
| insert some data into an existing file?
How would you do it in any other language?
At end is easy. At start is more tricky...
If it were a memory buffer how would you do it then?
(memmove perhap
Angus Leeming <[EMAIL PROTECTED]> writes:
| I feel like a bit of an idiot asking this, but what's the C++ way to
| insert some data into an existing file?
How would you do it in any other language?
At end is easy. At start is more tricky...
If it were a memory buffer how would you do it then?
(
I feel like a bit of an idiot asking this, but what's the C++ way to insert
some data into an existing file?
I tried this:
std::fstream fs(configure_file);
std::string buffer;
bool success = false;
while (fs) {
std::fstream::pos_type const start_of_line = fs.tellp();
std::getli
Andre Poenitz wrote:
I am not sure the message is valid. Sure, the compiler sees a tmporary
and returning a reference to a part of something refered to by the
temporary. However, that thing is not a temporary but lives in a
structure outside. The compiler does not know, but we do. So my
guess is t
On Tue, Feb 15, 2005 at 10:58:13AM +, Angus Leeming wrote:
> class Mover {...};
> class SpecialisedMover : public Mover {...};
>
> class Movers {
> public:
> /// @c returns the Mover registered for format @c fmt.
> Mover const & operator()(std::string const & fmt) const
> {
>
Angus Leeming wrote:
I read that as saying that the code in the mail at the start of this thread
is perfectly safe, don't you?
Well, we also have:
template
class _Tree
{
const_iterator find(const key_type& _Keyval) const
{ // find an element in nonmutable seque
Asger Alstrup wrote:
> Angus Leeming wrote:
>> That will require an MSVC user (Asger) to check his
>> std::map::const_iterator implementation.
>
> I'm not sure this is what you are looking for, but here is some of the
> code for the map::const_iterator in MSVC 7.1:
>
> class const_iterator
> : p
Angus Leeming wrote:
That will require an MSVC user (Asger) to check his
std::map::const_iterator implementation.
I'm not sure this is what you are looking for, but here is some of the code
for the map::const_iterator in MSVC 7.1:
class const_iterator
: public _Bidit
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | class Mover {...};
> | class SpecialisedMover : public Mover {...};
>>
> | class Movers {
> | public:
> | /// @c returns the Mover registered for format @c fmt.
> | Mover const & operator()(std::string const & f
Angus Leeming <[EMAIL PROTECTED]> writes:
| class Mover {...};
| class SpecialisedMover : public Mover {...};
>
| class Movers {
| public:
| /// @c returns the Mover registered for format @c fmt.
| Mover const & operator()(std::string const & fmt) const
| {
| SpecialsMap::cons
class Mover {...};
class SpecialisedMover : public Mover {...};
class Movers {
public:
/// @c returns the Mover registered for format @c fmt.
Mover const & operator()(std::string const & fmt) const
{
SpecialsMap::const_iterator const it = specials_.find(fmt);
return (i
Andre Poenitz wrote:
> Aehm... that's not LyX, is it?
weee, grep for either boost::function or boost::bind in the lyx
srcs...
--
Angus
On Wed, Nov 05, 2003 at 01:46:06PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > You do not expect me to understand that, do you?
>
> Think of it as the consequences of your suggestion and ask forgiveness
> ;-)
>
> Actually, this isn't so complicated is it:
>
> boost::function
Andre Poenitz wrote:
> You do not expect me to understand that, do you?
Think of it as the consequences of your suggestion and ask forgiveness
;-)
Actually, this isn't so complicated is it:
boost::function set_value = Node::set_conc;
Node node;
double val = 3;
//
On Wed, Nov 05, 2003 at 12:53:02PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > Well... this exposes an implementation detail (type of container) to
> > the outer world. Moreover, people are tempted to use ++ on
> > iterators, whereas not too many poeple would use (&element(3) + 1)
> >
>
Lars Gullik Bjønnes wrote:
> boost::function set_value = ...
>
> a bit more taxing on the complier but fewer surprises in the syntax.
> (IMHO of course.)
Last time I tried, gcc fell over on this syntax...
... nope. Works perfectly. Thanks, Lars.
--
Angus
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>> Well... this exposes an implementation detail (type of container) to
>> the outer world. Moreover, people are tempted to use ++ on
>> iterators, whereas not too many poeple would use (&element(3) + 1)
>>
>> So _I_'d prefer the ac
Andre Poenitz wrote:
> Well... this exposes an implementation detail (type of container) to
> the outer world. Moreover, people are tempted to use ++ on
> iterators, whereas not too many poeple would use (&element(3) + 1)
>
> So _I_'d prefer the accessor functions.
Hmpfff. I did as you suggested
On Tue, Nov 04, 2003 at 01:15:27PM +, Angus Leeming wrote:
> Grrr
> Windmills.
The new official catchphrase ?
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
On Tue, Nov 04, 2003 at 03:47:37PM +, Angus Leeming wrote:
> However, LyX is trying to use iterators more, not less, and you are
> driving that effort.
By replacing PragraphList::iterator with integer offsets?
Hah... you reveal my secret plan...
Andre'
Andre Poenitz wrote:
> On Tue, Nov 04, 2003 at 02:00:21PM +, Angus Leeming wrote:
>> Andre Poenitz wrote:
>>
>> > On Tue, Nov 04, 2003 at 12:19:25PM +, Angus Leeming wrote:
>> >> I have a container that currently allows the user to alter the
>> >> Node container. I want to allow the user
On Tue, Nov 04, 2003 at 02:00:21PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> > On Tue, Nov 04, 2003 at 12:19:25PM +, Angus Leeming wrote:
> >> I have a container that currently allows the user to alter the Node
> >> container. I want to allow the user to be able to alter the Node
Andre Poenitz wrote:
> On Tue, Nov 04, 2003 at 12:19:25PM +, Angus Leeming wrote:
>> I have a container that currently allows the user to alter the Node
>> container. I want to allow the user to be able to alter the Node
>> contents but to not be able to insert, erase Nodes from the vector.
>>
Andre Poenitz wrote:
> On Tue, Nov 04, 2003 at 12:37:00PM +, Angus Leeming wrote:
>> >> What's the best way to proceed?
>> >
>> >
>> > /// The element list is immutable.
>> > //std::vector const & elements() const { return
>> > elements_; } Element const & element(
On Tue, Nov 04, 2003 at 12:37:00PM +, Angus Leeming wrote:
> >> What's the best way to proceed?
> >
> >
> > /// The element list is immutable.
> > //std::vector const & elements() const { return
> > elements_; } Element const & element(size_t i) const {
> >
Andre Poenitz wrote:
> On Tue, Nov 04, 2003 at 12:19:25PM +, Angus Leeming wrote:
>> I have a container that currently allows the user to alter the Node
>> container. I want to allow the user to be able to alter the Node
>> contents but to not be able to insert, erase Nodes from the vector.
>>
Angus Leeming <[EMAIL PROTECTED]> writes:
| I have a container that currently allows the user to alter the Node
| container. I want to allow the user to be able to alter the Node
| contents but to not be able to insert, erase Nodes from the vector.
Don't return the vector but have an accessor f
On Tue, Nov 04, 2003 at 12:19:25PM +, Angus Leeming wrote:
> I have a container that currently allows the user to alter the Node
> container. I want to allow the user to be able to alter the Node
> contents but to not be able to insert, erase Nodes from the vector.
>
> What's the best way to
I have a container that currently allows the user to alter the Node
container. I want to allow the user to be able to alter the Node
contents but to not be able to insert, erase Nodes from the vector.
What's the best way to proceed?
/** \c ElementList is a convenient container of the nodes
*
On Wednesday 24 September 2003 1:44 pm, Andre Poenitz wrote:
> On Wed, Sep 24, 2003 at 02:29:44PM +, Angus Leeming wrote:
> > Which doesn't help us much...
>
> What why do you need that vector?
I guess I don't ;-)
Angus
namespace {
template
void clearIfNotFound(T & data, Enum value, vector
On Wed, Sep 24, 2003 at 02:29:44PM +, Angus Leeming wrote:
> Which doesn't help us much...
What why do you need that vector?
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Andre Poenitz wrote:
> On Wed, Sep 24, 2003 at 01:55:09PM +, Angus Leeming wrote:
>> Given an enum, is there a semi-automated way of returning a vector of
>> all named enum values? The best I can come up with is this:
>
> None that I am aware of.
>
> Actually, your solution does not work for
On Wed, Sep 24, 2003 at 01:55:09PM +, Angus Leeming wrote:
> Given an enum, is there a semi-automated way of returning a vector of all
> named enum values? The best I can come up with is this:
None that I am aware of.
Actually, your solution does not work for e.g.
enum TransformID {
Given an enum, is there a semi-automated way of returning a vector of all
named enum values? The best I can come up with is this:
#include
#include
template
std::vector const all_values_if_consecutive(Enum first, Enum last)
{
std::vector vals(last - first + 1);
typename std::ve
On Thu, Jun 12, 2003 at 09:02:20AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > The generated once will call the cctor and operator= of the base
"once"
*sigh* I really wonder why people write "phonetically"...
Does that mean we think, formulate audible words and write them down using
s
Andre Poenitz wrote:
> On Wed, Jun 11, 2003 at 07:29:17PM +, Angus Leeming wrote:
>> class Derived : public Base {
>> ???
>> };
>>
>> The question is, do I need to define explicit copy c-tor and operator=
>> for Derived to ensure that Base's copy c-tor, operator= is used?
>
> No.
>
On Wed, Jun 11, 2003 at 07:29:17PM +, Angus Leeming wrote:
> class Derived : public Base {
> ???
> };
>
> The question is, do I need to define explicit copy c-tor and operator= for
> Derived to ensure that Base's copy c-tor, operator= is used?
No.
The generated once will call the c
Suppose I have classes
class Base {
public:
Base()
: cache_(0)
{}
// cache is not copied.
Base(Base const &)
: cache_(0)
{}
Base & operator=(Base const &)
{
return *this;
}
private:
On Fri, Feb 14, 2003 at 01:43:50PM +, Angus Leeming wrote:
> why does this compile:
> string data = ...;
> istringstream datastream(data);
> LyXLex lex(0,0);
> lex.setStream(datastream);
>
> and this not:
> LyXLex lex(0,0);
> lex.setStream(istri
André, as our resident c++ guru, why does this compile:
string data = ...;
istringstream datastream(data);
LyXLex lex(0,0);
lex.setStream(datastream);
and this not:
LyXLex lex(0,0);
lex.setStream(istringstream(data));
The compiler complains that it
> I read the recent thread about casting Insets up to
> their "real" type and thought I'd try and implement André's
> asAInset, asBInset, asCInset thing using templates.
>
> Unfortunately, it doesn't compile :-(
>
> Is their anyway to do this?
No, you can't have templated virtual member functions.
On Thursday 31 October 2002 11:21 am, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | On Thursday 31 October 2002 10:57 am, Lars Gullik Bjønnes wrote:
> >> Angus Leeming <[EMAIL PROTECTED]> writes:
> >> | I read the recent thread about casting Insets up to
> >> | their "r
Angus Leeming <[EMAIL PROTECTED]> writes:
| Anyway, to answer your call for testers, this is what happens here:
I just tested with
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
this does not have member templates, but dynamic_cast work as
expected.
To me this implies that all g
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Thursday 31 October 2002 10:57 am, Lars Gullik Bjønnes wrote:
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>> | I read the recent thread about casting Insets up to
>> | their "real" type and thought I'd try and implement André's
>> | asAInset, asBInse
On Thursday 31 October 2002 10:57 am, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | I read the recent thread about casting Insets up to
> | their "real" type and thought I'd try and implement André's
> | asAInset, asBInset, asCInset thing using templates.
> |
> | Unfort
Angus Leeming <[EMAIL PROTECTED]> writes:
| I read the recent thread about casting Insets up to
| their "real" type and thought I'd try and implement André's
| asAInset, asBInset, asCInset thing using templates.
>
| Unfortunately, it doesn't compile :-(
>
| Is their anyway to do this?
Yes, by u
I read the recent thread about casting Insets up to
their "real" type and thought I'd try and implement André's
asAInset, asBInset, asCInset thing using templates.
Unfortunately, it doesn't compile :-(
Is their anyway to do this?
Angus
class Base {
public:
virtual ~Base() {}
On Mon, Jul 22, 2002 at 12:35:33PM +0200, Lars Gullik Bjønnes wrote:
> You could do as they do in the stl and take a reference are, but store
> the pointer. We should probably introduce a new smartpointer for that
> then.
>
> held_ptr<> perhaps.
I like this (though it still means I have to have
John Levon <[EMAIL PROTECTED]> writes:
| What is the standard way to get around the icky std::map requirement
| that the value object have a default ctor ? This is forcing me to not
| only havea pointless default no-argument ctor, but stop using references
| in the struct value for no good reason
What is the standard way to get around the icky std::map requirement
that the value object have a default ctor ? This is forcing me to not
only havea pointless default no-argument ctor, but stop using references
in the struct value for no good reason :(
regards
john
--
"Of all manifestations
On Thu, Apr 25, 2002 at 04:02:04PM +0200, Lars Gullik Bjønnes wrote:
> outside foo
> outside foo inside anon namespace
> inside foo...
>
> but there is one variant that is not allowed...
If there is one it might be the one in anon namespace.
Reasoning along the lines of: Suppose we had a compil
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | if (it == end) {
| | std::cout << c << " not found" << std::endl;
| | } else {
| | std::cout << c << " found at pos "
| | << it - b
Angus Leeming <[EMAIL PROTECTED]> writes:
| #include
| #include
| #include
>
| using std::string;
>
| class Foo {
| public:
| class Functor {
| public:
| Functor(char cin) : c(cin) {}
| bool operator()(char comp) { return c == comp; }
| p
On Thursday 25 April 2002 3:04 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | Apologies for the off-topic nature, but you're the best C++ programmers I
> | know ;-)
> |
> | Boost has shared_ptr and shared_c_ptr and scoped_ptr but no scoped_c_ptr
> | which leads to t
Angus Leeming <[EMAIL PROTECTED]> writes:
| Apologies for the off-topic nature, but you're the best C++ programmers I
| know ;-)
>
| Boost has shared_ptr and shared_c_ptr and scoped_ptr but no scoped_c_ptr
| which leads to the thought that actually all these are the same, save for the
| functi
Apologies for the off-topic nature, but you're the best C++ programmers I
know ;-)
Boost has shared_ptr and shared_c_ptr and scoped_ptr but no scoped_c_ptr
which leads to the thought that actually all these are the same, save for the
function they call in their d-tor.
So why don't they parame
On Thursday 25 April 2002 12:48 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> >> class Foo {
> >> class Functor {};
> >>
> >> void do_stuff() {
> >>find_if(..., Functor());
> >> }
> >> };
> |
> | I'm hazy about why not. Because it can go
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Apr 25, 2002 at 01:40:05PM +0200, Lars Gullik Bjønnes wrote:
>> What's not ok is using local classes for this:
>
| Is this written somewhere?
Yes, I belive so. I have seen references to this both at the boost
list and comp.lang.c++.moderated.
On Thu, Apr 25, 2002 at 01:40:05PM +0200, Lars Gullik Bjønnes wrote:
> What's not ok is using local classes for this:
Is this written somewhere?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
On Thu, Apr 25, 2002 at 12:35:11PM +0100, Angus Leeming wrote:
> What's the official take on putting functors in namespace anon and then
> passing them to an STL routine?
That's not forbidden as far as I know. But I am not really sure.
Andre'
--
Those who desire to give up Freedom in order to
Angus Leeming <[EMAIL PROTECTED]> writes:
>> class Foo {
>> class Functor {};
>>
>> void do_stuff() {
>>find_if(..., Functor());
>> }
>> };
>
| I'm hazy about why not. Because it can go out of scope? See, hazy! Could you
| lift my fog?
I am not really sure, but jus
On Thursday 25 April 2002 12:40 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | What's the official take on putting functors in namespace anon and then
> | passing them to an STL routine?
> |
> | Here, I get warnings like:
> | cxx: Warning: /usr/include/cxx/algorithm
Angus Leeming <[EMAIL PROTECTED]> writes:
| What's the official take on putting functors in namespace anon and then
| passing them to an STL routine?
>
| Here, I get warnings like:
| cxx: Warning: /usr/include/cxx/algorithm.cc, line 110: #1115-D external
| routine
| uses unnamed type
What's the official take on putting functors in namespace anon and then
passing them to an STL routine?
Here, I get warnings like:
cxx: Warning: /usr/include/cxx/algorithm.cc, line 110: #1115-D external
routine
uses unnamed type or namespace.
InputIterator find_if (InputIterator first
On Thursday 18 April 2002 10:18 am, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | Do you have any opinions about which way I should go?
>
> No, not really.
>
> - be as const as possible
> - all class functions that are logically const should be const.
>
> That's the ru
Angus Leeming <[EMAIL PROTECTED]> writes:
| Do you have any opinions about which way I should go?
No, not really.
- be as const as possible
- all class functions that are logically const should be const.
That's the rules I use.
--
Lgb
On Wednesday 17 April 2002 8:21 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | I'm clearly confused when it comes to "const" and member pointers.
> |
> | See the little code snippet below. If I compile it, I get the error:
> |
> | cxx: Error: trial.C, line 23: (that
Angus Leeming <[EMAIL PROTECTED]> writes:
| I'm clearly confused when it comes to "const" and member pointers.
>
| See the little code snippet below. If I compile it, I get the error:
>
| cxx: Error: trial.C, line 23: (that is, in the const_method)
| the object has type qualifiers that are not co
I'm clearly confused when it comes to "const" and member pointers.
See the little code snippet below. If I compile it, I get the error:
cxx: Error: trial.C, line 23: (that is, in the const_method)
the object has type qualifiers that are not compatible with the member
function
func(ob())
On Wednesday 13 March 2002 6:08 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | If I have a map some_map, can I create a vector of the keys
also,
> | vector ref_vec? I can create a vector ptr_vec.
> >
> | I'm thinking of my Bibtex data base of course.
>
> You c
Angus Leeming <[EMAIL PROTECTED]> writes:
| If I have a map some_map, can I create a vector of the keys also,
| vector ref_vec? I can create a vector ptr_vec.
>
| I'm thinking of my Bibtex data base of course.
You cannot "reset" an reference;
string a("Hello There!");
string & b = a;
string c(
If I have a map some_map, can I create a vector of the keys also,
vector ref_vec? I can create a vector ptr_vec.
I'm thinking of my Bibtex data base of course.
/** All Bibliography keys derive from this base class, and need only define
* code() to be instantiated.
*/
class BibKey {
public:
On Wednesday 12 December 2001 5:37 pm, Andre Poenitz wrote:
> On Wed, Dec 12, 2001 at 03:50:46PM +, Angus Leeming wrote:
> > Sorry for the off-topic question but:
> >
> > What is the correct way to empty a stringstream to use it again?
Currently,
> > I'm using ss.str(string()) but I'm sure
On Wed, Dec 12, 2001 at 03:50:46PM +, Angus Leeming wrote:
> Sorry for the off-topic question but:
>
> What is the correct way to empty a stringstream to use it again? Currently,
> I'm using ss.str(string()) but I'm sure there must be a better way...
Don't do that. Use a new stream.
I'll ne
On Wednesday 12 December 2001 3:52 pm, Lars Gullik Bjønnes wrote:
> I do not think there is better way...
Thank you.
A
Sorry for the off-topic question but:
What is the correct way to empty a stringstream to use it again? Currently,
I'm using ss.str(string()) but I'm sure there must be a better way...
std::stringstream ss;
// fill it the first time
ss << "attempt 1";
std::cerr <
On Saturday 25 August 2001 21:56, John Levon wrote:
> Angus recently added isBuilt() in controllers/ to make sure that
> the dialog is built before changing its readonly stuff.
>
> 60 template
> 61 void ControlDialog::show()
> 62 {
> 63 if (isBufferDependent() && !lv_
On Mon, Aug 27, 2001 at 08:21:50AM +0200, Andre Poenitz wrote:
> > 60 template
> > 61 void ControlDialog::show()
> > 62 {
> > 63 if (isBufferDependent() && !lv_.view()->available())
> > 64 return;
> > 65
> > 66 setParams();
> >
On Mon, Aug 27, 2001 at 08:21:50AM +0200, Andre Poenitz wrote:
> I'd say every instance of the function should have its own static. How else
> could it work when the type of 'isBuilt' depents on the template parameter?
I have no idea - let me put it this way; making it a member fixes the problem
> 60 template
> 61 void ControlDialog::show()
> 62 {
> 63 if (isBufferDependent() && !lv_.view()->available())
> 64 return;
> 65
> 66 setParams();
> 67
> 68 static bool isBuilt = false;
> 69 if (!isB
On Sun, Aug 26, 2001 at 04:42:03PM +0200, Yves Bastide wrote:
> Your void ControlDialog::show() is common to all objects of type
> "Base". Why don't you just use a data member? Rough draft:
yes, this is what I did in the end.
thanks
john
--
"That's just kitten-eating wrong."
- Rich
On Sat, Aug 25, 2001 at 09:56:49PM +0100, John Levon wrote:
>
> Angus recently added isBuilt() in controllers/ to make sure that
> the dialog is built before changing its readonly stuff.
>
> 60 template
> 61 void ControlDialog::show()
> 62 {
> 63 if (isBufferDependen
Angus recently added isBuilt() in controllers/ to make sure that
the dialog is built before changing its readonly stuff.
60 template
61 void ControlDialog::show()
62 {
63 if (isBufferDependent() && !lv_.view()->available())
64 return;
65
Perfect. Thank you.
A
On Wednesday 09 May 2001 11:31, John Levon wrote:
> On Wed, 9 May 2001, Angus Leeming wrote:
>
> > This one dies with
> >
> > cxx: Error: #79 expected a type specifier
> > typedef MenuList::const_iterator const_iterator;
> ^
>
> try adding "typen
1 - 100 of 168 matches
Mail list logo
