Hi,
first a question also to non-gfortraners: if I want to use std::map,
where do I "#include "? In system.h?
Now to the patch-specific part: in this PR, module files are produced
with random changes because the order in which symbols are written can
depend on the memory layout. This patc
ps I forgot to mention that I also changed write_generic to traverse the
tree in defined order, this is the same in the C++ and the C-only patch.
Cheers,
- Tobi
On 2012-10-13 15:26, Tobias Schlüter wrote:
Hi,
first a question also to non-gfortraners: if I want to use std::map,
where do I "
On 2012-10-13 09:26 , Tobias Schlüter wrote:
Hi,
first a question also to non-gfortraners: if I want to use std::map,
where do I "#include "? In system.h?
No. Ada includes system.h in pure C code. Why not include it exactly
where you need it?
Diego.
On 2012-10-13 20:00, Diego Novillo wrote:
On 2012-10-13 09:26 , Tobias Schlüter wrote:
first a question also to non-gfortraners: if I want to use std::map,
where do I "#include "? In system.h?
No. Ada includes system.h in pure C code. Why not include it exactly
where you need it?
Ok, I wa
On 2012-10-13 14:04 , Tobias Schlüter wrote:
On 2012-10-13 20:00, Diego Novillo wrote:
On 2012-10-13 09:26 , Tobias Schlüter wrote:
first a question also to non-gfortraners: if I want to use std::map,
where do I "#include "? In system.h?
No. Ada includes system.h in pure C code. Why not in
On Sat, 13 Oct 2012, Diego Novillo wrote:
> On 2012-10-13 14:04 , Tobias Schlüter wrote:
> > On 2012-10-13 20:00, Diego Novillo wrote:
> > > On 2012-10-13 09:26 , Tobias Schlüter wrote:
> > > > first a question also to non-gfortraners: if I want to use std::map,
> > > > where do I "#include "? In
On Sat, Oct 13, 2012 at 4:26 PM, Tobias Schlüter
wrote:
>
> Hi,
>
> first a question also to non-gfortraners: if I want to use std::map, where
> do I "#include "? In system.h?
>
> Now to the patch-specific part: in this PR, module files are produced with
> random changes because the order in whic
On Mon, Oct 15, 2012 at 12:35:27AM +0300, Janne Blomqvist wrote:
> On Sat, Oct 13, 2012 at 4:26 PM, Tobias Schlüter
> > I'm putting forward two patches. One uses a C++ map to very concisely build
> > up and handle the ordered list of symbols. This has three problems:
> > 1) gfortran maintainers m
On 2012-10-14 23:44, Jakub Jelinek wrote:
On Mon, Oct 15, 2012 at 12:35:27AM +0300, Janne Blomqvist wrote:
On Sat, Oct 13, 2012 at 4:26 PM, Tobias Schlüter
I'm putting forward two patches. One uses a C++ map to very concisely build
up and handle the ordered list of symbols. This has three pro
Hi Janne,
thanks for the review.
On 2012-10-14 23:35, Janne Blomqvist wrote:
- Personally, I'd prefer the C++ version; The C++ standard library is
widely used and documented and using it in favour of rolling our own
is IMHO a good idea.
- I'd be vary wrt backporting, in my experience the modu
On 2012-10-14 23:44, Jakub Jelinek wrote:
On Mon, Oct 15, 2012 at 12:35:27AM +0300, Janne Blomqvist wrote:
On Sat, Oct 13, 2012 at 4:26 PM, Tobias Schlüter
I'm putting forward two patches. One uses a C++ map to very concisely build
up and handle the ordered list of symbols. This has three pro
Hi all,
On 2012-10-14 23:35, Janne Blomqvist wrote:
On Sat, Oct 13, 2012 at 4:26 PM, Tobias Schlüter
wrote:
- Personally, I'd prefer the C++ version; The C++ standard library is
widely used and documented and using it in favour of rolling our own
is IMHO a good idea.
After receiving no reply
Dear gfortraners,
On 2012-10-14 23:35, Janne Blomqvist wrote:
- I'd be vary wrt backporting, in my experience the module.c code is
somewhat fragile and easily causes regressions. In any case, AFAICS PR
51727 is not a regression.
Can this be reconsidered, as the benefits for users seem to be f
Hi,
On 2012-10-14 23:44, Jakub Jelinek wrote:
On Mon, Oct 15, 2012 at 12:35:27AM +0300, Janne Blomqvist wrote:
On Sat, Oct 13, 2012 at 4:26 PM, Tobias Schlüter
I'm putting forward two patches. One uses a C++ map to very concisely build
up and handle the ordered list of symbols. This has thr
14 matches
Mail list logo
