Visual Studio 64 бита? [закрытый]

Вот пара вещей, которые, я думаю, могли бы вам помочь:

1) Разделить ваш код. doStuff запрашивает ввод данных у пользователя, но также генерирует массив, содержащий значения из min-max. У вас должна быть отдельная функция, которая генерирует массив от мин до макс. Разделив его, вы сможете легче идентифицировать проблему.

2) Несколько решений предлагают глобальную переменную, которая может быть опасной. Когда вы должны совместно использовать состояние, ограничьте его область действия только тем, что необходимо для доступа к этому состоянию.

3) Сделайте ваши интерфейсы согласованными. Вы не должны возвращать значение одного экземпляра и ничего в другом. Если есть ошибка, убедитесь, что вы согласны с тем, как вы уведомляете звонящего.

function buildArray(start, end) {
  let arr = [];

  if (start > end) {
    // There are a lot ways to deal with this
    // But you want a consistent interface for letting
    // the caller no that start < end
    throw {
     message: 'Start can\'t be bigger than end',
    };
  }
  
  for (let x = start; x <= end; x++) {
    arr.push(x);
  }
  
  return arr; 
}

// encapsulate the variable numArray, so that it is only accessible
// to the methods that need it
var numArrayModule = (function(){
   let numArray = [];
   
   return {
     doStuff: function(){
        let start = parseInt(prompt("Enter a small number"));
        let end = parseInt(prompt("Enter a larger number"));
        try {
          numArray = buildArray(start, end);
        } catch(err) {
          console.log(err);
        }
     },
     addArray: function(){
        console.log(numArray);
     },
   }

}());
// You may use these as onClick handlers as well.
numArrayModule.doStuff();
numArrayModule.addArray();

250
задан shA.t 21 February 2018 в 00:29
поделиться

4 ответа

Технические причины являются просто оправданием. Настоящая причина "..., потому что существует больше денег, которые будут сделаны, делая что-то еще". Люди, которые разрабатывают использование Microsoft Tools, склонны придерживаться Microsoft. Если бы был некоторый большой альтернативный язь на 64 бита, который заставлял Microsoft терять деньги тогда, то у них была бы версия на 64 бита через несколько месяцев. (Если существует альтернатива, я не услышал о ней, имеет кого-либо здесь на stackoverflow?)

0
ответ дан Paul McCarthy 27 June 2019 в 06:47
поделиться

По многим причинам Нет .

Почему объясняется в этом сообщении MSDN .

Во-первых, с точки зрения производительности указатели становятся больше, поэтому структуры данных становятся больше, а кэш процессора остается того же размера. Это в основном приводит к снижению чистой скорости (ваш пробег может различаться). Итак, вы начинаете в яме и должны выкопать себя из нее, используя дополнительную память выше 4G в своих интересах. В Visual Studio это может происходить в некоторых больших решениях, но я думаю, что лучше всего в первую очередь просто использовать меньше памяти. Многие алгоритмы VS поддаются этому. Вот старая статья, в которой подробно обсуждаются проблемы с производительностью: http://blogs.msdn.com/joshwil/archive/2006/07/18/670090.aspx

Во-вторых, с точки зрения затрат, вероятно, самый короткий путь переноса Visual Studio на 64-разрядную версию - это постепенный перенос большей части ее на управляемый код , а затем перенос остальной части. Стоимость полного переноса этого большого количества нативного кода будет довольно высокой, и, конечно же, все известные расширения выйдут из строя, и нам придется создать 64-битный {{1} } экосистема почти так же, как и для драйверов. Ой.

228
ответ дан 23 November 2019 в 02:57
поделиться

Нет, но 32-битная версия отлично работает в 64-битной Windows.

5
ответ дан 23 November 2019 в 02:57
поделиться

нет, но он отлично работает на win64 и может создавать файлы Win64 .EXE

4
ответ дан 23 November 2019 в 02:57
поделиться
Другие вопросы по тегам:

Похожие вопросы: